[tcpPrague] Prague Cwnd reduction in CWR state

[Deepak K <[e-mail]>]

Hi everyone,

I am currently trying to align TCP Prague in the ns-3 network simulator
with that of Linux.
In the process, I came across an interesting behaviour: if the sender is in
a CWR state, the cWnd update would look something like
cWnd = cWnd - cWnd * alpha / 2     --- (1)
I noted that this is how DCTCP updates its cWnd in Linux.

But in the case of current Linux Prague code, the value
reduction = cWnd * alpha / 2           --- (2)
is subtracted from the cwnd_cnt variable, which sort of acts as a cushion
and reduces the cWnd over many RTTs (in prague_update_cwnd( ) ), instead of
reducing it instantaneously.

I would like to mention a noticeable difference resulting from the approach
taken in (2). All the following simulations were carried out in ns-3.

While reproducing the single-flow topology from Pete Heist's scenario (
https://github.com/heistp/sce-l4s-ect1#scenario-1-one-flow : a Prague
sender, DualQ bottleneck and a Prague receiver), I decided to implement
both approaches in ns-3 to see how they differ from each other.

For lower bottleneck bandwidths (5mbps and 50mbps in the scenarios), I
didn't observe much difference between (1) and (2), and the approach in (1)
aligned with the cWnd graphs from Linux (which I obtained separately via
namespaces).

However, for the scenario with a higher bottleneck speed - 250mbps in
particular, the difference between (1) and the Linux approach (2) was
significant.
With (1), the cWnd was reduced by a smaller value when compared to (2), in
ns-3.This meant that (2) took more time to reach a stable value in Additive
Increase compared to (1). I also observed that cWnd reduced to a much lower
value in Linux (again, graphs obtained via namespaces) when compared with
the ns-3 plots from (1).

My guess would be that in (2), since cWnd is decreased gradually, the
sender would not immediately relieve the queue of congestion, and hence
would receive few more ECE marks leading to further reduction later on when
compared to (1).

I noted this behaviour for both higher (80ms) and lower (20ms) values of
RTT, with a 250mbps bottleneck.
Could you comment on the reason for choosing approach (2) in Linux instead
of (1)?

Thanks.