Subject: [quicwg/base-drafts] Possible dead lock with 0RTT and depleted congestion window (#2984)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 21 Aug 2019 23:28:19 -0700

Lets suppose that client sends HTTP/3 request in 0RTT, and server sends its response in Short packets and it consumes all available congestion window.
And somehow server Initial and/or Handshake are lost.  Client cannot send ACK for Short packet because it does not have 1RTT key.  Server cannot resend Initial/Handshake packet because congestion window is 0.
I think that I have to make Short packets lost and reclaim in_flight bytes.  But I'm not sure https://tools.ietf.org/html/draft-ietf-quic-recovery-22#appendix-A.9 covers this case.
It looks to me that unless pn_space becomes 1rtt pn space, no processing done for Short 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/2984

---

From: Marten Seemann <[email-masked]>
Date: Thu, 22 Aug 2019 00:56:34 -0700

If I understand correctly, the retransmissions would be sent when the PTO timer fires in this case, and therefore are probe packets. As such, they're not blocked by the congestion controller.

-- 
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/2984#issuecomment-523794159

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 22 Aug 2019 03:32:16 -0700

According to the pseudo code in A-9, PTO does not fire if endpoint has unacknowledged crypto data.

-- 
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/2984#issuecomment-523847282

---

From: ianswett <[email-masked]>
Date: Thu, 22 Aug 2019 18:25:57 -0700

In the editor's draft, PTO replaces the handshake timer, TLP and RTO.  In the current editor's draft, it's armed until the client has 1-RTT keys.  So the client must retransmit something in Initial or Handshake encryption levels to move the handshake along.

Given that, I'm unclear on what the issue is?

-- 
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/2984#issuecomment-524136860

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 23 Aug 2019 05:14:31 -0700

Closed #2984.

-- 
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/2984#event-2579511494

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 23 Aug 2019 05:14:30 -0700

Thank you for replies.  The issue is against draft-22, and I haven't checked editor's copy.
At this point, I realized that this issue is a duplicate of #2779.  .5RTT response just accelerates the issue.  The root cause is that we cannot declare handshake packets lost in the draft-22.  If it is fixed in editor's copy then you can close #2779 as well.

-- 
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/2984#issuecomment-524292708