Re: [tcpPrague] TCP Prague parameters?

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Szilveszter,

Indeed currently Prague is not fully optimized, and would need the "performance improvements" to be implemented. I also didn't have the resources up to now, but we are encouraging others to contribute to the open source project. I know some are/have merged the kernel version to the BBRv2 version, so we can combine L4S and BBR techniques easier (in both directions). Clearly the Prague RTT independent code could use an algorithm to fall back to RTT dependent again or even slow start when for "some time" no marks have been seen. Seems BBR has a useful BW detection scheme that might inspire 😉. Similarly BBRv2's too aggressiveness as you mentioned can be tuned to targeting the converged RTT-independent marking rate of 25ms RTT flows. The merged code will also allow to use BBRv2 with accurate ECN. As another improvement, I believe Prague can take the latency signal into account on top of marking signal to better respond. I also saw very nice results at some point also taking the ACK rate into account (which also BBR does). So lots of interesting opportunities for CC experts/researchers that can spend more time on it. Let me check when this combined build would become available.

But this doesn't help you now, right? So maybe useful to put things in current perspective: How many flows are you targeting on the 10G link? It would be good to test as well under "normal internet use" conditions where every flow would get around 5 to 50Mbps, typical minimum and probably extreme max for today's interactive streaming applications. On a 10G link this would boil down on having 200 to 2000 TCP flows active. Is this something you can achieve in your tests? I guess for downloads 500Mbps to 1Gbps per flow would be a reasonable limit per user/flow, and there 10 to 20 flows are minimally needed. In those conditions I would expect to see the results you showed with getting up to speed degradation for default prague settings (fair rate for flows with RTT below 25ms).

So it would be good if you can show better results too (I would expect, let me know if not) for Prague with the 25ms rate fairness enabled (so just the default TCP-Prague settings) with enough flows and for base (unloaded) RTTs that are common on the internet 5ms - 25ms base latencies (for most nearby DC access on both mobile and fixed networks). Of course, also add the bad cases, which show where more work needs to be done on the CCs.

Thanks,
Koen.


-----Original Message-----
From: Szilveszter Nadas <[e-mail]> 
Sent: Tuesday, May 18, 2021 4:33 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[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: TCP Prague parameters?

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.