Subject: [iccrg] When is congestion control safe and fair

From: Markku Kojo <[email-masked]>
Date: Thu, 17 Dec 2020 13:55:19 +0200 (EET)

Dear congestion control experts,

I have a simple, principled question regarding congestion control.

Assume a TCP sender is fully utilizing its bottleneck link capacity with 
cwnd=40MSS and a number of connections become active to compete on the 
link capacity of the same bottleneck. This happens to result in a loss 
event where the second half of current window of data is dropped due to 
congestion. In addition, the TCP sender becomes application limited for 
a short while as the application does not give new segments to send.
Roughly after a period equalling to RTO, the application has again more 
data to send.

To help considering this, you may assume 7 TCP flows became active to 
compete on the same bottleneck, which would mean ~ 5 MSS/RTT for each 
flow to equitably share the bottleneck capacity.

Using standard congestion control this would cause an RTO and the TCP 
sender would enter RTO recovery in conventional slow start as follows:

0. timeout expires
1. set cwnd=1; ssthresh = FlightSize/2 = 20; retransmit one segment
2. Ack arrives for the segment in step 1;
    set cwnd=2; retransmit 2 segments
3. slow start continues as usual ...

Would it be safe and fair to other competing flows if we change the 
congestion control behavior of the TCP sender in question as depicted 
below?

If so, how would you justify it (also taking into account congestion 
control principles as per RFC 2914)?

Proposed change:

0. timeout expires;
1. (set temporarily cwnd=1); resend one segment
2. Ack arrives for the segment in step 1;
    set cwnd=ssthresh=FlightSize/2 = 20;
    retransmit 19 segments plus send one new segment
3. Continue sending with cwnd=20 until all 20 losses
    in the current window are repaired or RTO fires;
    this would also include a way to detect possibly
    dropped retransmissions which would get retrasmitted again
    without adjusting the send rate (i.e., without modifying cwnd)
    and thereby increasing the chance that all drops are succesfully
    repaired before RTO expires (*)
    So step 3 would essentially be recovering in slightly
    modified fast recovery, i.e., sending also new data if cwnd
    allows

(*) note that RTO may allow a time period of several RTTs to continue this 
recovery in step 3

The proposed change would definitely improve loss recovery efficiency 
of the modified TCP sender but what would be the implications?

Best regards,

/Markku

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 17 Dec 2020 15:00:06 +0200

> On 17 Dec, 2020, at 1:55 pm, Markku Kojo <kojo=[email-masked]> wrote:
> 
> The proposed change would definitely improve loss recovery efficiency of the modified TCP sender but what would be the implications?

The major safeguard I think we'd have to insist on is that any further loss events during the retransmissions MUST be treated as indications of congestion and cause a reduction in cwnd.  Otherwise it looks possible for the recovery period to continue indefinitely at a constant cwnd and with a high loss rate, which seems dangerous.

Behaviourally, this looks similar to an ECN congestion event reducing cwnd to 20, followed by a brief period of application-limited inactivity, followed by data being available again to fill the cwnd.  Clearly this new traffic would respond to congestion signals as normal, and so should anything that looks like it.

 - Jonathan Morton