Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

If using DiffServ is considered as a widely deployable technique on the internet, then we should simply use DiffServ as the "input" L4S identifier and use SCE as the congestion "output". I don't think we need more complex experimental schemes, especially if they end up needing a final DiffServ codepoint anyway even after the experiment (like in Jonathan's proposal).

As such it would be the perfect marriage of both L4S and SCE. So an AQM can only mark SCE if it has the DiffServ L4S-id and can protect and isolate the L4S-SCE flows from flows not responding to the SCE marks (in a DualQ or FQ, or any other scheme detecting presence of non-L4S flows).

This was one of the options that was considered before and which would be the simplest solution involving DiffServ.

The question was and still is if DiffServ "is" the perfect wedding proposal for Internet wide traffic. How many more hurdles do we need for deploying scalable and smooth congestion control (which is I assume the common goal of both L4S and SCE).

Main question is: Is the risk (pushing away Classic flows on a RFC3168 ECN bottleneck after tens of seconds) worth the extra deployment obstacles (practically making its deployment as constrained as an end-to-end managed service).

If the answer is yes, then we should define a DiffServ codepoint that identify L4S and only use SCE for those. If the risk is assumed minimal and comparable with other experimental CCs (see ICCRG https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-the-great-internet-tcp-congestion-control-census-00), then we live with the (small?/controlled?) impact.

I understood the latter had the biggest support in the input/output vote during the previous interim. I think if L4S flows are not used for long time downloads (non-application-limited flows), the impact is minimal and a 3168 detection and fallback would never be needed. It also was known that Classic bottleneck detection would be a challenge, but I think Asad/Bob showed that a (maybe not 100% perfect, but already) very good implementation is possible if needed for the problem conditions that are known then. These could be used (experimented with) when using L4S for downloads.

So bottom-line question: Who believes an end-to-end DiffServ solution is realistically deployable???
Second sub question: who believes L4S is a bigger risk than all other CCs "experiments" on the Internet??

Regards,
Koen.



-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Jonathan Morton
Sent: Wednesday, March 24, 2021 11:24 PM
To: Bob Briscoe <[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

> On 25 Mar, 2021, at 12:10 am, Bob Briscoe <[e-mail]> wrote:
> 
> Can someone explain for the record how using a DSCP as an L4S identifier would solve the CE ambiguity problem?

It doesn't.  It only allows containing the resulting harm to participating networks, thereby protecting (most) innocent bystanders.  It's enough, I think, to conduct a field experiment to discover just how bad the problem really is in practice.

This is predicated on the notion that the L4S-ID DSCP(s) are bleached or dropped at the participating networks' border, and in the case of border bleaching, that L4S endpoints interpret CE marks *not* carrying the L4S-ID DSCP as per RFC-3168 or RFC-8511.

I refer you also to my recent post titled "L4S, DSCP, and RFC-4774 Option 2" in which I give a more detailed explanation of a two-DSCP proposal.  The short version is that a version of L4S using that scheme would have *some* positive confidence whether or not they were receiving L4S or conventional marking, without the need for heuristic probing or monitoring.

 - Jonathan Morton