[e2e] Congestion control as a hot topic in IETF

[Jon Crowcroft]

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 
you like

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.
 >>>
 >>> Michael
 >>
 >>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.
 >>
 >>
 >>--=20
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistra=DFe 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