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

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Mar 26, 2021, at 13:30, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Hi Sebastian,
> 
> I understood the goal of your proposal.

	[SM] Then why did you not actually address it? I am confused.



> But before diving into the details of a DiffServ-based proposals, I'm taking a step back asking: Is using DiffServ an option at all. I don't believe so (see other reply to Steve's mail related to the reason for deployment).

	[SM] Well, then you failed, because none of your abstract theoretical objections actually fit my proposal, you are free to slay any strawmen you like, but that does not show why my simple proposal would be unworkable. I tried to address yours and Bob's objections and think I showed why these, in the context of a guard DSCP are sufficientky met tp at east merit a discussion of the proposal. Sure, this proposal has been declared "crazy" by some, but if you feel the same than show my where and why, please.

> 
> As a second step after this, "IF" using DiffServ is an option,

	[SM] Sorry, this is trying to use a general challenge with Diffserv in a context where it does not apply. The core idea of my proposal is, the guard DSCPs will not escape participating networks, so the fact that DSCPs are unlikely to be E2E (your single most important objection) simply is not a logical argument against my proposal. 


> then L4S and SCE can get married and we can benefit from both.

	[SM] Different discussion. Also I do not accept for one minute that you are actually willing to entertain this as a real option. But I understood that when proposing a guard DSCP that leaves the core L4S machinery underneath in tact. Which is of essence, given that it took you like a decade to get to this point, so I accept that you want to test the design and implementation you have, and not that you might wish you had.


> If DiffServ cannot be used,

	[SM] There is zero indication that it can not be used as a guard DSCP, if you have real objections, please bring them, the proposal needs fleshing out (or shooting down, I might have overlooked a showstopper, but DSCP not naturally being E2E is not a showstopper here).


> we have to pick one, like we did up to now and trust as a community that we together can make that work.

	[SM] What in the L4S development in this WG for the last few years, makes you believe that?


> I think the IETF needs to provide the platform for multi-party innovations, but then needs to be able to let control go and to trust the professionalism of the individual parties.

	[SM] Hard to parse, but it explains why you essentially propose RFCs without teeth (like no mandatory policing that ECT(1) flows actually behave in an L4S compatible fashion, and no reliable guarantees for sharing between flows of different RTT or traffic class). Add to this the desire to inflict the current known broke state of L4S (it neither functions as promised, nor is t safe for the rest of the internet) onto the existing internet without any robust and reliable safety mechanisms, and I really doubt that I am willing to trust your professionalism, sorry. 


So after this philosophical aside, can we maybe discuss why my proposal is unacceptable, please? 

Regards
	Sebastian


> 
> Koen.
> 
> -----Original Message-----
> From: Sebastian Moeller <[e-mail]> 
> Sent: Friday, March 26, 2021 12:55 PM
> 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,
> 
> more below, prefixed [SM]. But as a preface, it seems while you addresses this mail at me, you do not actually discuss my proposal at all. Why?
> 	While I am fully sympathetic to the proposal to re-jig L4S' signaling mechanism, all I was/am proposing is a method to contain potential fall-out during an L4S experiment to those voluntarily participating in the experiment, while keeping innocent bystanders reasonably safe. 
> 	Is my proposal 100% perfect or technically elegant? Sure not, but it does not need be, the initial "mandatory" life-time of this would only cover L4S experimental phase and a PS phase only IFF it had proved itself to be functional and feasible, so the containment mechanism would need to survive the same level of evaluation and scrutiny as L4S itself.  
> 
> 
> 
>> On Mar 26, 2021, at 12:07, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
>> 
>> Hi Sebastian,
>> 
>> The NQB codepoint is not needed to make L4S work.
> 
> 	[SM] I know, but I did not claim that (the guard DSCP is about making the L4S experiment safe, not about L4S' core functionality). My claim is, that the biggest expected immediate user of L4S saw it fit to make sure that an L4S-DSCP exists. This indicates that they do/did not share your concerns about the applicability of such a DSCP. And in actual discussion Greg seemed to indicate that he sees the fact that SLA's/TCAs might be required to guarantee safe-passage of such an L4S-DSCP as acceptable and clearly not a show-stopper.
> 
> 
>> 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.
> 
> 	[SM] Mind you, you are still discussing the "make DSCPs an integral part of L4S signaling" proposal. For my proposal of using a guard DSCP for the duration of the L4S experiment, your arguments do simply not hold. Not propagating by default E2E is part of what makes a guard DSCP actually helpful to contain an L4S experiment to participating networks. Also, the one use case where L4S is going to work for reasonably well, is short-RTT, low-hop count "fast-lanes", say, between eyeballs and content providers, a situation that typically involves a sufficient low number of AS/networks/actors to make the "negotioate DSCP-passage per contract" approach feasible.
> 
> 
>> 
>> I don't think your proposal is very simple,
> 
> 	[SM] Well, the problem is complex, so any solution will have to have some complexity in itself, but conceptually my proposal is rather small; I do not claim that implementing it might not take work and effort though.
> 
>> and has quite some impact on all parts of the architecture.
> 
> 	[SM] I disagree, adding configuration options that are required to be active for the experiment, will allow to require/allow to change these to inactive for full standards deployment. The impact would be to add these features/capabilities for the duration of the experiment sure. IMHO adding these sounds preferable than not running an experiment at all... As David indicated, with a safety proposal similar to my rough idea, the L4S experiment could have probably been started years ago, so is not changing the implementation really worth years of wall clock waiting time?
> 
> 
>> If DiffServ would be in the picture, I see the DiffServ-input and ECN-output as the only simple straightforward solution.
> 
> 	[SM] I agree that this sounds like a better design, than what L4S proposed right now, in regards to safety-by-design, but I maintain, that even my more modest guard-DSCP proposal might unlock the path to experimentation sooner. I would be delighted, if during experimentation such an "DiffServ-input and ECN-output" alternative would also be tested.
> 
>> 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.
> 
> 	[SM] Well, that is not my point, so if you will. I keep sticking to my point. If you want to deploy L4S signaling as currently designed and implemented for experimentation in live production networks soon, put L4S under the containment of a guarding DSCP would be a great way to convince me of the safety of doing so. And I assume that I am not alone in this.
> 
>> 
>> 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.
> 
> 	[SM] I defer to Jonathan's point regarding fitting SCE-style ECT(1) output signaling into L4S. This is orthogonal to the issue of how to make experiments with existing L4S design and implementation safe.
> 
>> 
>> Again, the only question is, who wants to deploy a feature that relies on a DiffServ codepoint that needs end to end path support??? 
> 
> 	[SM] According to the NQG ID, Greg, assumes this to be an attractive feature. I assume that Greg speaks on behalf of CableLabs and also assume that CableLabs thinks that DOCSIS-ISPs will be interested in that feature as well. I did not notice you objecting to the NQB draft based on your doubts about DSCP passage... 
> 
>> Let it be clear: I'm NOT. I think this is suicide...
> 
> 	[SM] Why? And "suicide" is not really an appropriate term here. That said IMHO, L4S is not going to fail because of a DSCP requirement; L4S is going to fail because L4S-compliant protocols fail to compete sufficiently well on non-L4S bottlenecks, and because L4S bottlenecks give such an undeserved advantage to L4S flows that folks will disable these pretty quickly. Whether or not you use a DSCP, is irrelevant to the sad fact that L4S is simply not ready for anything else than Eyeball<->nearCDN fast lanes (where ironically, DSCP can be reasonably expected to be E2E, either by default or facilitated by SLA/TCA).
> 
> 
>> 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).
> 
> 	[SM] If we actually had asked folks about their motivations, we might know, but we didn't... so let's not go there, please.
> 
> Best Regards
> 	Sebastian
> 
> 
> 
>> 
>> 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
>>> 
>> 
>