[Iccrg] LT-TCP followup

[Michael Welzl]

Hi,

It's worse: even with ECN all over the place, a queue
can overflow, and then a packet can be dropped due
to congestion. It's just less likely.

Hence, the only reliable way to avoid missing
a congestion signal in the Internet of today
is to assume that a packet loss is due to
congestion - which makes it impossible to rely
on the same signal as a sign of corruption - and
hence, an altogether different (i.e. explicit)
signal is the best way to signal corruption IMO

that's why I suggested using ETEN (and I agree
that your TCP variant would probably still work
very well if combined with it!)

cheers
michael


On Wed, 2007-08-08 at 10:47 -0700, Dirceu Cavendish wrote:
> 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
> 
> 
> 
> 
> ______________________________________________________________________
> Shape Yahoo! in your own image. Join our Network Research Panel today!
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg