Hi Roland, I agree with everything, except in your email below, everywhere:
s/delay/delay or ECN I state this because it’s my opinion but also to hopefully prevent a flood of long emails related to ECN… Cheers, Michael > On Mar 31, 2017, at 8:41 AM, Bless, Roland (TM) <[email protected]> wrote: > > Hi, > > thanks to the session recordings I just listened to the very > interesting ICCRG related discussion in the tsvarea meeting from > Monday. > > Lars Eggert said something like: > "Bufferbloat is something that a congestion controller > can't really do anything about anyway... > it's not necessarily a congestion control problem." > > I believe that this statement is not correct. > A large buffer will not be filled completely by a delay-based > congestion control (e.g., Vegas was a very early > one). Thus even if the buffer is large, the queuing > delay doesn't increase dramatically and we wouldn't > see that bufferbloat effect so prominently (as in slide 3 of > https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-reflections-on-congestion-control-praveen-balasubramanian-00.pdf). > > So if _everyone_ would use such a delay-based variant, we wouldn't > have the bufferbloat problem. > > However, since we have more loss-based congestion control variants > deployed, which will fill a tail-drop buffer completely, such > delay-based variants get suppressed and cannot get a reasonable share > of the bottleneck bandwidth. Therefore, several variants have a > fallback to a more aggressive mode in order to get a reasonable > share (I think Christian Huitema also referred to this by the different > modes). What could help is some kind of co-existence mechanism that > separates queue-filling TCP CC variants from delay-based variants > (e.g., see http://ieeexplore.ieee.org/document/7796842/ for details). > So IMHO getting rid of the queue filling variants would be useful, > but is probably hard in practice, i.e., replacing them isn't easy > due to the co-existence problem. > > Consequently, fighting against bufferbloat could be done in the network > using AQMs (enforcing shorter queues) or by using a different > congestion control algorithm (trying to limit inflicted queuing delay), > or even by a combination of both. However, what delay and throughput > performance can be achieved with AQMs is limited, so better performance > in both metrics requires eventually a better congestion control algorithm. > > Regards, > Roland > > _______________________________________________ > iccrg mailing list > [email protected] > https://www.irtf.org/mailman/listinfo/iccrg
