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

[Roland Bless]

Hi Jonathan,

On 23.03.19 at 16:03 Jonathan Morton wrote:
>> On 23 Mar, 2019, at 11:02 am, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>>
>> On Sat, 23 Mar 2019, Roland Bless wrote:
>>
>>> I suggest to use an additional DSCP to mark L4S packets.
>>
>> DSCP doesn't work end-to-end on the Internet, so what you're suggesting isn't a workable solution.
> 
> An interesting question, in this context, is "precisely what happens if the DSCP is lost?"
> 
> With a notional L4S using DSCP instead of ECT(1) as an identifier, that really is a serious problem; the L4S flow will flood out TCP-friendly flows *unless* its failsafe kicks in.

One possibility to avoid such problems could be to check for DSCP
remarking on connection setup (i.e., during TCP handshake) and then fall
back to classic behavior in case that the DSCP was modified.

> But with SCE, what happens is that the L4S flow gets treated the same as any other, if the bottleneck where the distinction matters is downstream of the DSCP corruption.  The L4S flow reacts properly to CE in this scenario, because its been designed around SCE semantics, so it is TCP-friendly.  Flow-isolating AQMs don't need to know the DSCP in the first place.
> 
> So the worst case is when a single or dual-queue AQM bottleneck is involved, and the L4S flow is affected by queuing induced by other flows who aren't quite so enlightened.  The damage is only to the L4S flow, and within reasonable bounds.
> 
> This of course ignores the overwhelmingly most common situation on today's Internet, where the bottleneck queue is completely unmanaged.  But then, losing the DSCP has no effect there.

Regards
 Roland