Subject: [quicwg/base-drafts] TIMEOUT CONNECTION_CLOSE error (#3126)

From: Rui Paulo <[email-masked]>
Date: Mon, 21 Oct 2019 12:51:28 -0700

Perhaps we should have a TIMEOUT error code?  Connection timeouts are extremely common.  It would help implementations detect timeout conditions without having to parse the connection_close error string.  One could argue that a timeout isn't an error, but we already have SERVER_BUSY.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 21 Oct 2019 12:53:13 -0700

If so, it should probably distinguish between idle timeout and handshake timeout.

-- 
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/3126#issuecomment-544679538

---

From: ianswett <[email-masked]>
Date: Mon, 21 Oct 2019 20:07:55 +0000 (UTC)

I think the transport doc currently suggests using NO_ERROR.  There are no other suggested uses of NO_ERROR, so this seems like it is functionally equivalent to a TIMEOUT error code?

> After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An endpoint MUST NOT send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended.

-- 
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/3126#issuecomment-544685436

---

From: Rui Paulo <[email-masked]>
Date: Mon, 21 Oct 2019 13:44:56 -0700

@ianswett When I read that, it doesn't really sound like it's describing a timeout condition, just that one side is about to enter the draining state and it may send a CONNECTION_CLOSE packet to increase the chances the other side also moves to the draining state.

NO_ERROR doesn't seem that useful to me.

-- 
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/3126#issuecomment-544699977

---

From: Marten Seemann <[email-masked]>
Date: Mon, 21 Oct 2019 13:46:17 -0700

If my understanding of the spec is correct, you're not supposed to send a CONNECTION_CLOSE when you detect a timeout, since you don't expect it to be received anyway.

-- 
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/3126#issuecomment-544700468

---

From: Rui Paulo <[email-masked]>
Date: Mon, 21 Oct 2019 16:59:48 -0700

I was thinking about the case where the idle timeout is long and a peer would be stuck retransmitting data until it hits the idle timeout.  Right now, it can send NO_ERROR, but it just seems like having a specific error code for timeouts would help.  I agree that there's no need to send anything after we reach the idle timeout.

-- 
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/3126#issuecomment-544756501

---

From: ianswett <[email-masked]>
Date: Mon, 21 Oct 2019 18:31:18 -0700

I prefer more error codes over fewer, especially for cases like this that may be quite common.

Even if we use NO_ERROR, I think we should specify what the error code to send is in the case you're mentioning.

-- 
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/3126#issuecomment-544773352

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2019 19:11:14 -0700

Why would this condition need to be signaled?

-- 
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/3126#issuecomment-544779646

---

From: Rui Paulo <[email-masked]>
Date: Tue, 22 Oct 2019 10:52:38 -0700

@martinthomson I think it could help identify problems when the link is asymmetrically broken and you don't have access to the state of the server.

-- 
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/3126#issuecomment-545079040