[tsvwg] L4S: Guard DSCP

["Black, David" <[e-mail]>]

[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:

  1.  Mark all L4S traffic with a Guard DSCP at endpoints and/or network edges.
  2.  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.
  3.  Plan to remove Guard DSCP requirement if L4S experiment succeeds.

DON'T

  1.  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.
  2.  Rely on DSCPs for signaling or modify transport protocols to have reactions that vary by received DSCP.
  3.  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 [phone] [e-mail]<mailto:[e-mail]>