Congestion control during application limited state

[pravb]

The text in recovery draft 19 says "The congestion window should not be increased in slow start or
congestion avoidance when it is not fully utilized". This is a deviation from how congestion control works in deployed TCP implementation. We need a crisp definition of what is meant by "full utilization". I also have concern that this will make QUICs performance for bulk transfers poorer than TCP because application I/O patterns and scheduling of the sending thread will affect cwnd growth. After making the definition crisp and consensus that we need to include such a provision, the pseudo code will need to be updated to handle this as well.

[janaiyengar]

@pravb: You're right, this needs to be made crisp and we need to add pseudo-code to handle this. Do you have a strawman proposal? How does Windows TCP do currently to handle growth during app limited periods?

The naive approach doesn't work, since it prevents growth in the second RTT during slow start. I don't remember anymore what Linux TCP does, but I can look into that.

[janaiyengar]

FWIW, my read of the Linux code tells me that at ack receipt time, the sender considers itself app-limited if in slow-start and cwnd > 2 x inflight, or if in cong-avoid and cwnd > inflight.

[ianswett]

Jana, your reading matches my memory, but I thought there was an extra "fq-pacing quantum" added to inflight in the second case?

[pravb]

So there is no standard mechanism defined for this in any of the TCP RFCs especially the ones describing modern congestion control like CUBIC and DCTCP. Instead of providing a particular algorithm I propose we leave the handling of this to the implementations? Maybe we can refer implementers to https://www.rfc-editor.org/rfc/rfc7661.txt for possible ideas.

[evolodina]

I’m not sure, but I guess RFC4960 & SCTP implementation may be useful in this case.

[ianswett]

I found this in RFC4960(https://tools.ietf.org/html/rfc4960#section-7.2.1):
"When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
use the slow-start algorithm to increase cwnd only if the current
congestion window is being fully utilized, an incoming SACK
advances the Cumulative TSN Ack Point, and the data sender is not
in Fast Recovery. Only when these three conditions are met can
the cwnd be increased; otherwise, the cwnd MUST not be increased."

The current QUIC recovery text tries to clarify what fully utilized means, particularly in the presence of pacing.

[janaiyengar]

I'm quite familiar with RFC 4960, and it does not have anything that is particularly helpful here. @ianswett: I didn't see an fq-quantum in the code, but I could also be missing something.