<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">Michael,</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">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.</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">Notice that mistakenly taken a corruption loss as overflow loss does not necessarily have to have a big impact on a TCP session. It is bad enough for VJ (alpha=2) TCP, but other controllers can be much more "immune" to sporadic "misreading" of packet loss information.</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><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Michael Welzl <michael.welzl@uibk.ac.at><BR>To: Dirceu Cavendish <dirceu_cavendish@yahoo.com><BR>Cc: l.andrew@ieee.org; 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 6:23:53 AM<BR>Subject: Re: [Iccrg] LT-TCP followup<BR><BR>
<DIV>Hi,<BR><BR>It's worse: even with ECN all over the place, a queue<BR>can overflow, and then a packet can be dropped due<BR>to congestion. It's just less likely.<BR><BR>Hence, the only reliable way to avoid missing<BR>a congestion signal in the Internet of today<BR>is to assume that a packet loss is due to<BR>congestion - which makes it impossible to rely<BR>on the same signal as a sign of corruption - and<BR>hence, an altogether different (i.e. explicit)<BR>signal is the best way to signal corruption IMO<BR><BR>that's why I suggested using ETEN (and I agree<BR>that your TCP variant would probably still work<BR>very well if combined with it!)<BR><BR>cheers<BR>michael<BR><BR><BR>On Wed, 2007-08-08 at 10:47 -0700, Dirceu Cavendish wrote:<BR>> The problem with ECN is that, as in any router assisted CC solution,<BR>> it requires an all routers' support. If a single router is not ECN<BR>> enabled, little can be guaranteed about CC's
performance.<BR>> Of course, any ECN solution in a mix path environment should perform<BR>> at least as well as when there is no ECN router support at all in the<BR>> session path. That is why I am more infavor of CC schemes with<BR>> implicit CC info, not explicit. I believe it is possible to<BR>> differentiate between (b) and (c) cases below with implicit feedback<BR>> information...<BR>> <BR>> Dirceu<BR>> <BR>> <BR>> ----- Original Message ----<BR>> From: Lachlan Andrew <lachlan.andrew@gmail.com><BR>> To: Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu><BR>> Cc: "RAMAKRISHNAN, KADANGODE K (K. K.)" <kkrama@research.att.com>;<BR>> iccrg@cs.ucl.ac.uk; Vijay Subramanian <subrav@rpi.edu><BR>> Sent: Wednesday, August 8, 2007 10:15:12 AM<BR>> Subject: Re: [Iccrg] LT-TCP followup<BR>> <BR>> Greetings Shiv,<BR>> <BR>> If we use ECN to distinguish between congestion
and loss, how can we<BR>> detect that "there is loss that is caused due to congestion on the<BR>> path (and ECN signals are absent)" and know to revert to TCP-SACK?<BR>> <BR>> The problem is that the flow may be ECN-enabled, and there may be (a)<BR>> some ECN packets, (b) some packets lost due to corruption, and (c)<BR>> some packets lost due to congestion of a non-ECN queue. How can we<BR>> distinguish (b) from (c)?<BR>> <BR>> Thanks,<BR>> Lachlan<BR>> <BR>> On 08/08/2007, Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu> wrote:<BR>> ><BR>> > If ECN is used, the likelihood of congestion related loss may be<BR>> > minimized. However, if there is congestion related loss, because<BR>> either<BR>> > ECN is absent, or there are also end-systems that do not respond to<BR>> ECN,<BR>> > then LT-TCP will have a robust method for safely reverting back to<BR>> > TCP-SACK
behavior. When there is loss that is caused due to<BR>> congestion<BR>> > on the path (and ECN signals are absent), LT-TCP will revert back to<BR>> > TCP-SACK.<BR>> <BR>> > best<BR>> > -Shiv<BR>> ><BR>> > On Mon, 6 Aug 2007, Michael Welzl wrote:<BR>> ><BR>> > > in the presence of<BR>> > > packet loss (which can always be due to an overflowing queue,<BR>> > > ECN notwithstanding), the right thing to do is to assume<BR>> congestion.<BR>> <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<BR>> <BR>> _______________________________________________<BR>> Iccrg mailing list<BR>> Iccrg@cs.ucl.ac.uk<BR>> <A href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg"
target=_blank>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</A><BR>> <BR>> <BR>> <BR>> <BR>> ______________________________________________________________________<BR>> Shape Yahoo! in your own image. Join our Network Research Panel today!<BR>> _______________________________________________<BR>> Iccrg mailing list<BR>> Iccrg@cs.ucl.ac.uk<BR>> <A href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target=_blank>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</A></DIV></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1>Fussy? Opinionated? Impossible to please? Perfect. <a href="http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ">Join Yahoo!'s user panel</a> and lay it on us.
</body></html>