On 4/1/2023 1:46 AM, Michael Tuexen wrote:
On 1. Apr 2023, at 01:59, Christian Huitema <[email protected]> wrote:
There are two different thresholds, amplification and congestion control.
1) If the server flight is larger than 3.6KB, the server will request and
acknowledgment before it continues.
2) The acknowledgement will act as a validation check for the IP address.
(There are details, but in most cases it will.) After that point, the
amplification limit is lifted. The limiting factor is now congestion control,
for which the recommended value would be the initial window (IW). IW is
typically 10 packets, which means the server can send another 12KB before
having to pause for an ACK. As long as the server flight is shorter than 3.6+12
= 15.6 KB, the server hello will require 2RTT.
3) if the server flight is larger than 15.6 K, the server will have to pause
for an ACK, and the exchange will require 3 RTT, or maybe even more.
As Paul point out, if the client knows that the MTU of the path is larger than
1200 bytes, it could send a larger initial packet. If the initial packet is
8KB, the threshold above become 24KB and 104KB.
Hi Christian,
just wondering:
Using IW = min(10*MSS, max(2*MSS, 14600)) from
https://www.rfc-editor.org/rfc/rfc6928.html#section-2
for TCP, which also seems to apply for QUIC according to
https://www.rfc-editor.org/rfc/rfc9002.html#section-7.2
allows you to send 10 packets of 8KB? Wouldn't the second
term limit you to 2 packets in case of the MTU of 8KB?
Yes, sending large packets takes care of the amplification limit, but
does not lift the congestion control limits. In my suggested mitigation,
the client sends:
1- Initial packet containing client hello, padded to 1200 bytes
2- MTU probe, i.e., initial packet containing Ping frame and padded to
the supposed MTU limit.
If only the client hello arrives all limits stay in place. This will
happen if the probed MTU is larger than the actual MTU of the path.
If both packets arrive, the anti-amplification lime is raised to 3 times
1200 bytes plus the probed MTU size -- 27.6KB if probing 8K, 8.1K if
probing 1500 bytes. But as Michael points out, the server MTU is still
1200 bytes -- it won't change until the server engages in PMTU
discovery. The server's congestion window will be IW = 10*1200, 12KB.
Good, but somebody is bound to manufacture server responses larger than
that...
-- Christian Huitema
