[quicwg/base-drafts] QUIC's Initial Congestion Window specification is incorrect (#3997)

[ianswett <[e-mail]>]

Broken off from Gorry's comments in #3992 per @martinthomson request

ISSUE:

/Endpoints SHOULD use an initial congestion window of 10 times the 
maximum datagram size (max_datagram_size), limited to the larger of 
14720 or twice the maximum datagram size./

- I would like to revist this. We talked in Montreal and at that time I 
understood the equivalence to TCP for the case where a large MSS was 
supported by the path, as per RFC6928. I have since revisited this topic 
and would like to suggest the present IETF advice for TCP is in fact 
wrong for the large initial MSS case, and that this draft should not 
perputate that mistake for QUIC. The issue comes when IW is initialiased 
for a path with a very large PMTU, but that PMTU is not in fact 
supported by the path.

- (i) I observe the TCP case where the path does actually support the 
large PMTU, and a receiver advertises an appropiately large MSS. The 
path then uses the large MSS naturally and all is OK, but stands the 
risk of (ii) below, since the path might not be the same as a previous 
case.

- (ii) if the receiver interface supports a large MTU, and the the 
receiver advertises a large MSS, but the sender does not have a large 
MTU, the advertised large MSS changes the IW, and can vastly increase 
the number of packets in the initial window. This was not intended. It 
should not happen by default and can cause congestion and increase 
latency. This is wrong.

- (iii) if the receiver interface supports a large MTU, and the the 
receiver advertises a large MSS, the sender has a large MTU, but the 
path does not support this large PMTU. Sending with the large MSS causes 
packet loss (or possibly IP-Frag if that was allowed). This was not 
intended, and may well predjudice performance. Retransmission with a 
more appropiate PMTU does not change the IW, which then sends too many 
segments/packets. For TCP it would probably have resulted in a RTO and 
collapsing cwnd. This can cause congestion and increase latency. This is 
wrong.

... So why was this was not seen as a real-life problem. I think the 
advice in RFC6928 should have considered the impact of PMTU failure, but 
I conclude it doesn't normally hurt TCP. At the time this was written, 
few interfaces really did support more than a 1500B MTU (it may still be 
so), and MSS was often effectively limited by the server (sometimes by 
config). For servers that did advertise a larger MSS, or where the path 
supports less than 1500B, then MSS-clamping by routers along a path 
would often have triggered. Still, the sender would normally receiver 
only a feasible advertised MSS.

... QUIC is different :-). There is no middlebox intervention for MSS 
clamping - therefore QUIC is unable to avoid (iii), and likely would be 
impacted by (ii). I therefore suggest that QUIC chooses either to 
eliminate the /or twice the maximum datagram size./ clause, **or** 
provides a requirement that if this datagram size is not confirmed, then 
the IW needs to be limited to 14720 B.

... Finally, I would expect QUIC to perform better if it were to set up 
the connection, and then immediately probe for the larger size, since 
DPLPMTUD is anyway needed to utliise a larger PMTU and avoid 
blackholing. However, I don't think we need to explain this in the ID.

---

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3997