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

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

Hi Sebastian,

The NQB codepoint is not needed to make L4S work. It could be interesting within small network segments (near the access edges: home and DC, not the core) to add more traffic into the L4S Q. I don't think anyone considers it very realistic using NQB as a widely deployable E2E feature, although it would be a bonus if it would finally, and RFCs should allow it to become that. That doesn't mean it will be a fact within the next decades.

I don't think your proposal is very simple, and has quite some impact on all parts of the architecture. If DiffServ would be in the picture, I see the DiffServ-input and ECN-output as the only simple straightforward solution. It removes the disadvantages of both while keeping the advantages of both. This was always my understanding, and I don't see any reason why this has changed. Let's keep things to the point.

Would you want SCE only to work if it has the right DiffServ codepoint on it? SCE would also need the DiffServ codepoint to protect SCE from non-SCE traffic. Even when using FQ, tunneled SCE gets trampled over by non-SCE traffic.

Again, the only question is, who wants to deploy a feature that relies on a DiffServ codepoint that needs end to end path support??? 
Let it be clear: I'm NOT. I think this is suicide... And I understood that was the main consensus during the input/output vote, and the main reason why people accepted L4S with the small risk of getting too high throughput, rather than SCE needing FQ or getting again the delay-based problems (getting trampled over by loss based and CE-only CCs).

Regards,
Koen.

-----Original Message-----
From: Sebastian Moeller <[e-mail]> 
Sent: Friday, March 26, 2021 9:06 AM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Cc: Jonathan Morton <[e-mail]>; Bob Briscoe <[e-mail]>; [e-mail]
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

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
>