Re: [tsvwg] path forward on L4S issue #16

[Ingemar Johansson S <[e-mail]>]

Hi

Do you have any public sources that confirm the numbers you quote below ?. I
tried to look up data on this but it surely is not easy. 
Which foras are the vendors that manufacture CPEs active in (if any) ?. 

As regards to endpoints implementing RFC3168, do you refer to servers and
clients or something else?. My interpretation is servers and clients and I
don't believe that they are central  to this discussion, or do I miss
something ?. I understand that traffic shaping on outgoing interfaces can be
applied in a Linux host but don't see why they become a problem especially
as there are qdiscs that support dualQ.

/Ingemar

PS. I am not yet trying to convince anybody, I am just trying to find the
answers.


> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 10 juni 2020 14:58
> To: Ingemar Johansson S <[e-mail]>
> Cc: Sebastian Moeller <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] path forward on L4S issue #16
> 
> > On 10 Jun, 2020, at 11:35 am, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > 1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ?
> 
> Enough for the effects to be visible on about 0.1-1.0% of current Internet
> traffic - and rising steadily.  That's some combination of endpoints
negotiating
> ECN support, and middleboxes implementing an AQM, but not necessarily
> both on the same path.  Deployment of ECN-enabled AQM is very high
> across a small number of forward-thinking ISPs, including a very large one
in
> France and a major one in Norway.
> 
> Basically every endpoint out there today implements RFC-3168 ECN, and
> every Linux endpoint runs an ECN-enabled AQM by default on each Ethernet
> interface.  If Linux and/or Microsoft had decided to switch it on by
default a
> decade ago, rather than hiding it behind a non-default configuration flag,
we
> would not be having this conversation, because the deployment numbers
> would be too big and obvious to ignore.  It's been a long, slow
chicken-and-
> egg situation which the major consumer ISPs have essentially refused to
help
> resolve.
> 
> But now there are commercial, off-the-shelf CPE products which anyone can
> buy and install, and which implement the sort of bufferbloat mitigation
> measures that most ISPs have not.  I've found at least one of those on the
> physical retail shelf, here in Finland.  I don't have sales numbers, but
they
> must account for most of the deployment on ISPs that haven't deployed it
> themselves.
> 
> > 2) If they are deployed _and_ enabled, can/will they be updated ?
> 
> Some can and will.  But some is baked in hardware so would be difficult to
> update, and some is managed by people/vendors who do not know or care
> about L4S, so would tend to keep using the old system which is RFC-
> compliant today.  When was the last time your CPE devices got a firmware
> update?  So L4S has to be able to cope with the existence of such
> deployments in at least the medium term.
> 
> Frankly, if you believe that tunnels are an intractable problem, then this
is
> just as bad.  So please finally drop this argument; you're not convincing
> anyone who matters.
> 
>  - Jonathan Morton