Re: Closing on CONNECTION_CLOSE

[Subodh Iyengar <[e-mail]>]

> The only downside I'm really aware of is that the closing side
has to keep state for something like 2MSL (so that it can properly
respond to late packets), rather than being able to clean up on
receiving an ACK

I favor the RST model as well.
You'll end up having to keep a loss timeout even in the FIN model because
of ACKs being lost / the remote side shutting for unrelated reasons / silently closing
their connection.

However what is the right response to late packets? The only response I can think of
is to resend the connection close if you still have the connection state. Is there anything
else that could be sent that I'm missing?

As an aside on the topic of TIME_WAIT itself:

The reason I'm aware that TIME_WAIT exists in TCP is to protect us from the local port
being re-bound to another connection and the data from the old connection interfering with
the new connection. With QUIC this seems less of an issue though because a
combination of (connection id + packet type + packet encryption) can be used to determine whether or
not the packet was valid to be received in the context of a new connection. Going with the
philosophy of dropping packets on the floor that are malformed that martin proposed during
the last WG meeting, do we even need a TIME_WAIT state in QUIC?

The advantage of TIME_WAIT that I see is this ability to send the CONNECTION_CLOSE in a timely
manner to prevent the client from needing to retry till the RTO limit and realize the connection
needs to be closed. However if we go with the close model of graceful close always driven by the app, then
this won't be a common case and we might deliver a PUBLIC RESET instead of a CLOSE.

Subodh


________________________________
From: QUIC <[e-mail]> on behalf of Christian Huitema <[e-mail]>
Sent: Thursday, July 27, 2017 7:02:33 AM
To: [e-mail]
Subject: Re: Closing on CONNECTION_CLOSE



On 7/27/2017 6:47 AM, Eric Rescorla wrote:
> The specification seems kind of vague on this point (there is a big
> TODO for TIME_WAIT) and in places suggests retransmission [1] I had
> previously assumed the FIN-like model but after talking to Ian this
> morning I think the RST-like model is better. It's easier to implement
> because you don't need to manage a post-close state machine on either
> side. The only downside I'm really aware of is that the closing side
> has to keep state for something like 2MSL (so that it can properly
> respond to late packets), rather than being able to clean up on
> receiving an ACK. However, this isn't that big a deal, because as
> noted above, you can throw away the connection and just send a stored
> packet, or alternately, just send public reset (or just go silent).
>
> Given that ID1 does include CONNECTION_CLOSE, albeit with limited
> semantics, it would be good to resolve this soon. Are there people who
> want to argue in favor of the FIN-like model?

Yes the text is vague. My ID1 code implements the RST behavior --
immediate close on receipt, no ACK. It seemed natural.

I have yet to implement a proper zombie state, but that would be needed
whether we want the RST or FIN semantic, since FIN packets can be lost.

RST behavior is cleaner there: repeat the RST frame if packets are still
received after some timeout.

--
Christian Huitema