Subject: [tsv-area] Fwd: [Iccrg] Heresy following "TCP: Train-wreck"

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Apr 2008 07:28:25 +0300

Hi,

FYI, the following message from the ICCRG list is related to the topic  
of several presentations we've had in TSVAREA and TSVWG.

Please keep the discussion on [email-masked] (Reply-to set  
accordingly.)

Lars

Begin forwarded message:
> From: "ext Matt Mathis" <[email-masked]>
> Date: April 2, 2008 19:35:11 GMT+03:00
> To: [email-masked]
> Subject: [Iccrg] Heresy following "TCP: Train-wreck"
>
> I just attended the "The Future of TCP: Train-wreck or Evolution?"  
> at Stanford last week, and it solidified my thoughts on a subject  
> that is sure to be controversial.
>
> I think it is time to abandon the concept of "TCP-Friendly" and  
> instead expect the network to protect itself and other users from  
> aggressive protocols and applications.  For the moment I am going to  
> assume two mechanisms, although I suspect that there will prove to  
> be more.
>
> 1) Deploy some form of Fair Queuing at the edges of the network.
>
> 2) Protect the core by bottlenecks at the edges of the Internet.
>
> I observe that both of these mechanisms are already being  
> implemented due to existing market forces, and the natural  
> consequence of their implementation is to make TCP-friendliness a  
> whole lot less important.  I admit that it is not clear at this  
> point if these two mechanisms will ultimately prove to be sufficient  
> to address fairness all situations, such as over loaded core  
> routers, but I suspect that sufficient mechanisms do exist.
>
> Supporting arguments:
>
> FQ is already being deployed at the edges to solve several existing  
> and growing fairness problems:
>
> * Non-IETF, UDP protocols that are non-responsive.
>
> * P2P and other applications that open huge numbers of connections.
>
> * Stock TCP is egregiously unfair when very short RTT flows compete  
> with wide
>  area flows.  This can be a real killer in a number of settings such  
> as data
>  centers and university campuses.  The symptoms of this problem will  
> become
>  more pronounced as TCP autotuning continues to be rolled out in  
> Vista,
>  Linux, and various BSDs.
>
> * Autotuning will also greatly magnify RFC 2309 [1] problems, since  
> every
>  single TCP flow with sufficient data will cause congestion  
> somewhere in the
>  network.  At the very least this will gradually force the  
> retirement of
>  drop-tail equipment, creating the opportunity for RED and/or FQ.   
> Since RED
>  by itself is insufficient to solve the other fairness problems, it  
> will not
>  be the first choice replacement.
>
> I should note that "Fair Queuing"is overly specific.  The network  
> needs to do something to large flows to prevent them from  
> overwhelming smaller flows and to limit queue occupancy.  FQ is one  
> way, but there are others.
>
> If you have ever shared a drop-tail home router with a teenager, you  
> might have observed some of these issues first hand, as has Comcast. 
> [2] As I understand it, some form of enforced fairness is now part  
> of all commercial broadband services.
>
> The core of the Internet is already mostly protected by bottlenecks  
> at the edges.  This is because ISPs can balance the allocation of  
> revenue from customers between the relatively expensive access link,  
> its own backbone links and interconnections to other ISPs.  Since  
> congestion in the core has proven to cause complaints from  
> commercial customers (and perhaps SLA problems), most providers are  
> careful to keep adequate capacity in the core, and can do so pretty  
> easily, as long as their duty cycle models hold true.
>
> Are these two mechanisms sufficient to make TCP-friendliness  
> completely moot? Probably not.
>
> We still have some work to do:
>
> First, stop whining about non-TCP-friendly protocols.  The are here  
> to stay and they can't hear us.  We are wasting our breath and  
> impeding real progress in well designed alternatives to "TCP- 
> friendly".  This concept came from an era when the Internet was a  
> gentleman's club, but now it needs to be retired.
>
> Second, blame the network when the network deserves it.  In  
> particular if there are drop tail queues without AQM, be very  
> suspicious of RFC2309 problems.  In fact every drop tail queue  
> without AQM should be viewed as a bug waiting to bite someone.   
> Likewise remember that "TCP-friendly" is extremely unfair when the  
> RTTs are extremely different.
>
> Third, think about the hard cases: over loaded interconnects,  
> failure conditions, etc.  Can FQ be approximated at core scales?   
> Where else are my proposed mechanisms insufficient?  I sure there  
> are some.
>
> Fourth, start dreaming about what it would take to make Moore's law  
> apply to end-to-end protocol performance, as it does to just about  
> everything else in the computing universe.  I suspect that in some  
> future hindsight, we will come to realize that TCP-friendly was  
> actually a untenable position, and has held us back from important  
> innovations.
>
> [1] RFC2309 "Recommendations on Queue Management and Congestion  
> Avoidance in the Internet", Bob Braden, et al.
>
> [2] Richard Bennett "New and Improved Traffic Shaping" http://bennett.com/blog/index.php/archives/2008/03/27/new-and-improved-traffic-shaping/
> ------------------
>
> It was a very stimulating conference!
> Thanks Nandita and everyone else who made it happen!
> --MM--
> -------------------------------------------
> Matt Mathis     http://staff.psc.edu/mathis
> Work:412.268.3319    Home/Cell:412.654.7529
> -------------------------------------------
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg