Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue delay targets

[Sebastian Moeller <[e-mail]>]

Hi Ingemor,

more below in-line, prefixed [SM2].

> Gesendet: Montag, 02. November 2020 um 10:50 Uhr
> Von: "Ingemar Johansson S" <[e-mail]>
> An: "Sebastian Moeller" <[e-mail]>
> Cc: "Rodney W. Grimes" <[e-mail]>, "Bob Briscoe" <[e-mail]>, "tsvwg IETF list" <[e-mail]>, "iccrg IRTF list" <[e-mail]>, "Christian Huitema" <[e-mail]>, "TCP Prague List" <[e-mail]>, "De Schepper, Koen (Koen)" <[e-mail]>, "Ingemar Johansson S" <[e-mail]>
> Betreff: RE: Re: [tsvwg] [iccrg] Realistic Queue delay targets
>
> Hi
> I don't anymore know where all these discussions are heading. 

        [SM2] Ideally this process would lead to better designed and implemented L4S core methods and better written internet drafts. All that requires team L4S to be a bit more open, to a) support their assertions with real data and b) at least occasionally accept criticism as valid and change more than a few words in the draft as a consequence. As long as team L4S basically maintains L4S is perfect as it is, this is heading nowhere (at least it should, in reality we are heading straight towards ratifying the existing IMHO sub-optimal state of the L4S internet drafts as experimental track RFCs, if only based on the argument that after working on this for a the better part of a decade it is now time to show up something). This view is supported by the fact that the chairs stopped soliciting actual data and safety tests, and focus mainly on seeing proposals for text changes. Even though it is still unclear if L4S is actually suitable for wider release into the internet. The current drafts however are not written in a way to conduct an "is L4S safe to deploy into the internet" experiment, as they offer neither criteria on how to asses safety, nor a plan for how to resolve the experiment for either outcome. (On success it is simple, either do nothing and keep experimental infrastructure in use, or try to move the RFC to standards track, but on failure, how to disable all the network nodes and how to reclaim the ECT(1) codepoint for other experiments?)

Seems like we 
> always end up in infinite discussions that lead nowhere!.

        [SM2] Oh, no. we are making progress albeit at a worrisome slow rate. For example, your points confirmed that relaying on protocol designers to meet requirements that only have subtle safety consequences (like the 15ms hack) seems overly optimistic and not a viable path to guaranteeing safety. Yet, I am certain, that this assessment will a) not be shared universally on this list, nor lead to changes in how team L4S plans to deal with issue #28 (the strategy so far is to more or less ignore that issue).

> Network implementers will implement whatever queue management they find 
> useful, be it dualQ, fq-codel or whatever.

        [SM2] Yes, and that as a consequence means, that the core L4S methods and components need to offer robust safety even when protocols might be (accidentally) cutting corners, no? Because if even you, a strong proponent of L4S, did not understand that section 4.3 was not intended to be optional, how can we expect other designers less involved in L4S get this right?

