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

[Bob Briscoe <[e-mail]>]

Mike,

Many of the arguments for why a DSCP is not useful e2e also apply when 
it is used as a guard DSCP in a single network. For instance, when an IP 
header with a DSCP is tunnelled in pipe mode, it is not propagated to 
the outer. So it won't be visible, won't be bleached, etc.

There's far too much vagueness in this thread. In the email I just sent 
to Jonathan, I asked him to address each of the critiques of a DSCP in 
Appx B.4, not just dismiss them all as invalid, which is untenable. 
Certainly, some of the critiques are not relevant to the way the DSCP is 
used in Jonathan's scheme, but many are like the tunnel issue above. So 
far, we've only just started on the basics like whether the feedback 
approach is even practical.


Bob

On 27/03/2021 03:00, C. M. Heard wrote:
> On Fri, Mar 26, 2021Sebastian Moeller wrote:
>
>     On Mar 26, 2021, at 18:34, De Schepper, Koen wrote:
>     > My first point is that requiring to set a DiffServ codepoint
>     alone would already support that.
>
>      [SM] Well, sure, but you came to the ECT(1) decision for a reason
>     (a reason I do not agree with, but that is a different topic, I am
>     trying to build you a bridge here how to run your experiments
>     without taking the rest of the internet down), so I am not going
>     to argue about that. My proposal adds an GUARD DSCP for the
>     duration of the EXPERIMENT to allow your measurements in live
>     production networks without negative side-effects for
>     non-participants. This layer of safety can be removed if the
>     experiment has run ist course and measurements in consenting
>     networks has provided data that L4S is safe without the DSCP. At
>     which point the DSCP could be dropped, try doing that if you only
>     use a DSCP as L4S classifier.
>
>
> This point sure seems to have been lost in much of the discussion. 
> Note again: GUARD DSCP for the duration of the EXPERIMENT. NOT DSCP 
> instead of ECT(1).
>
> I've read several comments objecting that using DSCP to distinguish 
> L4S traffic is undeployable end-to-end on the general Internet. Well, 
> according to the intended status of the drafts, L4S is starting life 
> as an EXPERIMENT, and as such is not expected (or at least should not 
> be expected) to be deployed on the general Internet. If the WG's 
> desire is to have L4S deployed on the general Internet as soon as the 
> specs are approved, then the WG should take Steven Blake's advice and 
> deprecrate/obsolete RFC 3168 and change the intended status of the 
> drafts, or else use a mechanism that is backward compatible with RFC 
> 3168, such Jake Holland's proposal to use ECT(1) -> ECT(0) as the L4S 
> congestion signal, leaving the semantics of CE unchanged.
>
> Mike Heard

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/