[Iccrg] LT-TCP followup

[Lachlan Andrew]

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