Re: [tsvwg] Reasons for WGLC/RFC asap

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

Hi

My take is that network equipment need to be upgraded for other reasons than
AQM functionality. And then we have the case that network gear becomes old
or breaks down (my home WiFi routers have been fragged by lightning twice).
No I don't have hard numbers 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). 
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. 

/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