Re: [tcpPrague] A Congestion Control Independent L4S Scheduler - TCP Prague preliminary results

["Tilmans, Olivier (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Szilveszter,

 
 > 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).

Thanks for sharing these.

* Short answer:
DCTCP actively hurts itself, tripping the step AQM unnecessarily.
This is mostly benign in DC environments due to the almost non
existent RTT, and small cwnd, but causes observable performance hits elsewhere.
Prague implements fixes for these issues.

* Long answer:
Please find below the main changes from dctcp to prague. The intuition
behind these is to avoid triggering the step AQM part of the dual queue
when there is classic traffic, or limit the extent of the received marks.
The first goal ensure that, when there is classic traffic, prague only
receives marks from the coupled PI2 component, which are strong enough on
their own to keep the L4S queue empty most of the time. Additionally
getting marks from the step AQM means that prague is hurting itself, as
it will reduce more than necessary. The second goal ensures that prague
does not unnecessarily drive the AQM (either PI2 or the step) to
high-marking rate; again because it will hurts its throughput and also
because it will create a standing queue.

Note that depending on your experimental setups, not all the below factors
will contribute.

1. Prague is always paced, regardless of the egress qdisc on the data sender,
   and paces itself at 100% of the estimated BDP.
	DCTCP is only paced when used in combination with fq, and paces at 120%
	of the BDP when that is the case.
2. Prague actively limits its gso bursts (defaults to 250us)
	DCTCP uses Linux defaults, 1ms
3. Prague implements a more accurate internal marking estimate (alpha)
	DCTCP, especially when operating with low marking probabilities, will
	tend to push down alpha to 0, delaying its response to marks (and thus
	increasing queue pressure/causing larger reduction down the line)
4. Prague carry over sub-cwnd reduction, such that multiple marks in a row
   occurring at low overall probability will eventually cause a cwnd reduction
	DCTCP's cwnd reduction code has no memory, i.e., as long as alpha is
	low enough compared to cwnd, no cwnd reduction will ever occur. This
	again drives the aqm to larger mark probabilities.

All of these points contribute to prague being more gentle towards the queue,
and more reactive to the received marks (i.e., achieving a lower overall
marking level)--the direct effect being smaller cwnd reduction (thus sawtooth)
than DCTP, which is critical when operating at higher e2e RTTs with a shallow
queue since it lowers the time to recovery.

Additionally, when operating over a long RTT path and controlling by PI2 (i.e.,
random marking, such that it receives marks almost every RTT--as opposed to a
step where it receives nothing for several RTTs and then a RTT with most of the
packets being marked), DCTCP suffers from the inaccurate/memoryless computations
in 3./4. and its interactions with Linux's PRR code (which prague does not use),
which can prevent it from ever reaching its expected rate.

I hope this helps to understand a bit better why prague appears to be more
aggressive--it is actually the opposite: dctcp systematically hurts itself
at longer base RTT, hence progressively give way as the RTT increases.
You can validate this by observing that the expected rate ratios between
classic flows and prague over the dualQ match the theoretical equations
(compounding the queue delay difference) even that higher base RTTs, which
is not the case for DCTCP.


Best,
Olivier