Re: Congestion control as a hot topic in IETF
Jon Crowcroft <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>, 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 >>[email protected] http://www.detlef-bosau.de >> cheers jon