> 
> Yes, there are ways to deal with jitter, some are implemented, some are in the 
> pipe, some are on the drawing board and as I mentioned several times: It is 
> not very fruitful to take todays internet jitter as a litmus test on how good 
> L4S will behave in the future.
> As examples, 5G has a shorter HARQ retransmission loop than 4G, this reduces 
> jitter, there is also work to reduce handover delay, shorter TTIs etc. It is 
> therefore quite meaningless to produce data on how well L4S will fare in the 
> precense of jitter. Leave that to the experiments.
> 
> /Ingemar
> 
> 
> > -----Original Message-----
> > From: Sebastian Moeller <[e-mail]>
> > Sent: den 2 november 2020 09:47
> > To: Ingemar Johansson S <[e-mail]>
> > Cc: Rodney W. Grimes <[e-mail]>; Bob Briscoe
> > <[e-mail]>; tsvwg IETF list <[e-mail]>; iccrg IRTF list
> > <[e-mail]>; Christian Huitema <[e-mail]>; TCP Prague List
> > <[e-mail]>; De Schepper, Koen (Koen)
> > <[e-mail]>
> > Subject: Aw: Re: [tsvwg] [iccrg] Realistic Queue delay targets
> >
> > Hi Ingemar,
> >
> > more below in-line, prefixed [SM].
> >
> > > Gesendet: Montag, 02. November 2020 um 09:30 Uhr
> > > Von: "Ingemar Johansson S"
> > > <ingemar.s.johansson=[e-mail]>
> > > An: "Rodney W. Grimes" <[e-mail]>, "Bob Briscoe"
> > > <[e-mail]>
> > > Cc: "tsvwg IETF list" <[e-mail]>, "iccrg IRTF list"
> > > <[e-mail]>, "Christian Huitema" <[e-mail]>, "TCP
> > > Prague List" <[e-mail]>, "De Schepper, Koen (Koen)"
> > > <[e-mail]>
> > > Betreff: Re: [tsvwg] [iccrg] Realistic Queue delay targets
> > >
> > > Hi Rodney
> > >
> > > I believe part of the answer to your question is found in
> > > https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-6.3 .
> > > The fact that we begin to see the scheduling jitter does not
> > > invalidate L4S as a means to reduce the congestion related jitter.
> >
> >        [SM] As so often that section does contain some theoretical 
> > observations,
> > but fails to empirically show which level of burstyness L4S can deal with
> > gracefully and what the consequences are (on the bursty flow itself, other
> > flows in the shallow-queue and and flows in the deep queue). That would be
> > meaningful responses to Rodney's concern. As is that section basically just
> > claims without supporting data, that even in the face of bursty flows, L4S
> > should still be tried, but that must be compared to a FiFO, because compared
> > to say fq_codel with a 5ms default target, traffic with > 5ms jitter will 
> > probably
> > look much better after fq_codel than after L4S (L4S will conserve the
> > burstyness much more, while fq_codel will smooth it out a bit).
> >         I wonder why such verbose but essentially non-actionable (almost
> > useless) sections keep getting added to already  quite long and verbose
> > internet drafts in the first place?
> >
> > Regards
> >         Sebastian
> >
> > >
> > > Scheduling jitter exist also in cellular technology. Scheduling jitter
> > > is however generally not evidence of congestion. L4S congestion
> > > marking should therefore be designed to not trigger on this. The
> > > master thesis** the L4S marking threshold was set sufficiently high to
> > > avoid this but it should be understood that L4S marking in cellular can be
> > implemented in smarter ways.
> > > In the master thesis, the L4S marker only inspected the queue on the
> > > RLC layer.
> > > There are other causes to delay jitter in cellular, HARQ
> > > retransmissions and handover delays are two examples. There is work in
> > > progress to reduce all kinds on delay jitter, L4S is a tool to reduce
> > congestion related jitter.
> > > In any case, non-congestion related jitter is not an argument against
> > > L4S
> > >
> > > /Ingemar
> > >
> > > **
> > > https://kth.diva-portal.org/smash/record.jsf?dswid=-6303&pid=diva2%3A1
> > > 484466
> > >
> > &c=1&searchType=SIMPLE&language=en&query=brunello&af=%5B%5D&aq=
> > %5B%5B%
> > > 5D%5D&
> > >
> > aq2=%5B%5B%5D%5D&aqe=%5B%5D&noOfRows=50&sortOrder=author_sor
> > t_asc&sort
> > > Order2 =title_sort_asc&onlyFullText=false&sf=all
> > >
> > > > -----Original Message-----
> > > > From: Rodney W. Grimes <[e-mail]>
> > > > Sent: den 1 november 2020 21:24
> > > > To: Bob Briscoe <[e-mail]>
> > > > Cc: Christian Huitema <[e-mail]>; tsvwg IETF list
> > > > <[e-mail]>; iccrg IRTF list <[e-mail]>; TCP Prague List
> > > > <[e-mail]>; De Schepper, Koen (Koen)
> > > > <[e-mail]>
> > > > Subject: [iccrg] Realistic Queue delay targets
> > > >
> > > > Bob,
> > > >
> > > > > Christian,
> > > > >
> > > > > I've changed the subject line given it's no longer appropriate.
> > > > > See inline tagged [BB]...
> > > >
> > > > And I am changing it again... as only addressing a statement that I
> > > > have
> > > great
> > > > concerns about.
> > > >
> > > > See inline ragged [RWG]
> > > >
> > > > > On 01/11/2020 01:07, Christian Huitema wrote:
> > > > ... [ much text deleted ] ...
> > > >
> > > > > [BB] Yes, once the IETF assigns the codepoint, BBRv2 will be 'allowed'
> > > > > to send packets over the Internet as ECT(1). Then, yes, an L4S
> > > > > DualQ Coupled AQM will classify BBRv2 packets into the L4S queue.
> > > > > This should have a very shallow ECN marking threshold (500us -
> > > > > 1ms), so even if the flow (whether QUIC or TCP) is flying just
> > > > > under the available capacity, bunching of packets means it is
> > > > > unlikely to completely avoid ECN marking between probes. If it
> > > > > could avoid ECN marking, you are right that it would get a bump of
> > > > > ECN marks during the probe. I haven't studied the code, but when
> > > > > it experiences ECN marking I believe it switches into an L4S ECN
> > > > > mode for a while, and uses ECN rather than delay probing to track
> > > > > available capacity. I assume it switches back to BBR's delay
> > > > > probing mode if it gets no ECN for a while (e.g. the bottleneck
> > > > > might have moved). But I haven't looked
> > > at
> > > > BBRv2's ECN behaviour in detail.
> > > >
> > > >  [RWG] I have great concern about this 500uS to 1mS ECN marking
> > > > threshold given that I have recently learned the latest WiFi
> > > > standards actually run
> > > with a
> > > > packet aggregation time of 4mS thus making it probably impossible to
> > > > have such traffic work in such a targeted low latency queue.
> > > >
> > > >  [RWG] Has any consideration been given to what is already deployed
> > > > on the Internet as link layer technologies that would preclude the
> > > > operation of
> > > the
> > > > L4S low latency queue?
> > > >
> > > > Regards,
> > > > --
> > > > Rod Grimes
> > > [e-mail]
> > > >
> > >
> > >
>