Hi Roland + others. As regards to comments around other new congestion control algorithms and that they may need adapted dropping likelihood relation between a classic queue and L4S queue. I have not tried out but I suspect that BBR may get an unfair treatment, at the same time it is possible that other delay based CCs may suffer.
They question however if this is a major problem?, one may as well see this as an incentive to switch over to scalable congestion controls and L4S ? There is after all no requirement to stick to a particular congestion control no matter what. ? The question whether or not endpoint dependency should be built into the networks is of course a valid question but given that the state of the art congestion controls like Reno and Cubic rely on a 1/sqrt(p) function then that is perhaps OK ?. There will for a foreseeable time come updated endpoint based congestion control algorithms that are optimized for one thing or the other (I am guilty too :-). However if one can distinguish between two classes (classic and L4S) where classic belong to the 1/sqrt(p) family then I believe that it is possible to solve the problem. If we try find a solution where classic = "all sorts of non-scalable non-L4S dependent congestion controls" then I believe that we easily end up in big problems. /Ingemar > -----Original Message----- > From: Bless, Roland (TM) [mailto:roland.bl...@kit.edu] > Sent: den 21 november 2016 15:28 > To: Bob Briscoe <i...@bobbriscoe.net>; tsvwg IETF list <ts...@ietf.org>; > TCP Prague List <tcppra...@ietf.org>; AQM IETF list <aqm@ietf.org>; tcpm > IETF list <t...@ietf.org> > Subject: Re: [tcpPrague] [aqm] L4S status update > > Hi Bob and all, > > see below. > > Am 01.11.2016 um 01:02 schrieb Bob Briscoe: > > A few people have been working away to specify and document all the > > aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) > > service, which held a successful BoF in Berlin. As the decision was to > > try to work across multiple WGs, I thought it would be useful to give ... > > Thanks for putting this together. > > > * Dual Queue Coupled AQM > > o With Curvy RED for Linux (access available shortly) > > o With PI2 for Linux <https://github.com/olgabo/dualpi2> > > [*UPDATED*] > > I'll repeat my concerns that I already expressed at the L4S BOF in Berlin: > > While I agree that we probably need to separate low-delay congestion > control schemes from traditional "queue-filling" congestion schemes, I > strongly suggest to avoid putting a congestion control-specific coupling > scheme into the network (a classic case for applying the "end-to-end > arguments in system design"). > The current Dual queue coupled AQM proposal has got a coupling based on a > congestion control specific dropping law p_C=(p_L/2)². So if congestion > control schemes change then this coupling needs to be adapted. For > example, the currently proposed scheme may fail if that vast majority of TCP > traffic is using BBR other some other forthcoming CC scheme instead of > Cubic, Reno, Compound etc. The same applies to draft-briscoe-tsvwg-ecn- > l4s-id, section 2.5, where the dropping likelihood is defined. > > Regards, > Roland > _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm