Hi Ingemar, my point was that it's probably better to refrain from building CC-specific behavior into network elements as the CC algorithms may evolve faster and in more flexible ways than we can foresee. Thus, it would be good to have a separation (or coupling) scheme that actually doesn't depend on the 1/sqrt(p) dropping law.
Am 22.11.2016 um 15:35 schrieb Ingemar Johansson S: > 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. It would be interesting to see what happens if BBR is sorted into the L4S queue in comparison to what happens if BBR is sorted into the classic queue (BBR isn't reacting to loss according to 1/sqrt(p)). > 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. ? Yes, and that's why I find that built-in coupling law too limiting. > 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. I'm not sure. Maybe we have a class of "queue-filling" CCs and a class of low-delay targeted CCs. Regards, Roland _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
