Re: [tsvwg] Reasons for WGLC/RFC asap

[Sebastian Moeller <[e-mail]>]

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://github.com/L4STeam/  

	[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://github.com/L4STeam/linux/commit/b256daedc7672b2188f19e8b6f71ef5db7afc720).


>> 
>>> 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