> On 15 Mar, 2019, at 4:44 pm, Sebastian Moeller <moell...@gmx.de> wrote: > > In essence, they do not want to deal with the diffserv mess under the > end-to-end perspective and making it reliable.
Yeah, that's pretty much what I thought. Diffserv really does need to be fixed sometime. >> But Codel-type AQMs don't provide the ideal ECN signal for L4S (and nor do >> RED-type AQMs without specific tuning for L4S), and any single-queue AQM is >> going to end up with L4S flows outcompeting standard ones quite seriously. > > Except L$S flows are required to "degrade" to classic congestion contro once > they have proof of not being handled by a l4s aware AQM, like real packet > drops or ECT(0) + CE... That isn't enough, because ECN AQMs as presently specified won't change ECT(1) to ECT(0) (nor will SCE), and it would require a lot of overload before dropping actually started. So those signals don't reliably identify a legacy AQM. > L4S would find uses for SCE, but that still faces the same roll-out issue... It's not the same roll-out issue, because in an SCE context L4S would have to be legacy-compatible by default, and only employ the "new" behaviour when SCE information appears - the reverse of its present behaviour - which then makes it backwards compatible and incrementally deployable. The real snag is that DCTCP's setpoint is 2 marks per RTT, which is different from SCE's specified setpoint of 50% packets marked (unless the cwnd is down to 4 packets). That'd make it difficult for a straight port of DCTCP to SCE to achieve full throughput. A sane compromise could be for SCE to be marked in the same way as L4S marks CE, and a valid interpretation of SCE to follow the 1/n response of DCTCP. That would leverage existing TCP-Prague R&D, but in a backwards-compatible, incrementally-deployable manner. Perhaps that's something worth discussing at IETF? - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
