Re: Closing on CONNECTION_CLOSE

[Eric Rescorla <[e-mail]>]

On Thu, Jul 27, 2017 at 7:08 AM, Subodh Iyengar <[e-mail]> wrote:

> > 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?
>

There seem to be three options, which we can leave to the implementation:

- Re-send CONNECTION_CLOSE
- Send Stateless Reset
- Drop the packet.


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.
>

Yes, that would probably also work. As above, do we need to decide?

-Ekr


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