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

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below in-line.

> On Jun 17, 2020, at 16:08, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> Sebastian 
> Please see inline
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: den 17 juni 2020 15:27
>> To: Ingemar Johansson S
>> <ingemar.s.johansson=[e-mail]>
>> Cc: Holland, Jake <[e-mail]>; Jonathan Morton
>> <[e-mail]>; Ingemar Johansson S
>> <[e-mail]>; [e-mail]
>> Subject: Re: [tsvwg] path forward on L4S issue #16
>> 
>> Hi Ingemar,
>> 
>> more below in-line.
>> 
>>> On Jun 17, 2020, at 15:20, Ingemar Johansson S
>> <ingemar.s.johansson=[e-mail]> wrote:
>>> 
>>> Hi Jake
>>> 
>>> And thanks for the input.
>>> Given all the input sofar my impression is that It is difficult to say how
>> serious issue 16 really is.
>>> Surely there is a possibility that L4S flows can get an potentially unfair
>> advantage over a congested node that is  RFC3168 capable (and ECN
>> enabled). The question is here when things are deemed as unfair and when
>> starvation is a fact, opinions differ.
>>> Another question is to how large extent there will be legacy RFC3168 ECN
>> capable (and ECN enabled ) bottlenecks that will "never" be updated or
>> replaced. This question is currently difficult to answer.
>>> 
>>> Yet another aspect is how successful it will be to implement RFC3168
>> bottleneck detection e.g. in TCP Prague, I am quite confident that these will
>> not always be successful.
>> 
>> 	[SM] +1
>> 
>> 
>>> But then, given the current deployment situation and possibility to
>>> update nodes in the networks (OpenWrt routers appear to support
>>> automatic updates)
>> 
>> 	[SM] Please accept my apology for not being clear on that topic in the
>> past. Stock OpenWrt does not offer automatic updates, not even notification
>> of update availability at all. There are some vendors, like Evenroute and
>> Turris, that base their own products on top of OpenWrt that do offer
>> automatic updates and as far as I can tell also notifications. But I have no
>> reliable numbers on the prevalence of either stock OpenWrt or update-
>> enabled versions in the field. I also add that a tiny bit of research should allow
>> to confirm this.
> 
> [IJ] Sounds like a contradiction here to me.

	[SM] Why, it is an clarification.


> I was asking for a list of off the shelf routers with OpenWrt support, all these seem to support automatic updates of course limited by some EOL constraints. To me this seems like what the average John or Jane Smith would consider to buy. On top of this we have the few enthusiastic do-it-yourself people who implement OpenWrt in Raspberry PI but that is of lesser interest because a) they are very few and b) they are in the forefront and are thus likely to upgrade pretty fast. 

	[SM] I disagree, we have no numbers to figure out whether assumption a) is true*, and for b) we will first need to demonstrate that any change is actually desirable. L4S is severely lacking in b) so far.

Best Regards
	Sebastian


*) I doubt this is correct, as quite a number of OpenWrt users stay on older releases as newer versions will not run well on under-powered devices. So there is going to be a long tail of legacy versions even among OpenWrt users. I base this assessment on supporting users on the OpenWrt forum.


> 
>> 
>>> I am not convinced that these need to be 100% bulletproof either.
>> 
>> 	[SM] 100% is not achievable, but what we currently have is an effort
>> just designed to get past the objections int the WG instead of actually trying
>> to tackle the issue for real.
>> 
>>> 
>>> /Ingemar
>>> 
>>>> -----Original Message-----
>>>> From: Holland, Jake <[e-mail]>
>>>> Sent: den 15 juni 2020 20:36
>>>> To: Ingemar Johansson S
>>>> <ingemar.s.johansson=[e-mail]>; Jonathan
>> Morton
>>>> <[e-mail]>
>>>> Cc: Ingemar Johansson S <[e-mail]>;
>>>> [e-mail]
>>>> Subject: Re: [tsvwg] path forward on L4S issue #16
>>>> 
>>>> Hi Ingemar,
>>>> 
>>>> I posted some summary numbers from some observations I made here:
>>>> https://protect2.fireeye.com/v1/url?k=d34bc422-8deb7e4c-d34b84b9-
>> 8660
>>>> 38973a15-6559e7e079a7505b&q=1&e=7a17ee77-c385-4248-836a-
>> 193e64d78d5c&
>>>> 
>> u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsvwg%2F2tbRH
>> phJ8
>>>> K_CE6is9n7iQy-
>>>> VAZM/
>>>> 
>>>> I didn't say anything about France or Norway, but the numbers I have
>>>> seen were roughly in line with the numbers Jonathan gave.
>>>> 
>>>> The "growing" claim also looks tentatively well-supported, because
>>>> I've seen
>>>> 2 new ASNs since then with a high count of CE-marking paths.
>>>> 
>>>> HTH.
>>>> 
>>>> Best regards,
>>>> Jake
>>>> 
>>>> On 6/10/20, 6:59 AM, "Ingemar Johansson S"
>>>> <ingemar.s.johansson=[e-mail]> wrote:
>>>> 
>>>> 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