s2n-quic
s2n-quic copied to clipboard
aws
Congestion window increases after MTU increase
When the MTU for a path is increased after successfully MTU probing, the congestion window (measured in bytes) is recalculated based on the new MTU size: https://github.com/awslabs/s2n-quic/blob/09d75247a3ddac8ab0930b0d994903c99bf784cb/quic/s2n-quic-core/src/recovery/cubic.rs#L374-L386
RFC 8899 specifies that this should not happen:
An update to the PLPMTU (or MPS) MUST NOT increase the congestion window measured in bytes [RFC4821].
The downside of fixing this is that when the MTU increases, the number of packets in the congestion window will decrease. If middleboxes are mostly buffering based on packet count, rather than total bytes, this would mean we are missing out on a potentially larger window. I haven't been able to find much information that routers/switches behave this way though.
Other implementations are following the specification in RFC 8899: Linux TCP, which tracks the congestion window (tp->snd_cwnd) in packets, does decrease the number of packets in the window when the MTU is increased, to maintain the same bytes in the congestion window: https://github.com/torvalds/linux/blob/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4/net/ipv4/tcp_input.c#L2710-L2712
Google Quiche tracks the congestion window in bytes, but does not change it when the MTU changes
The impact of this is limited, as the most likely time for an MTU increase is during Slow Start, when the congestion window has not reached a large size yet, but is rapidly growing.
Hi there, I am currently implementing PLPMTUD for Quinn and came across this issue. I'm a bit confused, because RFC 9002 says here that:
If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.
Are RFC 8899 and RFC 9002 contradicting each other?
Are RFC 8899 and RFC 9002 contradicting each other?
I believe RFC 8899 is referring to the current congestion window at the moment the MTU is increased, while RFC 9002 is referring to the initial window. I'm not sure recalculating the initial window would matter much though, unless you are remembering MTUs across connections and start a new connection with a previously discovered MTU.