Re: QUIC Connection Close Reliability

[Martin Thomson <[e-mail]>]

Hi Nick,

It seems that you are having a problem with getting agreement between
peers about what the close state is.  In your example, if A cares that
the stream was completely received by B, then this is not an
appropriate way to negotiate a close in that application protocol.

You might interpret the receipt of APPLICATION_CLOSE as implicit
acknowledgment of all streams to avoid this particular problem, or to
create additional signals.

HTTP over QUIC does this largely by driving this from the client end,
which simplifies things considerably.

On Tue, Apr 24, 2018 at 12:06 AM, Nick Banks
<nibanks=[e-mail]> wrote:
> Hey Folks,
>
>
>
> I have been trying to work through an issue with reliability, related to
> connection close and I am trying to understand if this is a protocol issue
> for if I need to change my implementation.
>
>
>
> Suppose you have an application protocol on top of QUIC where each side of
> the connection may use one or more streams and then immediately, but
> gracefully, close the connection when they are done with all the streams. In
> that kind of application protocol, one side of the connection generally ends
> up closing immediately in response to receiving a FIN on a stream. Then you
> get into a state where the peer won’t necessarily get that FIN acknowledged.
> Even if the endpoint sends an acknowledgment for the FIN (either as a
> separate packet or with the close) it’s possible that ACK is lost. Ideally
> (I think), the ACK is sent in the same packet as the close, so you can
> control the atomic state change on the peer. If the ACK was separate, and
> lost, but the close wasn’t lost, then the peer would treat the stream as
> abortively closed.
>
>
>
> A -------- STREAM (w/FIN) ------> B
>
> A <------- ACK, APP_CLOSE ------- B
>
>
>
> But now the issue comes if the ACK/APP_CLOSE packet is lost. Per spec, the
> endpoint (B) that received the FIN and then closed the connection enters the
> closing period. While in this state, the spec states that the endpoint
> SHOULD respond to any packet it receives [without a corresponding close
> frame] with another packet containing a closing frame. If the endpoint does
> this, and includes the ACK again as well, I believe everything would work.
> The peer (A) would retransmit the STREAM packet, which would elicit a new
> ACK/APP_CLOSE packet from (B). My fear though (from current interop
> experience) is that everyone will try to short circuit connection closure
> and just immediately go away. If this behavior isn’t completely standard
> across all implementations, then the application protocol would end up
> having different results on different implementations. Some implementations,
> might not send the ACK at all with the initial close, causing the peer (A)
> to most of the time interpret the stream as aborted. Other times, the
> endpoint (A) might not continue to send the ACK frame with the close, or
> just not send anything any more at all, resulting in a timeout on the peer
> side, also resulting in an abortive closure of the stream. This would
> probably cause the application protocol to end up creating it’s own close
> semantics, on top of QUIC.
>
>
>
> Now, folks might not think this is a very important scenario, but I feel we
> should aim for consistency here. Perhaps I have missed a different solution
> to the problem. I considered a design that always sends that last ACK with a
> PING frame, and waits for that to get acknowledged before closing, but I
> felt it was way too ugly.
>
>
>
> Thanks,
>
> - Nick