Re: Closing on CONNECTION_CLOSE

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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

That would be another argument for making the connection independent of
5-tuple. It would also simplify error handling during early handshake and
decouple protocol for from lower layer.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 28 July 2017 at 20.49.25, Christian Huitema ([e-mail]) wrote:



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