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

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

Hi

My finding is that it is a bit problematic to rely on RTT estimates for path
capacity especially with cellular access . It was summarized in section 4 in
https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 and also
presented in
https://www.ietf.org/proceedings/96/slides/slides-96-iccrg-1.pdf

Regards
Ingemar

> -----Original Message-----
> From: tcpm <[e-mail]> On Behalf Of Praveen
> Balasubramanian
> Sent: den 18 mars 2021 23:37
> To: ncardwell=[e-mail]; Christian Huitema
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tcpm] [EXTERNAL] Re: Hystart and delay jitter
> 
> 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://protect2.fireeye.com/v1/url?k=6c35f204-33aecb47-6c35b29f-
> 861fcb972bfc-c8f94340e007b7bd&q=1&e=fd13218f-2e70-4b39-a879-
> e9b53c01447d&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com
> %2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fproceedings%25
> 2F98%252Fslides%252Fslides-98-iccrg-an-update-on-bbr-congestion-control-
> 00.pdf%2523page%253D8%26amp%3Bdata%3D04%257C01%257Cpravb%2540
> microsoft.com%257Cbc3399870c0d4105299408d8e5a4cbaa%257C72f988bf86f
> 141af91ab2d7cd011db47%257C1%257C0%257C637511843745826011%257CUn
> known%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3D6SQWDb1
> mFH0cgrayEwiRYeccYvP0dv%252BAJ1eokyJF%252BKs%253D%26amp%3Brese
> rved%3D0
> 
> > 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://protect2.fireeye.com/v1/url?k=032901f3-5cb238b0-03294168-
> 861fcb972bfc-7a6ccb41bd90a846&q=1&e=fd13218f-2e70-4b39-a879-
> e9b53c01447d&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com
> %2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flis
> tinfo%252Ftcpm%26amp%3Bdata%3D04%257C01%257Cpravb%2540microsof
> t.com%257Cbc3399870c0d4105299408d8e5a4cbaa%257C72f988bf86f141af91a
> b2d7cd011db47%257C1%257C0%257C637511843745826011%257CUnknown%
> 257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3Doqte6wCaTBUvrw
> gXVRMcD13YgtspMJyIWMMLlwNuYdY%253D%26amp%3Breserved%3D0
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm