<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Hi Andrew.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Passive congestion probing is appealing because it does not require specific signalling from routers, hence it can be deployed with little effort. On the other hand, specific router behavior may interfere with some such passive schemes.</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">But that is the same as specific receiver misbehavior (either maliciously or not).</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">I guess it is widespread consensus today that complexity at the end points is best, so routers should keep its simplicity (not belittling routers many functions of today). Fortunately most routers adopt droptail queues. It is up to IETF to point to the direction most appropriate for queue management, and hence, router behavior of the future. I am not advocating routers imposing "unecessary queue delays" (I am not sure what you mean by that) for the purpose of congestion signalling. Explicit signalling requires specific router behavior from the get go, AND it is difficult to guarantee anything if not adopted by all routers on a session path. Even worse, performance of CC acting on explicit congestion information is not guaranteed even if ECN is supported by all routers on a session, assuming that routers generating such information is not aware of specific TCP session
details, such as rtts, or speed of rate adjustments. In addition, it is hard to specify a particular ECN to be supported by routers, without nailing down what TCP senders will do with that information.<BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">In my previous experience with designing network layer protocols, a big impairment was to overcome the hurdle of touching every single network element for deplying a new protocol. I've learned to be sympathetic to the issue. So it makes sense to me to ask: "how well can we design a CC scheme with as little new features from routers as possible?" Notice that I am not excluding ECN solutions - they could be overlayed on top of passive probing schemes, as they are currently on TCPs...</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">Dirceu<BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Lachlan Andrew <lachlan.andrew@gmail.com><BR>To: Dirceu Cavendish <dirceu_cavendish@yahoo.com><BR>Cc: Michael Welzl <michael.welzl@uibk.ac.at>; Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu>; "RAMAKRISHNAN, KADANGODE K (K. K.)" <kkrama@research.att.com>; iccrg@cs.ucl.ac.uk; Vijay Subramanian <subrav@rpi.edu><BR>Sent: Thursday, August 9, 2007 10:08:57 AM<BR>Subject: Re: [Iccrg] LT-TCP followup<BR><BR>
<DIV>Greetings Dirceu,<BR><BR>On 09/08/07, Dirceu Cavendish <dirceu_cavendish@yahoo.com> wrote:<BR>><BR>> Various TCP variants today track rtts, which would allow differentiation<BR>> between corruption loss and overflow loss. Obviously, in a extremely worst<BR>> case scenario, a packet loss overflow could occur at a single packet with no<BR>> "rtt evidence" (rtt increase) on "surrounding" packets of a TCP stream. But<BR>> IMHO most of the scenarios I've seen, the rtt increase evidence is there.<BR><BR>In most current scenarios, RED isn't used. If RED is used, congestion<BR>loss can happen with negligible RTT increase. An even more extreme<BR>case would be a router which ran an AQM on a virtual queue, in<BR>which case even severe congestion need not affect RTT at all (and<BR>combined with ECN could give congestion indication without impairing<BR>either loss or delay).<BR><BR>I'm all
for considering both delay and loss, but we should think<BR>carefully before encouraging a mechanism that relies too much on<BR>delays, which may force future standards to mandate that routers<BR>induce unnecessary delays during congestion. I'd prefer to encourage<BR>explicit signalling as the primary mechanism, and just use performance<BR>degradation (loss, delay, jitter) if it is still present after we<BR>account for the explicit signals.<BR><BR>Cheers,<BR>Lachlan<BR><BR>-- <BR>Lachlan Andrew Dept of Computer Science, Caltech<BR>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA<BR>Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603</DIV></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1>Sick sense of humor? Visit Yahoo! TV's
<a href="http://us.rd.yahoo.com/evt=47093/*http://tv.yahoo.com/collections/222">Comedy with an Edge </a>to see what's on, when.
</body></html>