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

Dirceu Cavendish dirceu_cavendish at yahoo.com
Wed Apr 2 20:06:54 BST 2008 

Matt,

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.

Boy, you touched a lot of pending issues. From the description, participants zeroed to the right points.
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 http://cavendish.homedns.org/ControlTheoreticalCC.pdf  under scheduling schemes, for a discussion on queueing disciplines and closed loop congestion control).

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...

Dirceu


----- Original Message ----
From: Matt Mathis <mathis at psc.edu>
To: iccrg at cs.ucl.ac.uk
Sent: Wednesday, April 2, 2008 9:35:11 AM
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
Iccrg at cs.ucl.ac.uk
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080402/c37cba8b/attachment.html

More information about the Iccrg mailing list