Re: Closing on CONNECTION_CLOSE

[Christian Huitema <[e-mail]>]

On 7/28/2017 10:15 AM, Patrick McManus wrote:
> I disagree a little bit with (I think) Subodh and Wily regarding what
> to send when you recv data after you have sent a CLOSE. I want to
> strongly encourage implementations to have a TIME_WAIT like period of
> being able to a fully protected CLOSE (it can be a memcpy retransmit).
> public reset ought to be left as a last resort.

As Subodh pointed out, "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." We don't have
that constraint of old packets resurfacing 30 seconds later and
interfering with a new data flow. Encryption protects against that. The
"waiting" or "draining" period would mostly be a courtesy to the peer,
to ensure that the CLOSE frame is well received, and that the peer
actually stops sending.

The normal duration of the draining period would be "sufficiently more
than 1 RTT". With the current spec, the closer knows that the CLOSE has
not been received yet if it keeps receiving packets from the peer. This
should normally last for 1 RTT after sending the CLOSE frame. If it
receives any packets more than 1 RTT after sending the CLOSE, it can
assume that the CLOSE frame was not received. It would make sense to
resend it then.

Of course, there is a question of how long to wait after 1 RTT. Probably
"some time depending on the application".

We could be tempted to specify acknowledgements, etc. But then we have
to remember the two generals...

-- 
Christian Huitema