Re: [tcpm] [EXTERNAL] Re: Hystart and delay jitter

[Praveen Balasubramanian <[e-mail]>]

Thanks Christian for the suggestions! We will include a discussion on jitter in the next draft update and also experiment with the min of max function. 

-----Original Message-----
From: tcpm <[e-mail]> On Behalf Of Neal Cardwell
Sent: Friday, March 12, 2021 2:18 PM
To: Christian Huitema <[e-mail]>
Cc: [e-mail] Extensions <[e-mail]>
Subject: [EXTERNAL] Re: [tcpm] Hystart and delay jitter

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F98%2Fslides%2Fslides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf%23page%3D8&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cbc3399870c0d4105299408d8e5a4cbaa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511843745826011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6SQWDb1mFH0cgrayEwiRYeccYvP0dv%2BAJ1eokyJF%2BKs%3D&amp;reserved=0

> 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

_______________________________________________
tcpm mailing list
[e-mail]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cbc3399870c0d4105299408d8e5a4cbaa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637511843745826011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oqte6wCaTBUvrwgXVRMcD13YgtspMJyIWMMLlwNuYdY%3D&amp;reserved=0