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

[Sebastian Moeller <[e-mail]>]

Hi Koen,

I think none of this addresses my simple proposal to use a guard DSCP for the duration of the L4S experiment. Looking at the NQB ID (https://tools.ietf.org/html/draft-ietf-tsvwg-nqb-05) and the low latency docsis (LLD) ID (https://tools.ietf.org/id/draft-white-tsvwg-lld-00.html) I think I can even propose a candidate DSCP pattern: 0x2A 
(for the use as guard DSCP the fact that this has a lower per-chance traversal likelihood than say 0x02 is actually a feature in the context of a guard DSCP). 

Here is cable labs position (NQB is used as synonym for the LL-queue and traffic having appropriate properties to qualify for the LL-queue):
"As of the writing of this draft, it is proposed that the DiffServ value 0x2A be standardized in IETF/IANA to indicate NQB [I-D.white-tsvwg-nqb]."

So it seems pretty clear that one of the biggest drivers behind the L4S effort already assumes that a L4S DSCP is viable, desirable and standardization is already in process. One could say they consider "DiffServ [...] as a widely deployable technique on the internet", no?

Since I have seen no arguments from you on the list arguing against the feasibility of an NQB DSCP/PHB, I wonder why you accept that as viable for the NQB draft and LLD, but not for L4S. Especially since LLD contains L4S as one of its building blocks?

Best Regards
	Sebastian



> On Mar 25, 2021, at 18:54, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> 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
>