Subject: [quicwg/base-drafts] nothing can be sent when receiving a packet just after the idle close timer expires (#2347)

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Jan 2019 23:38:52 -0800

IIUC, the primary reason of having STATELESS_RESET is to let the client notice that the connection is dead immediately, so that it can retransmit the request using a new connection. However, when a server receives a request immediately after it's idle close timer has expired, it cannot send any packet in response, because it is in the draining period. Is this the expected behavior?

IMO, we should always allow a server to respond whenever it receives a packet after the idle timeout has expired. One way of allowing that is to let an endpoint immediately discard the connection state when the idle close timer expires.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 20 Jan 2019 20:36:51 -0800

As long as the idle timeout is longer than the draining period would be, I think that this is right.  The text was there to allow for the case where a peer attempted to restart use of the connection near the end of the idle timeout period, but was unsuccessful.  On balance, a stateless reset is better in that case.

-- 
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/2347#issuecomment-455945985

---

From: Christian Huitema <[email-masked]>
Date: Tue, 29 Jan 2019 22:27:26 -0800

Just checking what my code does: at the end of the idle period, the server just gets rid of the connection. No message, no draining period. Maybe this is a bug, but it felt right...

-- 
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/2347#issuecomment-458827763

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2019 06:30:39 +0000 (UTC)

Tokyo conclusion:  Forbidding the server from responding in this window is not great.  We will drop the closing/draining period after an idle timeout and have the endpoint just drop state.

@ianswett suggested that you could send the CONNECTION_CLOSE that you might have otherwise sent, but it is easier to just shortcut the closing period.

-- 
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/2347#issuecomment-458828354

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jan 2019 22:43:51 -0800

Amendment based on discussion: suggest setting the idle timeout to `max(idle_timeout, 3*PTO)` to avoid pathological cases.

-- 
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/2347#issuecomment-458830911