Subject: Path MTU Discovery and Congestion Control

From: Timo Völker <[email-masked]>
Date: Sat, 26 Mar 2022 13:32:19 +0000

Hi,

Section 14.4. in RFC9000 states that PMTU probe packets consume congestion window. I wonder how to deal with that.

I describe my understanding of that with an example. For simplicity, I use IP level sizes for packets and congestion window.

When using DPLPMTUD, we start with a safe PMTU estimation, let's say 1280 B. This gives us an initial congestion window of 12800 B.

Case 1:
If we send a PMTU probe packet with a size of 1500 B, we have (12800 - 1500) B = 11300 B left to send, which are eight full sized (1280 B) packets or nine, if we overbook. This seems OK to me.

Case 2:
But, what if we discovered a PMTU of 12800 B in a previous connection to the same endpoint. After establishing a new connection to the endpoint, I would send a PMTU probe packet for this 12800 B to confirm that this PMTU is still valid. However, that would consume the complete congestion window.

Is my understanding correct?

If it is, how to deal with case 2? Two ideas:

1. Limit the size of PMTU probe packets relative to the current congestion window, e.g. probe packet <= 1/4 cwnd. For case 2, this would mean to start sending a PMTU probe packet with a size of 3200 B, even we know/expect better. It also would block PMTUD until an increase of the congestion window.

2. Restrict the congestion window consumption to the current PMTU estimation. For case 2, this would mean to add only 1280 B to bytes_in_flight, even if we send a PMTU probe packet with a size of 12800 B.

More/better ideas, comments?

Timo