Subject: [tcpPrague] Queries about prague linux code

From: Deepak K <[email-masked]>
Date: Sat, 8 Aug 2020 23:08:41 +0530

Hello everyone,
Hope you're doing well. I had a couple of quick questions about the current
TCP Prague code at https://github.com/L4STeam/linux

1) There was a mention in Page 6 here (
https://www.bobbriscoe.net/projects/latency/tcp-prague-netdev0x13.pdf) that
if Prague encounters a packet loss while in CWR state, ssthresh would be
reduced by (2+alpha)/4 instead of the usual 50% reduction. However as far
as I understand, the current code reduces it by half irrespective of
whether it's in CWR. Is that right?

2) I have some questions with the flow of code when RTT scaling heuristic
is particularly set to RTT_CONTROL_ADDITIVE.
In prague_ai_ack_increase (), the function
rtt_scaling_ops->ai_ack_increase() is called, with the parameter srtt_us.
This in-turn calls prague_rate_scaled_ai_ack_increase() with the same
parameter value. Now, srtt_us is compared with the result of
prague_target_rtt(). This function maps to prague_dynamic_rtt_target(),
which returns ca->rtt_target + srtt_us.

So, doesn't this lead to a comparison between srtt_us and ca->rtt_target +
srtt_us, which is redundant?

Thanks!

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 10 Aug 2020 14:08:18 +0000

Hi Deepak,
 
 > 1) There was a mention in Page 6 here
 > (https://www.bobbriscoe.net/projects/latency/tcp-prague-netdev0x13.pdf)
 > that if Prague encounters a packet loss while in CWR state, ssthresh would
 > be reduced by (2+alpha)/4 instead of the usual 50% reduction. However as
 > far as I understand, the current code reduces it by half irrespective of

Yes. The paper indeed advocates to not blindly reduce by 50% but also factor
in how much the connection might have already reduced (i.e., to avoid the
avalanche effect a full RTT of marks with one drop at the end would have),
but stayed as a (very) low priority item. We would welcome of course any
patch/test/... around this point.

 > In prague_ai_ack_increase (), the function rtt_scaling_ops-
 > >ai_ack_increase() is called, with the parameter srtt_us. This in-turn
 > calls prague_rate_scaled_ai_ack_increase() with the same parameter value.
 > Now, srtt_us is compared with the result of prague_target_rtt(). This
 > function maps to prague_dynamic_rtt_target(), which returns ca->rtt_target
 > + srtt_us.
 > 

Yes, this is a code-reuse artifact. The comparison you point enables to
scope the cwnd-scaling code to only operate in a certain RTT region (e.g., only
be active for the sub-10ms RTT flows as that's where most co-existence
problems are located). Since the _ADDITIVE heuristic scales the cwnd
irrespectively if the base RTT, that check is indeed always bypassed.

Best,
Olivier