Hi Jonathan, On 23.03.19 at 16:03 Jonathan Morton wrote: >> On 23 Mar, 2019, at 11:02 am, Mikael Abrahamsson <swm...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
