[tcpPrague] TCP Prague preliminary results & Hystart with larger RTT

Changing the title, to focus on this obserevation...

On 13/11/2020 07:27, Ingemar Johansson S wrote:
>
> Hi
>
> Just some food for thought.
>
> Hybrid Slowstart (HyStart) in Cubic is known to have the problem that 
> it can exit to congestion avoidance prematurely. We have in fact seen 
> issues with HyStart in cellular and the outcome is that it over-reacts 
> to scheduling jitter.
>
> This issue was mentioned in the long since expired 
> https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 
> <https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02> (section 
> 4) and a presentation at ICCRG 
> https://datatracker.ietf.org/meeting/96/materials/slides-96-iccrg-1 
> <https://datatracker.ietf.org/meeting/96/materials/slides-96-iccrg-1>
>
We've also been recently testing QUIC over broadband satellite systems, 
and we also observe the same sort of reaction to the path 
characteristics (likely also due to increased jitter in the 
timeslot-based transmission of ACKs when used on a shared broadband 
satellite return link). The result was a forward path that was 
under-utilised. These experiments used google's (latest) QUIC - and we 
saw a resulting reduction in the throughput when the RTT was larger.

> The Linux TCP stack enables HyStart with both the delay and ack train 
> algorithms on by default. It could be a good idea to at some stage 
> rerun the tests with HyStart completely disabled. I am not sure in 
> this is the reason but believe that it is worth to rule out the 
> problems with HyStart .
>
> /Ingemar
>
> PS HyStart++ developed by Praveen and others at Microsoft  instead 
> exits to a limited slowstart 
> https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03 
> <https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03>. 
>
>
This topic isn't new, but I think might need some attention wrt to new 
transport methods, and might be something to explore for a range of 
protocols. If it is still a concern, maybe we should open this up 
perhaps initially in TCPM ?

Gorry
>
> *From:* De Schepper, Koen (Nokia - BE/Antwerp) 
> <koen.de_schepper@nokia-bell-labs.com>
> *Sent:* den 12 november 2020 10:35
> *To:* Szilveszter Nadas 
> <Szilveszter.Nadas=40ericsson.com@dmarc.ietf.org>; tcpprague@ietf.org
> *Cc:* Ferenc Fejes <fejes@inf.elte.hu>; Gombos Gergo 
> <ggombos@inf.elte.hu>; LAKI Sandor <lakis@inf.elte.hu>
> *Subject:* Re: [tcpPrague] A Congestion Control Independent L4S 
> Scheduler - TCP Prague preliminary results
>
> Hi Szilveszter,
>
> Interesting work, thanks for sharing. There is indeed a very big 
> difference between how DCTCP behaves today in recent kernels, than 
> what we used in the original L4S work testing (Linux kernel 3.19). 
> That original version was a “clean” DCTCP version that matched very 
> well the theoretical equations: r=2/(p.RTT) for uniform stable random 
> and r=2/(p².RTT) on/off marking. Due to many interactions, integer 
> range constraints, pacing/GSO interactions and bugs, the performance 
> really degraded in the recent Linux versions. These issues were fixed 
> within the Linux Prague version, so that is why Prague should perform 
> “better” in respect to matching the equations. It would be interesting 
> to get an idea of the deviation from the r=2/(p.RTT) equation in your 
> tests (relevant in DualPI2 as the coupling gives a smooth 
> probability). Collecting the average RTT (base + queuing latency), 
> marking probability, and rate would make it possible to evaluate this.
>
> Main reasons why we saw deviations is when the probability varies a 
> lot in time. As you might know DCTCP’s (and Prague’s) equation becomes 
> r=2/(p².RTT) when it receives on/off marking episodes (on episodes in 
> the order of 1 RTT, off in the order of multiple RTTs). Any not so 
> stable marking probability results in a rate between those 2 
> boundaries. This is the theory, looking forward on how your practice 
> matches this.
>
> From a first quick look at the results it might not deviate that much, 
> I guess. The more aggressive part is probably due to the RTT 
> unfairness: 1 to 5 rate ratio (with a 5ms base RTT, Classic gets a 
> queue of 5ms+20ms target, so about 25ms and 5 times less throughput). 
> Did you try to use the RTT independent version? If you set it to the 
> f=max(15, RTT) mode, the minimum effective RTT becomes 15ms, so the 
> rate ratio is 3 to 5 in that case.
>
> Thanks and Regards,
>
> Koen.
>
> *From:* tcpPrague <tcpprague-bounces@ietf.org 
> <mailto:tcpprague-bounces@ietf.org>> *On Behalf Of *Szilveszter Nadas
> *Sent:* Tuesday, November 3, 2020 6:30 PM
> *To:* tcpprague@ietf.org <mailto:tcpprague@ietf.org>
> *Cc:* Ferenc Fejes <fejes@inf.elte.hu <mailto:fejes@inf.elte.hu>>; 
> Gombos Gergo <ggombos@inf.elte.hu <mailto:ggombos@inf.elte.hu>>; LAKI 
> Sandor <lakis@inf.elte.hu <mailto:lakis@inf.elte.hu>>
> *Subject:* [tcpPrague] A Congestion Control Independent L4S Scheduler 
> - TCP Prague preliminary results
>
> Hi all,
>
> During the review of our article “A Congestion Control Independent L4S 
> Scheduler” we received comments from one of the reviewers, on why we 
> did not also evaluate TCP Prague. So now we rerun the test cases with 
> replacing DCTCP to TCP Prague.
>
> The results are at the below link. We are somewhat surprised by much 
> increased aggressiveness of TCP Prague. Can you comment on it? The 
> settings and setup we used are described in the pdf (and in the 
> original article).
>
> Results: http://ppv.elte.hu/tcp-prague/ <http://ppv.elte.hu/tcp-prague/>
>
> Original article (including YouTube presentation): 
> http://ppv.elte.hu/cc-independent-l4s/ 
> <http://ppv.elte.hu/cc-independent-l4s/>
>
> Can you comment on the results and the settings we used?
>
> Cheers,
>
> Szilveszter
>
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague