<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,<BR><BR>
<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 9:13:55 AM<BR>Subject: Re: [Iccrg] LT-TCP followup<BR><BR>
<DIV>>Various TCP variants today track rtts, which would allow differentiation<BR>between corruption loss and overflow loss. >Obviously, in a extremely worst<BR>case scenario, a packet loss overflow could occur at a single packet with no<BR>"rtt >evidence" (rtt increase) on "surrounding" packets of a TCP stream. But<BR>IMHO most of the scenarios I've seen, the rtt >increase evidence is there.<BR><BR>i know, and I think I didn't say anything to discourage using other<BR>implicit feedback too; this being said, rtt increase is misleading too,<BR>how do you distinguish a growing queue from link layer arq happening<BR>because of corruption?<BR></DIV>
<DIV><DC> You may not WANT to distinguish between a L2 queue increase due to L2 corruption recovery schemes and a L3 router queue overflow. For instance, a L2 with retransmission may signal corruption to higher layers exactly by overflowing its interface queues. One can look at that as L2 corruption causing a decrease in the L2 link capacity, causing "congestion", similar to an AMC wireless link, that changes its coding/bit rate in response to channel fading.</DIV>
<DIV> </DIV>
<DIV>Dirceu</DIV>
<DIV></DC><BR><BR>>Notice that mistakenly taken a corruption loss as overflow loss does not<BR>necessarily have to have a big impact on a TCP >session. It is bad enough<BR>for VJ (alpha=2) TCP, but other controllers can be much more "immune" to<BR>sporadic "misreading" >of packet loss information.<BR><BR>ok, i can imagine that<BR><BR>cheers<BR>michael</DIV></DIV><BR></DIV></div><br>
<hr size=1>Luggage? GPS? Comic books? <br>
Check out fitting <a href="http://us.rd.yahoo.com/evt=48249/*http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz"> gifts for grads</a> at Yahoo! Search.</body></html>