Subject: [quicwg/base-drafts] Acknowledging *_CLOSE (#733)

From: Mike Bishop <[email-masked]>
Date: Tue, 15 Aug 2017 20:24:55 +0000 (UTC)

The current text suggests that the sender of CONNECTION_CLOSE keep sending the final packet in response to subsequent incoming packets with a backoff, until you wait long enough that you figure the other side probably figured it out and stopped sending.

@nibanks points out that if you have a QUIC object that represents the connection, this means that the object and its data can't actually go away until the timeout is done.  Is there value in having a short-circuit by which the sender of *_CLOSE can be sure it was received and go away early?

The obvious solution is to suggest responding to a *_CLOSE with a matching *_CLOSE, but that just moves the timeout to the other side.  Given that servers are likely to have a persistent connection management layer, that might be acceptable, but isn't so perfect for peer-to-peer applications.

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

---

From: Marten Seemann <[email-masked]>
Date: Tue, 15 Aug 2017 18:08:23 -0700

Why can't this data go away? All you need to do is export the byte representation of the CONNECTION_CLOSE and the receiver address from the QUIC object, and then the object can be freed. 

-- 
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/733#issuecomment-322632396

---

From: Nick Banks <[email-masked]>
Date: Wed, 16 Aug 2017 02:14:48 +0000 (UTC)

Something must be bound to the socket and listening for incoming packets as well, correct? If you must have code listening, why not have support for explicitly indicating that you can stop listening, instead of an arbitrary time out?

-- 
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/733#issuecomment-322644832

---

From: MikkelFJ <[email-masked]>
Date: Wed, 16 Aug 2017 08:05:57 +0000 (UTC)

This is a two-phase commit problem. I am also concerned with state lingering until timeout. Explicit confirmation is complex though. Like:

1. (A) generates close token (CT) and sends PREPARE_CLOSE(CT) periodically.
2. (B) receives (CT) and responds with CORFIRM_CLOSE(CT) periodically.
3. (A) receives CONFIRM_CLOSE(CT) and stops sending PREPARE_CLOSE(CT) sends CLOSE(CT) a few times then destroys context including CT. If CONFIRM close is not received within timeout, the context is destroyed.
4. (B) receives CLOSE(CT) or times out and destroys context.

There ought to be general application timeout as well so a lost PREPARE_CLOSE will also close the connection, but this timeout would be long.

I'm not really sure a CT token is needed but it might make it possible to drop most app context early.

The timeout can be short like 4RTT or so, because there is an expected response. There is no ACK involved in this and the timeouts are different because ACK can be delayed by an endpoint but CONFIRM_CLOSE and CLOSE must be ASAP.

In a proper two-phase commit context the state should be serialized to disk in order to handle crashes, but we do this with timeout instead.

-- 
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/733#issuecomment-322697055

---

From: Christian Huitema <[email-masked]>
Date: Thu, 24 Aug 2017 01:23:08 +0000 (UTC)

@mikkelfj - this is not a two phase commit problem, it is the good old two generals problem. You can devise how many exchanges you want, there is always a risk that some ack of ack of ack will be lost and one of the parties will give up and the state will be indeterminate. So you need time to get to the decision. In your proposal, the reliability derives from the statement that messages are send "periodically" or "a few time". You get about the same reliability if (A) sends a connection close and repeats it periodically as long as it receives data from (B), or until some time has elapsed. Or, we may ask (B) to ACK the packets that carried the connection close, in which case (A) can stop repeating when it receives the ACK. 

The two phase commit algorithm is mostly useful when synchronizing a graph of updates. But that's not what we see here.

-- 
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/733#issuecomment-324506005

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Aug 2017 15:50:12 +0000 (UTC)

Well - proper two-phase commit requires persistence and may take forever to complete - so what I describe is not proper two-phase commit, but related. Regardless, I think it would be good with a description of what a clean shutdown is, and if the draining period and can be made short in normal conditions.

-- 
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/733#issuecomment-324676702