[e2e] Congestion control as a hot topic in IETF

[Jon Crowcroft]

actually lost of links have a clock 
but that's neither here nor there

what you don't know is the 
other traffic demand on the net
in a non work-conserving, stat muxed world, 
so you have to elicit
feedback on what is nicely called sometimes
the _shadow price_ of your traffic.

the work of frank kelly is 
required reading round here in that regard:
http://www.statslab.cam.ac.uk/~frank/PAPERS/

the optimisation frameworks have also been aired 
by a few other groups (caltech etc) and the 
math is pretty persusasive...

the details of how you build protocols that do this 
a la KK ramakrishnan and raj jain et al's work at DEC, 
then Van's work on TCP are just that - protocol details - 
and surely newerer things like ECN (re-ecn, congestion exposure
etc) and codel/bql etc can improve things closer to optimal

if you want a circuit setup/open loop control, 
you need to invoke a lot of other mechanism as well 
(fancy switch schedulers, admission control, policers, pricing etc) 
to get to the same level of deployability,
which are explicitly more complex system wide 
so have largely fallen by the wayside in many networks....

nature abhors a circuit, if you ask me....
ad the corrolary is that you better have a 
congestion avoidance and control scheme
or live with long periods of massive packet loss
and little progress

(or: if god had wanted us to use connection oriented networks, 
it would have been listed in the commandments)

In missive <5135A361.1070702 at web.de>, Detlef Bosau typed:

 >>Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael):
 >>> There has been some interesting research on whether a transport protocol could work without any congestion control. One reference is: B. Raghavan and A. Snoeren, "Decongestion Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006.
 >>>
 >>I remember that you, some years ago, asked whether networking can be 
 >>done without flow control.
 >>
 >>O.k. I just asked my provider to give me some additional space for my 
 >>mailbox and claim the following:
 >>
 >>Congestion control is necessary, because when God created cabling and 
 >>fibre, he forgot to give them a mouth to talk.
 >>So, we actually don't know how much data can reside, if transient, on 
 >>the line. And NB: This is anything else but a trivial question.
 >>Particularly on mobile networks, we have only little knowledge about the 
 >>transient channel capacity (you might remember some personal discussions 
 >>between us two about 8, 9 years ago), if at all. The same holds true for 
 >>shared networks e.g. Ethernet, particularly the good old yellow garden hose.
 >>
 >>So, actually, the only way to assess whether the amount of  data send to 
 >>a "media" stays within "acceptable limits" is, simply spoken, trial and 
 >>error.
 >>Either it fits - or it is dropped.
 >>
 >>Depending on the link technology in use, this situation may vary. 
 >>However, the fundamental problem is generic.
 >>
 >>While receivers can talk, perhaps God spent more time in creating them, 
 >>flow control is easier.
 >>
 >>Congestion control is achieved indirectly and - to make things worse - 
 >>it is strongly intertwined with scheduling.
 >>
 >>Particularly, VJCC attempts to extend TCP's "self clocking" into a "self 
 >>scheduling" which is cumbersome because self scheduling requires 
 >>sufficient space for the data to be interleaved to be put. I strongly 
 >>suspect that the latter is a sufficient reason for what we often call 
 >>"buffer bloat".
 >>
 >>
 >>Detlef
 >>
 >>-- 
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistraße 30
 >>70565 Stuttgart                            Tel.:   +49 711 5208031
 >>                                            mobile: +49 172 6819937
 >>                                            skype:     detlef.bosau
 >>                                            ICQ:          566129673
 >>detlef.bosau at web.de                     http://www.detlef-bosau.de
 >>

 cheers

   jon