Re: [tsvwg] Reasons for WGLC/RFC asap

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

Hi

Snip-snip
"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."
Well.., I don't...

/Ingemar 



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