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

[Sebastian Moeller <[e-mail]>]

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%3A1484466
> &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_sort_asc&sortOrder2
> =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]
> >
>
>