[tcpm] Hystart and delay jitter

[Christian Huitema <[e-mail]>]

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.

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.

-- Christian Huitema