[tcpPrague] TCP Prague parameters?

[Szilveszter Nadas <[e-mail]>]

Hi Koen,

Thank you for your guidance below.  We did not have resources in the end to investigate this further. 

However, now we are running an experiment where we plan to use TCP Prague as an example for scalable CC. We plan to use Prague, because DCTCP is considered to be flawed in the internet RTT regime, and our experience is that BBRv2 scalable mode is too aggressive.

We use the following code:
https://github.com/L4STeam/linux.git
2021 jan 11
66331636f0dd4930916ee142ad5f505ac8e53e25

We experienced very slow convergence with  prague_rtt_scaling = RTT_CONTROL_RATE so we set it to 0 (RTT_CONTROL_NONE). Other than that we plan to use the default parameters of Prague. Is that OK? Do you recommend to change anything else?

Best Regards,
Szilveszter

FYI - some preliminary results of our experiments are attached. We use a scheduler similar to the one in this article: http://ppv.elte.hu/cc-independent-l4s/ . The attached plots are analogous to Fig 3a, but it is Prague instead of dctcp, and 10 Gbps instead of 1 Gbps



---
From: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> 
Sent: December 2, 2020 22:22
To: Szilveszter Nadas <[e-mail]>; [e-mail]
Cc: Ferenc Fejes <[e-mail]>; Gombos Gergo <[e-mail]>; LAKI Sandor <[e-mail]>; Tilmans, Olivier (Nokia - BE/Antwerp) <[e-mail]>
Subject: RE: [tcpPrague] A Congestion Control Independent L4S Scheduler - TCP Prague preliminary results

Hi Szilveszter,

First thing is to check that you can reproduce our results. With the previous (non-RTT-independent) Prague, can you confirm you get the following results?

Normally with the right coupling (p_C = p'^2 and P_L = 2*p') and if their total RTT is the same, Cubic (in Reno mode) and Prague get about the same throughput (Prague might get up to twice the throughput max). Total RTT means base RTT + all Queuing delay for each flow's round trip path. Can you confirm this, or do you see a bigger difference?

One way to check this on an equal base RTT setup is to use a singleQ PI2 which is doing the  correct marking or dropping according to the above equations, because the single Q  gives both classes the same latency (single Q = same Q delay). Another way is to use a DualQ and compensate the 15ms Classic latency with a 15ms bigger base RTT for Prague. In both cases you would see them getting around the same throughput. If the BDP (rate and/or RTT) becomes bigger, Cubic will start to get a higher throughput than Prague.

Note that if you install the latest Prague version from our L4STeam git, the default is now to be RTT independent below 25ms. So any Prague with a lower than 25 ms throughput will behave as a 25ms RTT flow (effective after 500 RTTs), and will get the same throughput as a 25ms RTT flow. You could test this with Prague on a DualPi2, when competing with a Cubic flow with a base RTT of 10ms. All RTTs (you can try even a mix of different ones in parallel) below 25ms should now get the same throughput as the Cubic one (because it has also a total RTT of 25ms).

Any other effective RTT combinations different than the equal ones should follow the "throughput ratio equals the inverse RTT ratio" rule. One exception is when non-Rtt-independent Prague flows with different RTTs ares competing on a STEP AQM. In that case the difference is bigger than that ratio, because the lowest RTTs are getting on-off marking, and behave as 1/p², instead of 1/p as they will get a more stable marking probability over their (much bigger) RTTs.

Let me know if you can reproduce the above behavior. If not, maybe try using the Linux DualPI2, and if still not as expected, then we need to dive deeper to find the reason.

Thanks,
Koen.