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

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Mar 26, 2021, at 19:07, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> I’m open for discussing alternatives, but I think we need first to decide whether using DiffServ is a feature or suicide…

	[SM] I do not think that this phrasing is helpful. The proposals on the table are:
a) re-jig L4S' signaling to re-balanca the inherent safety of L4S
b) making sure that the existing L4S signaling can safely be experimented with in the existing internet

I can see, why you would not want to do a), but liking to B) suicide is hyperbole.



>  
> I’m afraid it will be suicide… I don’t think enabling end-to-end DiffServ pass-through is under control of a single party.

	[SM] Exactly, that is one of the tenets of my proposal, require that any L4S path needs to be negotiated, so that the networks involved can make sure that the required safety mechanisms are in place. So that is hardly an argument agsainst my guard DSCP proposal, unless inflicting L4S' side-effects on innocent bystanders is the goal of the experiment...

> So at the end L4S will be restricted to single operational domains.

	[SM] Ever heard of SLAs and TCAs? Differserv domains can and do negotiate safe passage of DSCPs or PHB already, so that operational knowledge and process probably can be leveraged an used to span safe L4S test domains spanning multiple AS.


> Of course allowing L4S without DiffServ won’t stop anyone using DiffServ.

	[SM] And does nothing to guarantee the safety of the L4S experiment, so 

>  
> Do people with experience in that field (operators) have a substantiated opinion on this?
>  
> Would application providers see using DiffServ as an obstacle?

	[SM] Let me add the following refinement of the question (because any additional requirement is an "obstacle" the question is rather is this a show-stopper):
Would you parytcipate in the L4S experiment without a required DSCP but would pass if a guard DSCP would be required? And if so, how would you propose to keep the experiment under containment in your live production network instead?

Best Regards
	Sebastian


>  
> Koen.
>  
> From: Martin Duke <[e-mail]> 
> Sent: Friday, March 26, 2021 6:15 PM
> To: Jonathan Morton <[e-mail]>
> Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; Bob Briscoe <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>  
> Speaking as an individual,
>  
> Bob has identified all of the problems with using DSCP for L4S. Among them is running L4S through a tunnel.
>  
> Another axis of discussion was changing the L4S signal to be ECT(1)->ECT(0) and preserving the CE signal (thread: [1]), which comprehensively solves the coexistence issues. But this fell down, partially because of the (needless) RFC6040 tunnel decap behavior, which will revert any outer-header changes. There are some other problems, of course, they don't affect bystanders and I don't see them as likely to be fatal.
>  
> Honestly, if we're going to break L4S in tunnels anyway, I would just as soon break it with the semantic change and not take all the other DSCP baggage that Bob describes. We could even bis the mistake in 6040 so that "eventually" the needless behavior goes away.
>  
> This is not a statement in favor of 1->0 marking. It is a statement that if the WG is going to insist on a DSCP to ship this design, I would prefer 1->0 over that.
>  
> Sorry to complicate the discussion.
>  
> Martin
>  
> [1] https://mailarchive.ietf.org/arch/msg/tsvwg/TDMKRyH9E6zho6VkiXDYes7FZK0/
>  
> On Fri, Mar 26, 2021 at 7:00 AM Jonathan Morton <[e-mail]> wrote:
> > On 26 Mar, 2021, at 2:30 pm, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> > 
> > I understood the goal of your proposal. 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).
> > 
> > As a second step after this, "IF" using DiffServ is an option, then L4S and SCE can get married and we can benefit from both.
> 
> In recent days I have put forward two distinct ways to use Diffserv in this context, both of which I believe are workable.  The one I prefer is of course the one involving SCE-type signalling rather than L4S-type signalling; it consumes fewer DSCPs and has fewer failure modes.
> 
> In the SCE context, Diffserv is useful for three things:
> 
> 1: Protection of early experimental deployments.  This is temporary.
> 
> 2: Enabling dual-queue AQMs to perform SCE classification and signalling.
> 
> 3: Allowing SCE AQMs to distinguish SCE and non-SCE traffic embedded in the same tunnel.
> 
> SCE itself is compatible with existing dumb FIFOs, policers, dropping AQMs, and RFC-3168 AQMs both single and multi-queued, without the assistance or need for any Diffserv mechanism.  Most SCE AQMs will probably have AF or FQ functionality to ensure good compatibility with conventional traffic.
> 
> Diffserv is strictly an enhancement to SCE, which can be deployed in those contexts which benefit from it.  The CDN -> ISP -> subscriber path is an ideal context for deploying a coherent Diffserv system.  I think that dovetails very nicely with the technical needs of DOCSIS Low Latency.
> 
>  - Jonathan Morton