Subject: [quicwg/base-drafts] Clarify meaning of CONNECTION_CLOSE (#330)

From: Ryan Hamilton <[email-masked]>
Date: Tue, 21 Feb 2017 11:53:53 -0800

>From discussion on the list, we could clarify the meaning of CONNECTION_CLOSE. Specifically, it would be good to clarify if it acts more like a TCP FIN or a TCP RST. I would suggest that the analog of a TCP FIN is a FIN on a QUIC stream as they both gracefully half-close a single bidirectional communication channel. After a FIN, retransmission of data may still occur to deal with packet loss.

A QUIC CONNECTION_CLOSE, on the other hand, is an immediate termination of the connection. No more data is retransmitted. As such it is more like a TCP RST.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 16:17:49 -0800

Discussion is ongoing, but I think that we have:

* data that has been received on streams that have terminated MUST NOT be discarded

* received data on streams that are open MUST NOT be discarded or maybe it SHOULD be discarded, I can't tell yet

* data that was sent but not acknowledged is now in an uncertain state, assume the worst (it might have been received by the other side, but it might have been lost too)

If we take @igorlord's position, then we have two different meanings depending on stream state: a closed stream MUST be treated like a FIN (deliver the bits), an open stream is implicitly reset.

-- 
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/330#issuecomment-281848850

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 22 Feb 2017 18:55:04 -0800

I think we do have an agreement that data on a properly terminated stream (terminated with FIN that has received all data) MUST deliver the bits to the application after CONNECTION_CLOSE.

The question is what to do with other streams (open streams) after CONNECTION_CLOSE.
Proposals:

- MUST deliver all data that has been received (until the first gap), or
- SHOULD deliver all data that has been received (until the first gap), or
- SHOULD NOT deliver any data

It also seems like there is an agreement that whatever is decided here should also apply to RST_STREAM and a Public Reset. 

At this point I think that an application should be able to pick its semantics (via some QUIC library mechanism). So I do not like the MUST alternative.

-- 
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/330#issuecomment-281877755

---

From: martinduke <[email-masked]>
Date: Thu, 23 Feb 2017 21:01:55 -0800

So if there are no error conditions, what is the trigger to clear connection state? When all streams are closed?

-- 
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/330#issuecomment-282204893

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Feb 2017 14:29:40 -0800

I think so, yes.  And in a non-error case, that's controlled by your interface with the application.  The application layer will be consuming data out of the streams.  Even if you've closed your socket, so as long as the application has a handle open to the QUIC session and is using stream handles to read data, you'll have some persistent state.

You can clear out state when the socket is closed *and* all data has been read/discarded.

-- 
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/330#issuecomment-282423210

---

From: martinduke <[email-masked]>
Date: Fri, 24 Feb 2017 15:21:21 -0800

OK, so if I acknowledge the last of the peer data FINs after all of my FINs have been acknowledged, I should enter a TIME_WAIT-like state and then later delete the connection. It would appear that CONNECTION_CLOSE is entirely extraneous in this case.

Which I guess brings me back to the question I asked in #335. What value is CONNECTION_CLOSE providing above sending a Public Reset instead? It certainly provides some negative value in obscuring the end of the connection from stateful middleboxes.

-- 
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/330#issuecomment-282432379

---

From: Mike Bishop <[email-masked]>
Date: Fri, 24 Feb 2017 15:57:01 -0800

Actually, the text does allow connections to close silently based on timeout.  One might argue that CONNECTION_CLOSE is valuable in enabling one side or the other to short-circuit the idle timeout.  But I think its main value is that you're certain it came from the peer, because it's encrypted.

-- 
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/330#issuecomment-282437567

---

From: martinduke <[email-masked]>
Date: Fri, 24 Feb 2017 16:45:10 -0800

It's nice to have the authentication, but the implication is that this somehow protects us from attack. But an attacker is always welcome to use Public Reset, so the protocol is only as strong as the authentication in Public Reset regardless of how much we protect the CONNECTION_CLOSE.

-- 
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/330#issuecomment-282443812

---

From: ianswett <[email-masked]>
Date: Sat, 25 Feb 2017 15:10:16 -0800

Agreed @martinduke , which is why a trustable public reset is really critical, and as @RyanAtGoogle pointed out to me earlier this week, we may not need a connection close frame if we're willing to put an error code in the public reset.  This would also reduce the amount of state a server should keep after closing a connection in order to re-create the connection close packet from a full packet to a connection_id -> error code map.

-- 
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/330#issuecomment-282519376

---

From: mirjak <[email-masked]>
Date: Tue, 28 Feb 2017 03:04:24 -0800

+1

-- 
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/330#issuecomment-283010360