Closing on CONNECTION_CLOSE

[Eric Rescorla <[e-mail]>]

There have been a number of issues raised about the exact semantics of
CONNECTION_CLOSE [0], but we have never really closed on them. As Ryan
says, one might have think that CONNECTION_CLOSE is like TCP FIN or
like TCP RST.


In the FIN-like model:
- The closing side sends a CONNECTION_CLOSE
- The non-closing side ACKs it
- The closing side keeps retransmitting until it gets an ACK or it
  times out.


In the RST-like model:
- The closing side sends a CONNECTION_CLOSE
- The non-closing side just terminates the connection
- The closing side responds to new packets from the non-closing side
  with a retransmitted CONNECTION_CLOSE (perhaps just a stored packet)
  for some time.

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?

-Ekr


[0] https://github.com/quicwg/base-drafts/issues/330
https://github.com/quicwg/base-drafts/issues/328

[1] See also the spec for ID1 which says:
"The packet containing a connection close does not need to be
retransmitted."