[e2e] Congestion control as a hot topic in IETF

[Jon Crowcroft]

I doubt anyone shipping any OS with a TCP (or any other significant
transport) in is about to turn off congestion control - 

the folks that do tcp in linux/android, OSX/IOS, BSD, Windows etc
are probably a bit beyond ietf unicycles or naive market and 
commons arguments these days - 
the details of engineering a protocol to work across 
10Gbps multicore systems in data centers and on 2.5/3/4G
cellular are important and complex enough that we've become
irrelevant here:)
[if you want to see where the hot topics are, 
the usual top conferences have a slew of 
papers n the last 2-3 years on
even cleverer tcp hacks to solve
incast and tight delay bounds
requirements, as well as some ok work 
on bufferbloat (whether it happens 
much or not, and various ways to fix it )

that said, anyone wanting 
to witness congestion collapse should please
only try the experiment in their own back yard 
and not release "working code" in the wild in a hurry, 
as they'll find the consensus will be very rough
on them

back in the day, 
(why even more than 10 years after the dreaded
congestion collapse and 
its repair by congestion control but still in
the last millenium)
I remember ISPs disconnecting users who 
ran tcp-unfriendly flows... 

that was the micro-ecnomic version 
of the rationale for disconnecting
users who run p2p and mess with the 
ISPs traffic engineering and
peering arrangements...

you wouldn't get in an airplane today 
that did not have feedback controllers
stabilising its flight autonomically - 

why would you drive on the interweb
without such technological safety measures?

maybe no-one ever made money from this stuff,
but an awful lot of people would
lose their shirts if we stopped
using it.


In missive <51351F2E.9050808 at dcrocker.net>, Dave Crocker typed:

 >>
 >>On 3/4/2013 9:45 AM, Bob Braden wrote:
 >>> It seems like an interesting question for research to determine
 >>> whether widespread adoption of some future transport protocol with an
 >>> ill-advised or inadequate CC mechanism could still cause congestion
 >>> collapse of  large areas of the Internet,or only local patches.
 >>
 >>
 >>That seems a particularly counter-productive strawman to pursue.
 >>
 >>There is no community dismissal of the need for good CC mechanisms. 
 >>There is no reduction in community review of proposals.  There is no 
 >>leverage to force the community to deploy bad CC mechanisms.
 >>
 >>Stray comments from stray individuals do not create a problem.  Unless 
 >>we let them distract us.
 >>
 >>So please don't start believing that we have any more danger of 
 >>deploying bad mechanisms now than we've had for the last 40 years.
 >>
 >>d/
 >>-- 
 >>  Dave Crocker
 >>  Brandenburg InternetWorking
 >>  bbiw.net

 cheers

   jon