Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment

From: Piers O'Hanlon <[email-masked]>
Date: Fri, 5 Jun 2015 18:01:41 +0100

Hi Ingemar,

Looking at linux-4.04 git code:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/ipv4/tcp_cubic.c?id=refs/tags/v4.0.4#n403

It seems the HYSTART_DELAY code has been tweaked into a somewhat similar direction (right shift 3 instead of the original 4) to the patch:
			    HYSTART_DELAY_THRESH(ca->delay_min >> 3)) {

Although the ACK train detection does appear unchanged.

It would seem that Hystart could have issues at very high rates as it does rely on a few default parameters that might not be suitable for such environments. I can also imagine that it may not work so well on WiFi with block ACKing as Hystart uses a fixed window of 8 packets to estimate current delay which may end up being one block of packets...

Did you try asking this question on any Linux networking lists?

Cheers,

Piers.

On 26 May 2015, at 12:38, Ingemar Johansson S wrote:

> 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>
> =================================
> 
> _______________________________________________
> end2end-interest mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/end2end-interest
> Contact [email-masked] for assistance.

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 22 Jun 2015 09:23:17 +0000

Hi

Sorry for the delay and thanks for the response. The 4.0.4 is the one that I have implemented. I have not involved any Linux networking list for the moment. That is perhaps a good idea once I get to understand this better.

Currently I don't have any conclusive results that shows that there is a real issue with the current HyStart. Yes I can see a few cases where mainly the DELAY algorithm exits a bit early, and while one can argue that it is a bit too early, there seems anyway to be enough data in the RLC buffers to utilize the link well in most of the cases. It is only  in a few corner cases that I have seen issues with a very low link utilization.

As I cannot right now find a larger set of cases where HyStart is a general issue it has not been possible to try out Neal's suggested modifications.

I still have some more investigations to do after the vacation, this may show if there are general issues with HyStart. 

/Ingemar

> -----Original Message-----
> From: Piers O'Hanlon [mailto:[email-masked]]
> Sent: den 5 juni 2015 19:02
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]
> Subject: Re: [e2e] TCP HyStart patch deployment
> 
> Hi Ingemar,
> 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-
> stable.git/tree/net/ipv4/tcp_cubic.c?id=refs/tags/v4.0.4#n403
> 
> It seems the HYSTART_DELAY code has been tweaked into a somewhat
> similar direction (right shift 3 instead of the original 4) to the patch:
> 			    HYSTART_DELAY_THRESH(ca-
> >delay_min >> 3)) {
> 
> It would seem that Hystart could have issues at very high rates as it does rely
> on a few default parameters that might not be suitable for such
> environments. I can also imagine that it may not work so well on WiFi with
> block ACKing as Hystart uses a fixed window of 8 packets to estimate current
> delay which may end up being one block of packets...
> 
> >    Abraham
> Lincoln<http://www.brainyquote.com/quotes/authors/a/abraham_lincoln.h
> tml>