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

[Pete Heist <[e-mail]>]

Just to wrap this up, I fully support the idea that using DSCP to flag
the L4S ECN semantics is a productive way forward for now. IMO, it's
never too late to start down the right path, and it seems like we
should be able to pass drafts that do this relatively quickly.

Beyond what we've thought of to test in the lab, there may well be
things we haven't thought of, both in terms of safety and performance.
It makes sense to look at both on real-world traffic before the
allocation of ECT(1) for a potentially long Internet-wide experiment,
especially given the lab results we do have.

On Thu, 2021-03-25 at 00:23 +0200, Jonathan Morton wrote:
> > 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