<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">Dear Andrew,</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">I sense we are in violent agreement in various points, although coming from different perspectives. See below...<BR><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Lachlan Andrew <lachlan.andrew@gmail.com><BR>To: Dirceu Cavendish <dirceu_cavendish@yahoo.com><BR>Cc: iccrg@cs.ucl.ac.uk<BR>Sent: Thursday, August 9, 2007 2:28:27 PM<BR>Subject: Re: [Iccrg] LT-TCP followup<BR><BR>
<DIV>Greetings Dirceu,<BR><BR>On 09/08/07, Dirceu Cavendish <dirceu_cavendish@yahoo.com> wrote:<BR>> So it makes sense to me to ask: "how well can we design a CC scheme<BR>> with as little new features from routers as possible?"<BR><BR>Agreed. Larry Dunn has convinced me of that.<BR><BR>My point was that we ideally don't want to design protocols which<BR>*rely* on undesirable artefacts of current networks, which we might<BR>otherwise want (and be able) to get rid of. One such artefact is that<BR>current networks have very long queueing delay during congestion<BR>(because of Reno's "need" for bandwidth-delay droptail buffers).<BR></DIV>
<DIV><DC> Agree. CC protocols that maitain a high queueing delay are not desirable. I</DIV>
<DIV>alluded to that as "operating points" of a cc scheme in my presentation in Chicago. Due to the inherent template of AIMD based on packet loss/no-loss detection, many TCPs tend to operate at heavy queue filling levels. But the operating point of a cc scheme can be tuned to low queueing delays as well. This is a matter of design.</DIV>
<DIV></DC></DIV>
<DIV><BR>> Explicit signalling requires specific<BR>> router behavior from the get go, AND it is difficult to guarantee anything<BR>> if not adopted by all routers on a session path.<BR><BR>That is true if the explicit signalling is used to say "slow down".<BR>What Michael proposed was something to say "*don't* slow down, that<BR>wasn't congestion". The absence of that signal doesn't break<BR>anything.<BR></DIV>
<DIV><DC> Agree. But some people also advocate that L2 corruption loss should cause rate reduction, as a thread on this list has shown. In this context, then, I assume a router would decide that THAT particular corruption loss was spurious, hence a drastic rate/window reduction should not be exercised.</DIV>
<DIV></DC></DIV>
<DIV><BR>If a single router on the path knows that it is wireless, and likely<BR>to drop packets without congestion, then even if only that one router<BR>implements the signalling, then we avoid unnecessary window halving.<BR>The wireline/core routers needn't be touched.<BR></DIV>
<DIV><DC> Agree once more. However, persistent corruption losses in an AMC channel may trigger a mode change, with wireless service capacity reduction. In this scenario, it makes sense to me that the TCP sources slow down, as service bit rate has significantly reduced ( at a likely session bottleneck).</DIV>
<DIV></DC></DIV>
<DIV><BR>Conversely, consider the case of implicit signalling: A single<BR>congested queue drops many packets without introducing queueing delay<BR>(perhaps it has a small buffer). If this treated as heavy<BR>"corruption" by the congestion control, then the source doesn't slow<BR>down enough, and congestion persists.<BR></DIV>
<DIV><DC> Lets take the extreme case. Wireless channel, with no storage space whatsoever. If it is an adaptive channel (AMC), the channel will reduce its modulation rate in order to achieve an acceptable BER. If not, the wireless channel may indeed become a black hole. In this case, rate reduction is unlikely to help, and the TCP should and will take more drastic action (e.g., new slow start), triggered by RTOs, excessive retransmissions, etc...</DIV>
<DIV></DC></DIV>
<DIV><BR>(Minor comments below.)<BR><BR>Cheers,<BR>Lachlan<BR><BR>> specific router behavior may interfere with some such passive schemes.<BR>> But that is the same as specific receiver misbehavior (either maliciously or<BR>> not).<BR><BR>Sort of... If we can devise a way for routers not to delay packets<BR>despite persistent congestion, that is "progress", not "misbehaviour".<BR>However, if it causes all losses to be treated as non-congestion<BR>losses and so breaks congestion control, it is likely to be<BR>"disallowed" by the IETF.<BR><BR>> I guess it is widespread consensus today that complexity at the end points<BR>> is best, so routers should keep its simplicity<BR><BR>Yes, although wireless devices are likely to be cheap/simple devices.<BR>It was pointed out at the open mike session in Chicago that this<BR>particular "axiom" was just a description of what suited the 1980s<BR>networks, and should be reconsidered
now. (Not necessarily changed,<BR>just reconsidered.)<BR></DIV>
<DIV><DC> Just want to state that I am not all for dirty cheap routers, but simply routers where added complexity is well justified.</DIV>
<DIV></DC></DIV>
<DIV><BR>> Fortunately most routers adopt droptail queues.<BR><BR>Why is it that fortunate? It ensures large queueing delays and makes<BR>ECN impossible (increasing loss/inefficiency).<BR></DIV>
<DIV><DC> Not necessarily. If you assume current TCPs, than I can see your concern. That is, if TCPs slow down only as a reaction to packet drop, then routers should signal "random" drops in advance in order to keep their queues at low filling levels. But IMO it is much easier to fix and end-point behavior so as to shift the cc operating point to a low queueing delay, than to instruct every router to try and trigger a rate reduction in order to keep their buffers' level low, which to me amounts to try to "fool" TCP senders into believing that router queues are about to overflow. In any event, let me restate that I agree that large queues are not the desirable operating point of a session/network.</DIV>
<DIV></DC></DIV>
<DIV><BR>> I am not advocating routers<BR>> imposing "unecessary queue delays" (I am not sure what you mean by that)<BR><BR>As I pointed out, routers which drop packets based on a virtual queue<BR>will not incur queueing delays when they are congested. Any queueing<BR>delay which is not due to the buffer smoothing packet-level burstiness<BR>is unnecessary.<BR><BR>(An example of a protocol which forces unncessary queueing delay is<BR>Reno, which forces people to buffer one bandwidth-delay product of<BR>data so that a single flow can get high utilisation. If we didn't use<BR>Reno, queueing delays would be much smaller, improving user QoS.)<BR></DIV>
<DIV><DC> Again, I concur with your point. I am just not sure that I agree with the remedy. However, there can be many solutions to decreasing queueing delays in a TCP session, so we dont need to agree on a single one (but hopefully will understand each other's solution :-). Our experience with Reno shows a "medium" bottleneck queue utilization (filling level). There are less agressive protocols (our :-), CCP), and more aggressive ones (Fast).</DIV>
<DIV> </DIV>
<DIV>Dirceu</DIV>
<DIV></DC></DIV>
<DIV><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</DIV></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1>Be a better Heartthrob. <a href="http://us.rd.yahoo.com/evt=48255/*http://answers.yahoo.com/dir/_ylc=X3oDMTI5MGx2aThyBF9TAzIxMTU1MDAzNTIEX3MDMzk2NTQ1MTAzBHNlYwNCQUJwaWxsYXJfTklfMzYwBHNsawNQcm9kdWN0X3F1ZXN0aW9uX3BhZ2U-?link=list&sid=396545433">Get better relationship answers </a>from someone who knows.<br>Yahoo! Answers - Check it out.
</body></html>