[e2e] Congestion control as a hot topic in IETF
Jon.Crowcroft at cl.cam.ac.uk
Tue Mar 5 23:20:43 PST 2013
congestion control does work on some single links if the link layer
supports a congestion feedback mechanism - switched ethernet (for
example) has a feedback mechanism and some people have used this in
data center modifications and used it to push the later 2 feedback
up (as well as back) to IP/TCP - ie trigger ECN from the layer 2
this could easily also be done with contention information in
conventional and wireless ethernet on a single link
and could be triggerd from a cellular base station too if
but it isn't
but it could be...
given the impossibility (without precognition) of knowing who else is
just about to send on a wireless link, and the bursty nature of human
and software behaviour
it seems that this would be a more useful direction to fix things in
than other (more old fashioned and less efficient, c.f. keshav's
message )approaches -
In missive <51361FF1.8050208 at web.de>, Detlef Bosau typed:
>>Am 05.03.2013 13:07, schrieb Scharf, Michael (Michael):
>>>> 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.
>>> My comment is about network designs that typically assume erasure codes=
>> and flow-based queueing/scheduling in all network nodes. Actually, it to=
>>ok me a while to fully understand why this is no alternative to the way I=
>>nternet congestion control works today. But, for what it is worth, I foun=
>>d the overall idea intesting.
>>It's perhaps not the focus of this discussion, but you perhaps remember=20
>>our private discussion years ago, where I started to make a difference=20
>>between bandwidth and throughput, particularly as the "throughput delay=20
>>product" is something completely different from the "bandwidth delay=20
>>product". These are perhaps no central aspects of our discussion,=20
>>however it somehow illustrates where some of the confusion may come from.
>>And I made quite some turnarounds myself during the last years. Starting=20
>>from mobile networks, as you may remember, ending up in the insight that=20
>>VJCC does not really work with a single mobile wireless link=20
>>(!!!!!!!!!!!!!!!) and that this does not change if we put 30 wired links=20
>>in advance of the mobile one and 50 other behind - and then argue that=20
>>VJCC will work end to end.
>>No. Like in maths, one counterexample disproves a theorem.
>>However, different from math, VJCC is not a theorem but a mechanism=20
>>based upon quite some, if implicit, assumptions. So it may well be, and=20
>>actually is the case, that these assumptions do not hold in some network=20
>>so VJCC is not applicable and may lead to unwanted results.
>>This is no way a disaster, it is some kind of collective learning.
>>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
More information about the end2end-interest