[Iccrg] LT-TCP followup

[Dirceu Cavendish]

The problem with ECN is that, as in any router assisted CC solution, it requires an all routers' support. If a single router is not ECN enabled, little can be guaranteed about CC's performance.
Of course, any ECN solution in a mix path environment should perform at least as well as when there is no ECN router support at all in the session path. That is why I am more infavor of CC schemes with implicit CC info, not explicit. I believe it is possible to differentiate between (b) and (c) cases below with implicit feedback information...

Dirceu


----- Original Message ----
From: Lachlan Andrew <lachlan.andrew at gmail.com>
To: Shivkumar Kalyanaraman <shivkuma at ecse.rpi.edu>
Cc: "RAMAKRISHNAN, KADANGODE K (K. K.)" <kkrama at research.att.com>; iccrg at cs.ucl.ac.uk; Vijay Subramanian <subrav at rpi.edu>
Sent: Wednesday, August 8, 2007 10:15:12 AM
Subject: Re: [Iccrg] LT-TCP followup


Greetings Shiv,

If we use ECN to distinguish between congestion and loss, how can we
detect that "there is loss that is caused due to congestion on the
path (and ECN signals are absent)" and know to revert to TCP-SACK?

The problem is that the flow may be ECN-enabled, and there may be (a)
some ECN packets, (b) some packets lost due to corruption, and (c)
some packets lost due to congestion of a non-ECN queue.  How can we
distinguish (b) from (c)?

Thanks,
Lachlan

On 08/08/2007, Shivkumar Kalyanaraman <shivkuma at ecse.rpi.edu> wrote:
>
> If ECN is used, the likelihood of congestion related loss may be
> minimized. However, if there is congestion related loss, because either
> ECN is absent, or there are also end-systems that do not respond to ECN,
> then LT-TCP will have a robust method for safely reverting back to
> TCP-SACK behavior. When there is loss that is caused due to congestion
> on the path (and ECN signals are absent), LT-TCP will revert back to
> TCP-SACK.

> best
> -Shiv
>
> On Mon, 6 Aug 2007, Michael Welzl wrote:
>
> > in the presence of
> > packet loss (which can always be due to an overflowing queue,
> > ECN notwithstanding), the right thing to do is to assume congestion.


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

_______________________________________________
Iccrg mailing list
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg


       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070808/25546a10/attachment-0001.html