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

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

Hi
I don't anymore know where all these discussions are heading. Seems like we 
always end up in infinite discussions that lead nowhere!.
Network implementers will implement whatever queue management they find 
useful, be it dualQ, fq-codel or whatever.

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