Subject: Re: [quicwg/base-drafts] Connections SHOULD Respond to Connection Close Frames (#1029)

From: martinduke <[email-masked]>
Date: Mon, 08 Jan 2018 03:44:57 +0000 (UTC)

This seems like the case where CONNECTION_CLOSEs pass each other in flight, so there shouldn't be much of an issue. It certainly seems much easier to debug, and can let closers tear down faster.

I am somewhat suspicious that in the real world busy servers will just teardown in DRAIN immediately. If an OOO packet generates a stateless reset, that's probably cheaper than holding on to some state for a while.

-- 
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/1029#issuecomment-355879574

---

From: Nick Banks <[email-masked]>
Date: Mon, 08 Jan 2018 14:29:42 +0000 (UTC)

I am not referring to the case where CONNECTIO_CLOSEs pass each other in flight. I am specifically thinking about the scenario where one side starts the connection close process. I think it is worthwhile for the other side to generally acknowledge the CONNECTION_CLOSE frame with one of its own. I agree there might be cases, such as a server under heavy load, where that might not happen, but I believe it should most of the time.

-- 
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/1029#issuecomment-355981264

---

From: ianswett <[email-masked]>
Date: Mon, 08 Jan 2018 15:50:23 +0000 (UTC)

At the point the CONNECTION_CLOSE has been sent, the connection is essentially over.  Having the peer respond with a CONNECTION_CLOSE/no error would allow the sender of the packet containing the CONNECTION_CLOSE to no longer store it in memory, but I believe it has no other effect, so this seems like a case of trading off an extra packet to send/receive with a small amount of buffered memory.

But in order to process an encrypted packet, you have to store more connection state than just a connection ID and the final connection close packet, so if peers didn't send back connection closes and you expected them, there would be a slight increase in memory usage.

So I'd prefer to stick with MAY, since as a server, I expect I'll continue to not process incoming packets from closed connections, so they'd just be wasted 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/1029#issuecomment-356004803

---

From: Nick Banks <[email-masked]>
Date: Mon, 08 Jan 2018 16:29:18 +0000 (UTC)

What about when the client is closing the connection? It shouldn't be nearly as big a deal for clients to keep additional state around waiting for the server's response?

-- 
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/1029#issuecomment-356017201

---

From: ianswett <[email-masked]>
Date: Mon, 08 Jan 2018 08:40:42 -0800

Agreed.  In practice, I expect a lot of HTTP/QUIC clients to destroy all state after sending a connection close, so they wouldn't store anything.  But it likely depends upon the application.  

-- 
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/1029#issuecomment-356020679

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jan 2018 04:51:54 +0000 (UTC)

@ianswett: Are you saying that you expect that many (most? all?) client and server implementations will not adhere to the spec regarding the drain periods? I see the point, since at the moment when a connection is over, there's no point in being a nice and spec-compliant peer any more.
If we think this is actually the case, I'm beginning to wonder what the whole point of specifying the drain period 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/1029#issuecomment-356179594

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jan 2018 06:49:55 +0000 (UTC)

Clients that drop sockets won't necessarily respect this, but servers will have to.

-- 
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/1029#issuecomment-356195663

---

From: ianswett <[email-masked]>
Date: Tue, 09 Jan 2018 06:45:26 -0800

I agree with Martin, I think client behavior will vary and many will immediately close the socket.  I expect servers to adhere.

-- 
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/1029#issuecomment-356303747

---

From: Nick Banks <[email-masked]>
Date: Tue, 09 Jan 2018 06:47:23 -0800

I guess the main point I had here was, if an endpoint (client or server) is going to stick around for the draining period, shouldn't it respond to the initially received CONNECTION_CLOSE frame with its own?

-- 
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/1029#issuecomment-356304309

---

From: ianswett <[email-masked]>
Date: Tue, 09 Jan 2018 14:48:47 +0000 (UTC)

I would say 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/1029#issuecomment-356304750

---

From: Nick Banks <[email-masked]>
Date: Tue, 09 Jan 2018 06:55:52 -0800

If not, then implementations that wish to respect the spec will always have to wait the full draining period. What is the harm in recommending the CONNECTION_CLOSE should be sent? It is a very useful signal to the endpoint that initially closed the connection.

-- 
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/1029#issuecomment-356306987

---

From: ianswett <[email-masked]>
Date: Tue, 09 Jan 2018 11:57:22 -0800

I think we've come back around to our comments from a day ago.  I suspect most implementations will ignore it, and you think it's very useful.  I suggest we stick with MAY for now and we can discuss this again in 6 months when hopefully more people have implementation experience.

If specific applications want to specify MUST, that's fine by me, but I don't think it makes sense for HTTP.

-- 
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/1029#issuecomment-356396248