[tcpm] CUBIC WGLC Issue 6 (WAS: [NTAP/rfc8312bis] restrict use of cwnddirectly on a congestion event (PR #148) )

[Markku Kojo <[e-mail]>]

Hi Matt, all,

I'm replying to this on the tcpm wg mailing list (and changing the 
subject line) to keep the important discussions where they belong to. See 
inline below.

On Wed, 20 Jul 2022, Matt Olson wrote:

> 
>
>             I'm happy with a simple "on ACK, if inflight < cwnd/2, then don't grow cwnd". I just
>             want to confirm that is what the spec is supposed to be recommending, because the
>             wording makes it unclear whether the recommendation is explicitly to do the more
>             complicated RFC 7661 logic.
>
>       I can fix this in the proposed text.
> 
> Thanks! Happy to hear we will be recommending this simple approach.
>
>             And I still want to know why this requirement is only being applied to implementations
>             that use cwnd rather than inflight for setting ssthresh. It's like "it grows more in
>             those implementations, so try to offset that by capping cwnd based on inflight", but
>             when there is no loss and a low send rate, even implementations that use inflight for
>             setting ssthresh will see unbound cwnd growth, so why isn't this recommendation being
>             made across the board?
>
>       The point is to set cwnd based on actual inflight data or data acknowledged as that determines the
>       true bytes that are flowing in an end-to-end path. If flight_size and cwnd were always similar,
>       then we don't need to add any new text - you can use either. Its just because cwnd can grow higher
>       than actual flight_size for app-limited use cases (for example), we want to set the new cwnd based
>       on actual bytes being transmitted.
> 
> But like I said, even for implementations that set ssthresh = inflight*0.7 on congestion events, the cwnd can
> grow significantly beyond inflight. So I am asking why we are not recommending this cap for those
> implementations too.

If I understood it correctly, Matt has an important point here but that 
is different from what the restriction in my proposed text and the text 
in the stds track RFCs are addressing. We have two separate problem 
scenarious to solve.

1. A congestion event occurs when a sender is rate limited, i.e., inflight 
is less than cwnd.

If a TCP sender that uses cwnd to set a new value for ssthresh on 
congestion events is allowed to increase cwnd beyond inflight, it may not 
respond to congestion effectively at all. E.g., if inflight = 50, cwnd 
has been inceased to 100 for an app-limited sender and loss is detected, a 
Reno sender using ssthresh = cwnd/2 = 50 will effectively not react to 
congestion event at all but will continue sending at the same rate. This 
is in conflict with the basic congestion control principle that the 
sender must react to congestion. A CUBIC sender would be almost fully 
unresponsive for two congestion events: first, ssthresh = 100*0.7=70, 
second, ssthresh=70*0.7=49. A sender employing stds track (RFC 5681) or 
RFC 7661 response do not incur the same incorrect behaviour because the 
sender calculates a new ssthresh value using FlightSize (or pipeACK).

This is the case my proposed text was addressing. The current modified 
text is incorrect as it allows cwnd <= 2*inflight, that is, it would 
allow CUBIC to not react to all congestion events (in full).

2. A sender is rate limited, i.e., inflight is less than cwnd, and there 
is no congestion event but the sender stops being rate limited and may end 
up sending a (large) burst of data unless limeted somehow.

I believe Matt is concerned with the case 2 where the TCP sender is 
application data limited or rwnd limited but is allowed to increase its 
cwnd without any limits. If the cwnd has increased to a high value and the 
TCP sender stops being app data and/or rwnd limited, this may result in 
a very large burst of data to send which is undesireable. RFC 7661 limits 
this burst by not allowing the cwnd to increase if pipeACK < 1/2*cwnd and 
advices avoiding bursting at line rate by applying pacing or other 
ways to control the sending rate in such a case.
On the other hand, if we allow the same with a simple approach currently 
proposed ("on ACK, if inflight < cwnd/2, then don't grow cwnd") for a 
sender that uses cwnd to set the new value for ssthresh we leave the 
problem scenario 1 above unaddressed and end up incorrect sender 
behaviour. That's one major reason why using FlightSize in setting the 
new value of ssthresh should be the recommended way to address the both 
problem cases; I tried to explain this already earlier but obviously 
failed in articulating it.

So, the case 2 is a valid concern that the current standards track RFCs 
(e.g., RFC 5681 and RFC 9002) do not address but RFC 7661 (Experimental) 
does. If we (wg) decides to advance RFC 7661 to stds track, we already 
have a way to address it properly for stds track CC. I don't find it 
reasonable to solve it in the RFC series separately for a sender using 
cwnd to set a new value for ssthresh (as it is tricky to get correct).

Thanks,

/Markku

> —
> Reply to this email directly, view it on GitHub, or unsubscribe.
> You are receiving this because your review was requested.[png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEUAAACnej3aAAAAAXRSTlMAQObYZgAAAApJREFUCNdjY
> AAAAAIAAeIhvDMAAAAASUVORK5CYII=] Message ID: <NTAP/rfc8312bis/pull/148/[e-mail]>
>