Subject: [tcpm] TCP HyStart patch deployment

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 26 May 2015 11:38:08 +0000

Hi

Does anybody know if the TCP Cubic HyStart patch described in the link below is being used widely ?
It does not seem to be implemented in the latest Linux code.
http://patchwork.ozlabs.org/patch/85945/

Regards
Ingemar
=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

"No man has a good enough memory
  to be a successful liar"
    Abraham Lincoln<http://www.brainyquote.com/quotes/authors/a/abraham_lincoln.html>
=================================

---

From: Neal Cardwell <[email-masked]>
Date: Tue, 26 May 2015 08:48:08 -0400

> http://patchwork.ozlabs.org/patch/85945/

It appears that roughly a week after that thread started, the
following patch was added to address that issue:

  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b4636a5f8ca547000f6aba24ec1c58f31f4a91d

Then later on the following patch was added to further refine the
sensitivity of Hystart:

  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=42eef7a0bb0989cd50d74e673422ff98a0ce4d7b

Hope that helps,
neal

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 26 May 2015 14:09:45 +0000

Thanks for the prompt response. 

Noted though that the first suggested first patch wants (http://patchwork.ozlabs.org/patch/85945/) to stretch things a bit further than what the linux.git patches suggest.

I have implemented a HyStart + Cubic (with the linux.git patches) in our LTE system simulator. I seem to get issues that HyStart quite often seem to exit too quickly. I have double and triple checked the code but don't find any differences against the Linux code. One possible reason is that LTE introduces an amount of scheduling jitter. Question is if this is what is causing the problem ?

If I implement the original patch (85945) I seldom get early exits from HyStart, on the other hand I get larger overshoots, and that is of course not optimal.

/Ingemar

> -----Original Message-----
> From: Neal Cardwell [mailto:[email-masked]]
> Sent: den 26 maj 2015 14:48
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]; Eric Dumazet; Yuchung
> Cheng; Sangtae Ha
> Subject: Re: [tcpm] TCP HyStart patch deployment
> 
> It appears that roughly a week after that thread started, the following patch
> was added to address that issue:
> 
> 
> Then later on the following patch was added to further refine the sensitivity
> of Hystart:
> 
>

---

From: Neal Cardwell <[email-masked]>
Date: Tue, 26 May 2015 10:35:20 -0400

> If I implement the original patch (85945) I seldom get early exits from HyStart, on the other hand I get larger overshoots, and that is of course not optimal.

In your tests without patch 85945, is it the HYSTART_ACK_TRAIN or
HYSTART_DELAY mechanism that is triggering early exit of slow start?

Eric Dumazet found HYSTART_ACK_TRAIN triggers early exit often,
particularly if fq pacing is used. You may consider using just
HYSTART_DELAY.

What is the magnitude of the jitter and RTTs for which you are seeing problems?

The delay threshold of 2*min_rtt in the patch you are citing --
http://patchwork.ozlabs.org/patch/85945/ -- seems to allow a very big
overshoot before exiting slow start.

On the other hand, if you get good results for LTE and non-LTE
simulations for something like:

                        if (ca->curr_rtt > ca->delay_min +
                            HYSTART_DELAY_THRESH(ca->delay_min >> 2)) {
or
                        if (ca->curr_rtt > ca->delay_min +
                            HYSTART_DELAY_THRESH(ca->delay_min >> 1)) {

then that starts to sound potentially applicable for general use.

neal

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 28 May 2015 12:08:02 +0000

Hi
And thanks for the tips. I will make a more thorough investigation to see how the suggested changes below affects performance. It may take a couple of weeks though before I have anything meaningful.

/Ingemar

> Sent: den 26 maj 2015 16:35
> To: Ingemar Johansson S
> > Noted though that the first suggested first patch wants
> (http://patchwork.ozlabs.org/patch/85945/) to stretch things a bit further
> than what the linux.git patches suggest.
> >
> > I have implemented a HyStart + Cubic (with the linux.git patches) in our LTE
> system simulator. I seem to get issues that HyStart quite often seem to exit
> too quickly. I have double and triple checked the code but don't find any
> differences against the Linux code. One possible reason is that LTE introduces
> an amount of scheduling jitter. Question is if this is what is causing the
> problem ?
> >
> > If I implement the original patch (85945) I seldom get early exits from
> HyStart, on the other hand I get larger overshoots, and that is of course not
> optimal.
> 
> particularly if fq pacing is used. You may consider using just HYSTART_DELAY.
> 
> On the other hand, if you get good results for LTE and non-LTE simulations for
> something like:
> 
>                             HYSTART_DELAY_THRESH(ca->delay_min >> 2)) { or