[Iccrg] Heresy following "TCP: Train-wreck"

Matt Mathis mathis at psc.edu
Wed Apr 2 17:35:11 BST 2008

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 

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" 

It was a very stimulating conference!
Thanks Nandita and everyone else who made it happen!
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529

More information about the Iccrg mailing list