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

From: ianswett <[email-masked]>
Date: Thu, 13 Aug 2020 12:54:01 -0700

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

---

From: ianswett <[email-masked]>
Date: Thu, 13 Aug 2020 13:31:57 -0700

Recovery says "QUIC begins every connection in slow start with the congestion window set to an initial value."

There's no mention of updating the initial congestion window, so at the beginning of the connection is currently the only time it's set.

QUIC advises setting do not fragment, and UDP typically gets dropped instead of fragmented in my experience even without the flag set, so I believe that simplifies the situation.

Given that, along the lines of (iii), I can imagine one potential issue is if the initial window is set to a large value based on some past information and then the MTU is decreased in order to allow the handshake to complete.  Currently there's nothing saying that the IW should be re-calculated if the max packet size decreases during the handshake, and adding one would be along the lines of your second suggested option.

But I'm also fine with removing the twice max datagram size clause, but that seems like a larger departure from existing RFCs, which makes me hesitant.

https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-recovery.md#initial-and-minimum-congestion-window-initial-cwnd

-- 
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#issuecomment-673695661

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2020 19:00:02 -0700

I think that - as a recommendation - this is fine.  Like everything else we recommend in this draft, it is almost certainly not congruent with what implementations will do and that is OK.

My suggestion is that those who want to look into this further do so and document their results in a draft that will be pursued independent of QUIC.  At some point we have to say no to further refinement and that point has passed.

-- 
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#issuecomment-673841019

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 14 Aug 2020 04:31:30 -0700

QUIC seems to me to propose the first IETF CC that with a larger IW for datagrams,. If people in future do happen to use jumbo Ethernet frames, the case Ian describes is sufficiently gross that QUIC needs to suggest/require a remedy. 

I think I'd be happy with either of Iain's 2 simple proposals. 

-- 
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#issuecomment-674030642

---

From: mirjak <[email-masked]>
Date: Fri, 14 Aug 2020 05:24:43 -0700

Gorry you wrote
 "Retransmission with a
segments/packets."

However, if you retransmit because you have experienced loss in the initial round, don't you anyway have to decrease your congestion window?

About this RFC6928 says: 
"Furthermore, to limit any negative effect that a larger initial
   window may have on links with limited bandwidth or buffer space,
   implementations SHOULD fall back to RFC 3390 for the restart window
   (RW) if any packet loss is detected during either the initial window
   or a restart window, and more than 4 KB of data is sent."

So understanding would be that you are actually already supposed to kind or "reset" the initial window, no?

-- 
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#issuecomment-674048845

---

From: ianswett <[email-masked]>
Date: Fri, 14 Aug 2020 11:53:08 -0700

FWIW, I don't have a strong opinion on what to do here, and I'm personally fine with doing nothing as well, but I wrote up the PR that seems most inline with existing RFCs from my reading.

-- 
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#issuecomment-674222224

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Aug 2020 02:13:25 -0700

I agree with Mirja on what TCP should do, and that such paths are recommended to reset IW to RW. That seems safe. My point was slightly different, we could consider for QUIC that the reduction might allow IW (cwnd) to be recomputed based on the actual PMTU. The PR seems to be heading this direction.

-- 
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#issuecomment-674762059