<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:10pt"><DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">Matt,</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">First of all, that you very much for the "summary" of the event. For those like myself, who were not able to attend, this is valuable.</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">Boy, you touched a lot of pending issues. From the description, participants zeroed to the right points.</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">RTT fairness...It is a idealistic concept, but NOT real. Not today (with TCP bias towards short RTT sessions), not ever (UNLESS we assume PER-session queueing in the routers, and dimension their buffers according to their respective RTT - see <A href="http://cavendish.homedns.org/ControlTheoreticalCC.pdf">http://cavendish.homedns.org/ControlTheoreticalCC.pdf</A> under scheduling schemes, for a discussion on queueing disciplines and closed loop congestion control).</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif">About network protection, I couldnt agree more. I have seen TCP "nice" proposals, where router buffers are conservatively kept low, impacting session throughput, that people argue about why would anyone use a TCP that steps back in face of more aggressive protocols, even legacy ones...</DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"> </DIV>
<DIV style="FONT-SIZE: 10pt; 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: Matt Mathis <mathis@psc.edu><BR>To: iccrg@cs.ucl.ac.uk<BR>Sent: Wednesday, April 2, 2008 9:35:11 AM<BR>Subject: [Iccrg] Heresy following "TCP: Train-wreck"<BR><BR>I just attended the "The Future of TCP: Train-wreck or Evolution?" at Stanford <BR>last week, and it solidified my thoughts on a subject that is sure to be <BR>controversial.<BR><BR>I think it is time to abandon the concept of "TCP-Friendly" and instead expect <BR>the network to protect itself and other users from aggressive protocols and <BR>applications. For the moment I am going to assume two mechanisms, although I <BR>suspect that there will prove to be more.<BR><BR>1) Deploy some form of Fair Queuing at the edges of the network.<BR><BR>2) Protect the core by bottlenecks at the edges of the Internet.<BR><BR>I observe that both of these mechanisms are already
being implemented due to <BR>existing market forces, and the natural consequence of their implementation is <BR>to make TCP-friendliness a whole lot less important. I admit that it is not <BR>clear at this point if these two mechanisms will ultimately prove to be <BR>sufficient to address fairness all situations, such as over loaded core <BR>routers, but I suspect that sufficient mechanisms do exist.<BR><BR>Supporting arguments:<BR><BR>FQ is already being deployed at the edges to solve several existing and <BR>growing fairness problems:<BR><BR>* Non-IETF, UDP protocols that are non-responsive.<BR><BR>* P2P and other applications that open huge numbers of connections.<BR><BR>* Stock TCP is egregiously unfair when very short RTT flows compete with wide<BR> area flows. This can be a real killer in a number of settings such as data<BR> centers and university campuses. The symptoms of this problem will become<BR> more
pronounced as TCP autotuning continues to be rolled out in Vista,<BR> Linux, and various BSDs.<BR><BR>* Autotuning will also greatly magnify RFC 2309 [1] problems, since every<BR> single TCP flow with sufficient data will cause congestion somewhere in the<BR> network. At the very least this will gradually force the retirement of<BR> drop-tail equipment, creating the opportunity for RED and/or FQ. Since RED<BR> by itself is insufficient to solve the other fairness problems, it will not<BR> be the first choice replacement.<BR><BR>I should note that "Fair Queuing"is overly specific. The network needs to do <BR>something to large flows to prevent them from overwhelming smaller flows and <BR>to limit queue occupancy. FQ is one way, but there are others.<BR><BR>If you have ever shared a drop-tail home router with a teenager, you might <BR>have observed some of these issues first hand, as has
Comcast.[2] As I <BR>understand it, some form of enforced fairness is now part of all commercial <BR>broadband services.<BR><BR>The core of the Internet is already mostly protected by bottlenecks at the <BR>edges. This is because ISPs can balance the allocation of revenue from <BR>customers between the relatively expensive access link, its own backbone links <BR>and interconnections to other ISPs. Since congestion in the core has proven <BR>to cause complaints from commercial customers (and perhaps SLA problems), most <BR>providers are careful to keep adequate capacity in the core, and can do so <BR>pretty easily, as long as their duty cycle models hold true.<BR><BR>Are these two mechanisms sufficient to make TCP-friendliness completely moot? <BR>Probably not.<BR><BR>We still have some work to do:<BR><BR>First, stop whining about non-TCP-friendly protocols. The are here to stay <BR>and they can't hear us. We are wasting our
breath and impeding real progress <BR>in well designed alternatives to "TCP-friendly". This concept came from an <BR>era when the Internet was a gentleman's club, but now it needs to be retired.<BR><BR>Second, blame the network when the network deserves it. In particular if <BR>there are drop tail queues without AQM, be very suspicious of RFC2309 <BR>problems. In fact every drop tail queue without AQM should be viewed as a bug <BR>waiting to bite someone. Likewise remember that "TCP-friendly" is extremely <BR>unfair when the RTTs are extremely different.<BR><BR>Third, think about the hard cases: over loaded interconnects, failure <BR>conditions, etc. Can FQ be approximated at core scales? Where else are my <BR>proposed mechanisms insufficient? I sure there are some.<BR><BR>Fourth, start dreaming about what it would take to make Moore's law apply to <BR>end-to-end protocol performance, as it does to just about
everything else in <BR>the computing universe. I suspect that in some future hindsight, we will come <BR>to realize that TCP-friendly was actually a untenable position, and has held <BR>us back from important innovations.<BR><BR>[1] RFC2309 "Recommendations on Queue Management and Congestion Avoidance in <BR>the Internet", Bob Braden, et al.<BR><BR>[2] Richard Bennett "New and Improved Traffic Shaping" <BR><A href="http://bennett.com/blog/index.php/archives/2008/03/27/new-and-improved-traffic-shaping/" target=_blank>http://bennett.com/blog/index.php/archives/2008/03/27/new-and-improved-traffic-shaping/</A><BR>------------------<BR><BR>It was a very stimulating conference!<BR>Thanks Nandita and everyone else who made it happen!<BR>--MM--<BR>-------------------------------------------<BR>Matt Mathis <A href="http://staff.psc.edu/mathis" target=_blank>http://staff.psc.edu/mathis</A><BR>Work:412.268.3319
Home/Cell:412.654.7529<BR>-------------------------------------------<BR><BR><BR>_______________________________________________<BR>Iccrg mailing list<BR><A href="mailto:Iccrg@cs.ucl.ac.uk" ymailto="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</A><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></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: times new roman, new york, times, serif"><BR></DIV></div><br>
<hr size=1>You rock. That's why Blockbuster's offering you <a href="http://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com">one month of Blockbuster Total Access</a>, No Cost.</body></html>