[Iccrg] LT-TCP followup

[Dirceu Cavendish]

Hi Andrew.

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.
But that is the same as specific receiver misbehavior (either maliciously or not).
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.

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...

Dirceu

----- Original Message ----
From: Lachlan Andrew <lachlan.andrew at gmail.com>
To: Dirceu Cavendish <dirceu_cavendish at yahoo.com>
Cc: Michael Welzl <michael.welzl at uibk.ac.at>; Shivkumar Kalyanaraman <shivkuma at ecse.rpi.edu>; "RAMAKRISHNAN, KADANGODE K (K. K.)" <kkrama at research.att.com>; iccrg at cs.ucl.ac.uk; Vijay Subramanian <subrav at rpi.edu>
Sent: Thursday, August 9, 2007 10:08:57 AM
Subject: Re: [Iccrg] LT-TCP followup


Greetings Dirceu,

On 09/08/07, Dirceu Cavendish <dirceu_cavendish at yahoo.com> wrote:
>
> Various TCP variants today track rtts, which would allow differentiation
> between corruption loss and overflow loss. Obviously, in a extremely worst
> case scenario, a packet loss overflow could occur at a single packet with no
> "rtt evidence" (rtt increase) on "surrounding" packets of a TCP stream. But
> IMHO most of the scenarios I've seen, the rtt increase evidence is there.

In most current scenarios, RED isn't used.  If RED is used, congestion
loss can happen with negligible RTT increase.  An even more extreme
case would be a router which ran an AQM on a   virtual   queue, in
which case even severe congestion need not affect RTT at all (and
combined with ECN could give congestion indication without impairing
either loss or delay).

I'm all for considering both delay and loss, but we should think
carefully before encouraging a mechanism that relies too much on
delays, which may force future standards to mandate that routers
induce unnecessary delays during congestion.  I'd prefer to encourage
explicit signalling as the primary mechanism, and just use performance
degradation (loss, delay, jitter) if it is still present after we
account for the explicit signals.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603


       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070809/f7ef995d/attachment.html