Re: [tsvwg] L4S: Guard DSCP

[Pete Heist <[e-mail]>]

One question/comment below...

On Thu, 2021-04-22 at 23:40 +0000, Black, David wrote:
> [posted as an individual, not as a WG chair]
>  
> Some time ago, I wrote:
>  
> > in the hope of fostering productive discussion, I'll try to put
> together a summary (as an individual) of what a Guard DSCP
> > could look like whose sole purpose is to better equip operators to
> deal with things that might go wrong in an L4S
> > experiment (without redesigning the experiment).  Patience, please
> ...
>  
> Here's that attempt, but first some process discussion …
>  
> The L4S ops draft currently contains material for operators of L4S
> hosts (Section 4) and for operators of networks participating in the
> L4S experiment who experience problems at RFC 3168 FIFO bottlenecks
> in their own networks).  A Guard DSCP for L4S complements material in
> the L4S ops draft by providing means for an operator actively
> participating in the L4S experiment to deal with reports that L4S
> traffic leaving the operator's network is causing problems downstream
> in a network that may not be participating in the L4S experiment
> (including an all-but-unmanaged residential WiFi access point).  I'd
> suggest that initial discussion focus on what a Guard DSCP for L4S is
> and how it works with a goal of getting detailed text on that into
> the L4S ops draft, after which could come the inevitable heated
> discussion on requirement level (MUST/SHOULD/MAY) for a Guard DSCP.
>  
> … and so here is that summary for discussion, phrased as
> goals/guidelines for specifying the Guard DSCP:
>  
> DO:
> A. Mark all L4S traffic with a Guard DSCP at endpoints and/or
> network edges.
> B. Participating operators are able to identify and separately
> handle Guard DSCP traffic at network boundaries, dropping it as a
> last resort.  Strongly discourage traffic filtering to drop
> ECT(1) traffic.
> C. Plan to remove Guard DSCP requirement if L4S experiment succeeds.

Regarding B, other than dropping Guard DSCP marked traffic at network
boundaries, are there other options to prevent L4S and non-L4S traffic
from meeting at an RFC compliant AQM outside the experimental network?
Bleaching ECT(1) on traffic with the Guard DSCP might be one...

Pete

> DON'T
> A. Require AQMs to use Guard DSCP in addition to ECT(1) to identify
> L4S traffic.   This should be allowed, not required, which is
> already the case - see Section 5.4 of the ecn-l4s-id draft.
> B. Rely on DSCPs for signaling or modify transport protocols to have
> reactions that vary by received DSCP.
> C. Do anything else that would be a significant obstacle to removing
> use of the Guard DSCP if the L4S experiment succeeds.
>  
> For further discussion: Operator/technology-specific alternate means
> of accomplishing the functional equivalent of A & B
> E.g., I would think that 5G networks have other means at their
> disposal to handle traffic aggregates at network boundaries in a
> fashion that could make 5G use of a Guard DSCP pointless.
>  
> This is what I had in mind for a Guard DSCP – I'll do my best to
> promptly answer questions, respond to comments etc.  Please try to
> keep the discussion calm and technical.
>  
> [reminder: posted as an individual, not as a WG chair]
>  
> Thanks, --David
>  
> David L. Black,Sr. Distinguished Engineer, Technology & Standards
> Infrastructure Solutions Group, Dell Technologies
> mobile +1 [e-mail]
>