Subject: [quicwg/base-drafts] Crypto Frames/Packets Aren't Blocked by CC (#2377)

From: Nick Banks <[email-masked]>
Date: Mon, 28 Jan 2019 00:00:48 -0800

Initial/Handshake packets with CRYPTO frames should not be prevented from being sent my cwnd. I thought we had text to this effect already, but I couldn't find it.

-- 
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/2377

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 28 Jan 2019 08:17:40 -0800

Original transmissions are still blocked by cwnd atm, retransmissions are not blocked on cwnd. Previously this would be done by considering all handshake packets as lost, now in draft 18, you would just retransmit all unacked handshake packets

-- 
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/2377#issuecomment-458196310

---

From: Nick Banks <[email-masked]>
Date: Mon, 28 Jan 2019 14:25:22 -0800

Why should original transmissions be blocked? On the server side, you have the 3x amplification logic, but I view that as separate from CC. Once the client's IP has been validated, then you have no restrictions. On the client, I don't see any reason to restrict it at all.

-- 
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/2377#issuecomment-458326669

---

From: ianswett <[email-masked]>
Date: Mon, 28 Jan 2019 15:01:10 -0800

In most cases, even with 0-RTT responses, you'd send the crypto data before 1-RTT data, so the crypto data wouldn't be blocked by congestion control.

I think the interesting case is what if the crypto data is large(ie: >IW10)?  It seems like congestion control should probably apply there?

gQUIC did ensure crypto packets were never blocked by congestion control, so I suspect this was in the docs early on, but has subsequently removed.  I suspect it was rarely if ever a practical issue in our implementation, but it is a bit easier to reason about if CRYPTO frames are always sent immediately.

-- 
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/2377#issuecomment-458337059

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 29 Jan 2019 17:28:41 -0800

I think it just makes it easier to make crypto subject to the same cc algorithm vs making a special case for it in this way. Why would it matter if crypto is limited by CC?

-- 
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/2377#issuecomment-458775432