Re: [tsvwg] Reasons for WGLC/RFC asap

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below in-line, prefixed [SM].


Tl;dr: We are discussing whether L4S operational safety can be achieved by requiring/expecting that all existing network nodes will be updated in time to fix up the safety gaps the current L4S design and implementation introduced. 


> On Nov 20, 2020, at 10:10, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi Sebastian. 
> 
> I appears to me that we have had this discussion for 6 months of more and it
> is quite obvious that we can agree to disagree. 

	[SM] Ingemar, we are talking about hard facts here, that will not change whether you accept them or not. There are no "alternative" facts in reality. Either you are right, and all relevant network nodes (including all CPE/home-routers) can be updated to accommodate L4S' new demands on the network layers in sufficient time, or they can not. The conservative prediction is that they can and will not (unless we are talking about a time frame for starting the L4S roll-out of another decade). You say, that is wromg and it can be done mich quicker, and hence L4S can skip safety steps. Fine, now proof that your prediction is likely and we can talk. But continuously claiming other peoples updates will safeL4S' posterior without giving data that supports that prediction is simply the same old engineerng by wishful thinking that I have complained about in the past.


> I don't see that the potential audience in this WG will become much wiser if
> we continue the discussion for yet another 6 months or more. 

	[SM] This is why you need not to simply repeat your assertions and conviction, but present data that convince others that your view holds merit and is not sinply taken because it is convenient to push L4S through this WG's process.


> My standpoint remains that these issues are to be addressed during the L4S
> experiment. 

	[SM] Tat is a tall order to add to the L4S experiment, solving the existing critical update and security issue that afflicts home-routers (and similarly IoT)... 

> 
> And.. to help this experiment gain traction also outside IETF it is
> necessary that the L4S draft have RFC status.

	[SM] That is conjecture, sorry. You are trying to make the WG "ratify" the current L4S drafts by implying that 3GPP is currentky up-help by lack of RFC status, which seems not exactly true. IIUC 3GPP has in no way committed to L4S, it is just you (and maybe others) that want to make it that way. No doubt, that for this endeavor RFC status could be helpful, but please do not paint that as an already sorted and settled 3GPP requirement.

Best Regards
	Sebastian




> 
> /Ingemar
> 
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: den 20 november 2020 09:34
>> 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,
>> 
>> 
>>> 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
>>> 
>