[Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Jonathan Morton]

> On 15 Mar, 2019, at 4:44 pm, Sebastian Moeller <moeller0 at 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