Re: Closing on CONNECTION_CLOSE

[Christian Huitema <[e-mail]>]

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