Re: [tsvwg] Reasons for WGLC/RFC asap

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,


> On Nov 20, 2020, at 09:22, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> 
> My take is that network equipment need to be upgraded for other reasons than
> AQM functionality.

	[SM] In the home router space that time point often only comes when either:
1) the old device ceases to work/operate at all (block smoke)
2) the old device is not compatible with the access tech anymore (ADSL router on VDSL2 plant)

These have time frames on the order of 5-15 years, if you are in for the long haul, you might be fine, but banking on that for operational safety is a gamble you undertake with somebody else's quality of internet access...


> And then we have the case that network gear becomes old
> or breaks down (my home WiFi routers have been fragged by lightning twice).

	[SM] Exactly, but that does not have reliable time constants to predict when the fleet currently in service is going to be replaced, no?


> No I don't have hard numbers

	[SM] Which all of us knew...

> but I don't see that lack of knowledge about
> how for instance edge routers are equipped and how upgradeable they are,
> should to be used as an argument against WGLC for the L4S drafts (that
> target experimental status). 

	[SM] But universal deployment. Sorry, as long as L4S has side-effects in the real internet these need to be taken into consideration, independent whether standards or experimental track RFCs are sought. The critical issue here is not word in an RFC or whether there exists an RFC at al, but what happens in the real world with non-ETC(1) data flows.


> This applies also to the VPN tunnels discussion in a separate thread.  
> These potential issues can be a part on the L4S experiment and solutions can
> be documented as a result of this, but it is not necessarily so that L4S
> need to adapt to all possible issues. 

	[SM] Again, L4S wants something special, the exclusive right to one rate IP header code point, and the permit to run rough-shed over existing CE users, which exist in the real world. The least to be expected from L4S is to demonstrate that its un-doubted negative side-effects are sufficiently controlled to "do no harm" to the existing internet. The way to do that is not to argue ad infinitum in a mailing list why you BELIEVE that these concerns don't matter, but to run experiments and show empirical data demonstrating these concerns can be safely put to rest.
	As S. Blake explained (again) to ru these experiments over the existing internet, no RFC is required and using carefully selected DSCPs and SLA's the participating partners can make sure to not affect unsuspecting parties during those experiments.

Best Regards
	Sebastian


> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: den 20 november 2020 08:52
>> To: Ingemar Johansson S <[e-mail]>
>> Cc: Lars Eggert <[e-mail]>; tsvwg IETF list <[e-mail]>
>> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
>> 
>> Hi Ingemar,
>> 
>> a correction below.
>> 
>> 
>>> On Nov 19, 2020, at 15:24, Ingemar Johansson S
>> <ingemar.s.johansson=[e-mail]> wrote:
>>> 
>>> Hi
>>> 
>>> Please see inline [IJ]
>>> 
>>> /Ingemar
>>> 
>>>> -----Original Message-----
>>>> From: Lars Eggert <[e-mail]>
>>>> Sent: den 19 november 2020 14:10
>>>> To: Ingemar Johansson S <[e-mail]>
>>>> Cc: Steven Blake <[e-mail]>; tsvwg IETF list
>>> <[e-mail]>
>>>> Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
>>>> 
>>>> Hi,
>>>> 
>>>> On 2020-11-19, at 14:36, Ingemar Johansson S
>>>> <[e-mail]> wrote:
>>>>> The only way is see is that the L4S
>>>>> drafts are moved to WGLC, then people will hopefully read the drafts
>>>>> and come with requests for clarifications where needed. Until then
>>>>> you can only expect more of the same long incomprehensible
>>>>> discussion threads until March, when we will repeat the same process
>> again.
>>>> 
>>>> to clarify: I don't have opinions about the L4S drafts. I haven't
>>>> read
>>> them in a
>>>> while, I agree that I should.
>>>> 
>>>> One point I am trying to make is that since the set of documents we
>>>> are discussing seems incomplete, in that it doesn't seem to contain a
>>>> TCP
>>> variant
>>>> that intends to delivers benefits over L4S paths w/o regressions.
>>>> 
>>>> My main point though is that there seem to be questions raised about
>>>> the performance and behavior of L4S with various TCP variants. This
>>>> is not an issue with the content of the L4S drafts. It's a remaining
>>>> uncertainty
>>> related to
>>>> the experimental evaluation and analysis that the L4S mechanisms have
>>>> seen so far. Going forward with a LC is not going to bring further
>>>> clarity
>>> here.
>>>> 
>>>>> [IJ] The only pain point I see now is the RTT bias in cases where
>>>>> long RTT Prague flows compete with short RTT ditto. This is being
>>>>> addressed by the developers and it is not only an L4S problem.
>>>>> Besides this, Prague will be presented at ICCRG tomorrow as I
> understand
>> it.
>>>> 
>>>> That is one point. I think interactions with tunnels was another.
>>> [IJ] My take is that this is something for L4S ops that I see as a
>>> product of the L4S experiment. It is not something that needs to be
>>> answered on its own as it is mainly the RFC3168 AQM issue in another
>>> shape, we don't know how widely spread this problem is or to how large
>>> extent this equipment can be updated, earlier discussions on fq-codel
>>> implementations in home gateways was not conclusive I guess but it
>>> appears that many of these have automatic upgrade features,
>> 
>> 	[SM] This is simply untrue, most home router will only see an update
> if
>> the user actively monitor's the provider's or manufacturer's website and
> most
>> manufacturer's will only create and distribute updates around the time a
>> device is still marketed/sold. There is pretty little home gear out these
> which
>> gets automatic updates or only notifications of possible updates. I agree
> that
>> that would be a great situation to be in, but realistically the home
> router
>> update and security situation is only mildly above the update and security
>> situation of IoT devices. Remember it is the "s" in IoT that stands for
>> security/safety...
>> 	So, if your stance is, automatic updates are robust, reliable and
> wide-
>> spread, please post some references supporting that hypothesis.
>> 
>> 
>> 
>> 
>>> I guess the reason here is to be able to upgrade to combat security
>>> threats but this is admittedly speculation.
>> 
>> 	[SM] For someone putting their operational safety in that basket I
>> would have expected more robust and reliable numbers for how many
>> devices might be amenable to automated updates. Like hard numbers
>> supporting the hypothesis that automatic updates are wide spread enough to
>> allow distribution of such functionality updates. Also think about who is
>> supposed to make back-ports of the required Linux kernel changes to the
>> often ancient kernel versions SoC-SDKs are based on? To be honest that
> level
>> of engineering by wishful thinking frightens me a bit.
>> 
>> 
>>> 
>>>> 
>>>> I'm actually looking forward to the presentation on TCP Prague - is
>>>> there
>>> a
>>>> draft?
>>> [IJ] Not that I know of, code is found at
>>> https://protect2.fireeye.com/v1/url?k=3f509ea0-60cba7e3-3f50de3b-
>> 861fc
>>> b972bfc-3fb038567b51ac5d&q=1&e=0ad66ee5-96b6-405d-84d7-
>> e83c5a03bcba&u=
>>> https%3A%2F%2Fgithub.com%2FL4STeam%2F
>> 
>> 	[SM] Is it just me that sees a problem in that the reference
> protocol
>> implementation just exists in a repository, without even an attempt of
> writing
>> an internet dratf describing that protocol? There are zero guarantees the
>> tomorrows TCP Prague still is L4S compliant (today's is not, the rfc3168
>> detection and fall back are disabled by default, see
>> https://protect2.fireeye.com/v1/url?k=c7557841-98ce4102-c75538da-
>> 861fcb972bfc-22e4ec3d607132d2&q=1&e=0ad66ee5-96b6-405d-84d7-
>> e83c5a03bcba&u=https%3A%2F%2Fgithub.com%2FL4STeam%2Flinux%2Fcom
>> mit%2Fb256daedc7672b2188f19e8b6f71ef5db7afc720).
>> 
>> 
>>>> 
>>>>> Besides this there is discussion around all sorts of cases with
>>>>> RFC3168 style AQMs, additional discussion before a WGLC will
>>>>> definitely not make us more wise.
>>>> 
>>>> Discussion won't, but experimentation would.
>>> [IJ] Yes, but we need to get past the discussion on all possible
>>> things that can happen. Recall from the discussion yesterday that
>>> Stuart Cheshire and his team has not need evidence of ECN marking
>>> AQMs. So I fear that we spend a lot of time discussing problems that are
>> very rare.
>> 
>> 	[SM] Ingemar, I and other OpenWrt users have an rfc3168 AQM on
>> my internet access link, that by default uses ECN for the downlink. I do
> not
>> have the view of the world as apple has, but I can guarantee the number is
>> grater than zero. And as stated before people doing this today are exactly
> the
>> latency conscious users L4S should aim at winning over...
>> 
>>> 
>>>> 
>>>>> As regards to investment, already today there is investment in this,
>>>>> examples that are disclosed in the open are Broadcom and Nokia. I
>>>>> can imagine that there is some expectation that L4S will materialize
>>>>> in RFCs
>>>> 
>>>> Sorry I was unclear. You are right that there is investment by vendors.
>>> But I
>>>> think the key question if there will be an investment by operators,
>>>> since
>>> they
>>>> need to eventually buy L4S kit and deploy it. And that investment
>>>> will
>>> only pay
>>>> off if end systems actually have deployed a CC scheme that takes
>>>> advantage
>>> of
>>>> L4S. So the ready availability of such a scheme is IMO a key
> requirement.
>>> [IJ] I would say that we already have CC algos that can be used.
>>> Surely they do not meet all the requirements today but I don't see why
>>> it will not be possible.
>> 
>> 	[SM] This tells more about your confidence in your vision than in
> what
>> might be achiebale in those CCs. IMHO ithe onus is on team L4S to
>> demonstrate that possibility by demonstrating a CC that ticks all the
> check
>> marks (does not need to be perfect, but should show significantly better
>> performance in some dimension, while doing at least no harm in others,
>> currently TCP Prague fails on both accounts).
>> 
>> 
>>> It is definitely the case that we will be discussing what typical RTTs
>>> are like forever but that is not something that should delay the L4S
>>> drafts I think.
>> 
>> 	[SM] Sorry, this is getting absurd, I point out both Bob completely
>> missing how PIE works (and what it's target variable actually describes )
> and an
>> inconsistency between two of the L4S drafts only to be ridiculed here.
>> Ingemar, publishing RFC with inconsistent terms and definition is not a
> sign of
>> a professional authoring process. Reviews are supposed to help finding
> such
>> issues, and the response of the authors should not be something like your
>> offense above, but a simple "thanks for pointing out the inconsistency, we
> are
>> going to fix it, here is our proposed change". The ambiguity between the
>> DualQ and the id drafts I pointed out are real, and "typical RTT" is not a
> well
>> known term of art that every IETF member or operator is going to
> understand
>> intuitively.
>> 	Also, if my worst fear is correct, protocol and AQM "typical RTT"
>> values need to be selected in lock-step to be effective, and such a
>> requirement needs to be made explicit in an RFC. And if I am wrong that
> the
>> two uses of the term have different definitions that needs to be
>> disambiguated in the internet drafts, no?
>> 
>> 
>>> 
>>>> 
>>>>> [IJ] If this would only be a IETF matter, then you are right. We
>>>>> however try to address this also in 3GPP standards to make the whole
>>>>> thing work in products, and that is of course hard to do if L4S is
>>>>> not
>>> even an
>>>> RFC.
>>>> 
>>>> Is L4S currently a requirement for a future 3GPP release?
>>> [IJ] L4S is not currently pushed for in 3GPP, there is however work on
>>> the support for extended reality that requires low latency. L4S will
>>> definitely fit there. I would expect that L4S support can be proposed ~
> mid
>> next year.
>> 
>> 	[SM] So you are willing to push an under-tested solution into 3GPP,
>> but you insist upon that un-tested solution having IETF blessing? That
> seems
>> rather odd, I would have expected that the primary requirement should be
>> "works robustly and reliably without (unacceptable) side-effects" and not
> only
>> "has RFC status". I have a hard time believing 3GPP works like that...
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>>> 
>>>> 
>>>> Thanks,
>>>> Lars
>