Re: [tcpm] Hystart and delay jitter

[Neal Cardwell <[e-mail]>]

On Fri, Mar 12, 2021 at 4:29 PM Christian Huitema <[e-mail]> wrote:
>
> Back in November 2019, when adding Cubic and Hystart to my
> implementation of QUIC, I noticed that Hystart was sensitive to delay
> jitter. Hystart detects the buildup of queues by monitoring the RTT.
> Some links experience delay jitter, caused for example by access
> protocol for shared radio links or possibly by link-local ARQ protocols.
> The delay jitter can cause Hystart to make the wrong decision, in two ways:
>
> 1) Delay jitter during a previous period could cause some packets to be
> delivered "faster than usual", causing Hystart to under-estimate the min
> RTT for that period.
>
> 2) Delay jitter during the currently measured period can cause packets
> to be delivered "slower than usual",  causing Hystart to over-estimate
> the min RTT for that period.
>
> The combination of these two issues may cause Hystart to make the wrong
> decisions, and exit slow start at levels well below link capacity.

Yes, we have found in both our production experience and controlled
experiments that the Hystart-Delay algorithm is very susceptible to
spurious triggering from jitter, particularly in LTE and wifi paths.

We discussed this a bit in Spring 2017 in the comparison of BBR's
bandwidth-based mechanism for exiting startup, vs Hystart-Delay's
delay-based mechanism:
  https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf#page=8

> The draft-ietf-tcpm-hystartplusplus-01 does have some protection against
> the second issue, because currentRoundMinRTT is computed on at least
> N_RTT_SAMPLE. If that number is large enough, computing the min over N
> samples should filter out "slower than usual" anomalies. However, the
> draft does not include a protection against "faster than usual"
> anomalies happening in the previous period. In my implementation, I
> protected against that by computing a "min of max" function: compute a
> rolling "MAX over N_RTT_SAMPLE", then compute the MIN value of that
> during the reference period, and use that to set the reference value
> "lastRoundMinRTT".
>
> I think it would be good to add a discussion of the effect of jitter to
> the hystart++ draft. In addition, we may also want to mention
> timestamps. The jitter on RTT may be caused by jitter on either
> direction of transmission -- data path or ACK path. The effect of jitter
> on the ACK path can be minimized if time stamps can be used to monitor
> the variation of one-way delays. This is not discussed in the current
> draft. Maybe it should be.

A discussion of the effect of jitter sounds like a great idea.

neal