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

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

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.

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