Re: [tsvwg] L4S: Guard DSCP

[Pete Heist <[e-mail]>]

On Fri, 2021-04-30 at 21:21 +0000, Greg White wrote:
>  
> 
> [GW] There has been little evidence shown of single queue RFC3168
> bottlenecks.  In Pete Heist’s data (one small ISP in Czech) the known
> instances of RFC3168 were all fq_codel, and the rest of the observed
> CE markings were agreed to likely be fq_codel or CAKE as well.
>  Similarly the earlier data from Apple showing some level of ECN
> marking in France were consistent with the reported fq_codel
> deployments by one of the ISPs there.  Also, I don’t believe that any
> ISP has come forward to state that they have single queue RFC3168
> bottlenecks in their network (and, given the amount of list traffic
> on this topic, I would assume that any ISP that monitors TSVWG would
> have self-identified by now).  

While the known RFC3168 AQM marking in this case was from fq_codel,
it's hard to say what the unknown marking was from
(https://datatracker.ietf.org/doc/draft-heist-tsvwg-ecn-deployment-observations/
). Those could be fq_codel/Cake, WiFi drivers in Linux (afaik including
ath9k, ath10k, mt76 and iwl drivers), or even if uncommon, single queue
AQMs in non-default switch configs. The latter could lead to all non-
L4S flows through a bottleneck, ECN capable or not, being dominated by
a single L4S flow.

Regarding WiFi: In my spare time I help administer a WiFi network that
includes five Open Mesh OM2P-HS APs (different ISP/region from where
the ECN data was collected). All of those APs received Linux's ath9k
drivers with fq_codel via an automatic update several years ago,
without my intervention. It's not possible in the admin interface to
disable it, but it is possible and even reasonable to turn Automatic
Updates off, which would add delay to any patches required by the L4S
experiment. Most users of this and other WiFi products are innocent
bystanders with no knowledge of RFC3168.

Coming back to the Guard DSCP topic, the discussion seems to show a
fault line on whether or not the L4S experiment needs to be contained
to participating networks. In my opinion, it does, and specifically
using DSCP, or an equivalent mechanism not involving the ECN bits
alone, so as to preserve their end-to-end passage. I think the history
of ToS and DSCP suggests that netops folks faced with (or just aware
of) problems will act using the simplest method available to them, i.e.
bleaching. The introduction of a signaling mechanism that isn't
compatible with RFC3168, a proposed standard which is currently in use,
would unfortunately invite that, and could make bleaching of the entire
DS byte routine.

Mike's proposal to use DSCP at the endpoints seems sensible to me,
avoiding any action on the ECN field in the network.

Pete

> > I recall from the lengthy discussion that went on about one year
> > ago (see,
> > e.g., https://mailarchive.ietf.org/arch/msg/tsvwg/ij5BqzNtMxKV8VbHE
> > 8pUevZjx7k/ [mailarchive.ietf.org]) that one of the big objections
> > to the use of a Guard DSCP as a means to contain the experiment is
> > that an L4S experimental domain does not map well to a DSCP domain,
> > and so the Guard DSCP may be inadvertently bleached (e.g. by
> > tunnels) inside the participating network. If correct, that
> > objection is hard to address.
> 
>  
> Mike Heard