Re: [tcpm] Meeting Notes // TCP silent close issue

[Yoshifumi Nishida <[e-mail]>]

Hi Joe, everyone,

On Fri, Nov 12, 2021 at 8:58 AM [e-mail] <[e-mail]>
wrote:

> Hi, all,
>
> I noticed the discussion on TCP “silent close”, but didn’t recall seeing
> any discussion on this topic on the list, so I figured I’d start one.
>
> (Incidentally, a question to the chair: aren’t topics with meeting times
> slots supposed to have at least been discussed on the list or drafted?)
>
> The issue, AFAICT, is that:
> - an app with a huge number of TCP connections crashes
> - so the OS sends out that huge number of FINs
> - which a burden on the OS and network
> - if the entire OS crashes, no FINs get sent out
> - so why not let that happen when the apps crash?
>
> This is addressed in TIME_WAIT discussions already, e.g.:
>
> T. Faber, J. Touch and W. Yue, "The TIME-WAIT state in TCP and its effect
> on busy servers," IEEE INFOCOM '99. Conference on Computer Communications.
> Proceedings. Eighteenth Annual Joint Conference of the IEEE Computer and
> Communications Societies. The Future is Now (Cat. No.99CH36320), 1999, pp.
> 1573-1583 vol.3, doi: https://doi.org/10.1109/INFCOM.1999.752180
>
>
> The reason is RFCs 793 and 1122 both require hosts to avoid new
> connections for the TIME_WAIT period during a reboot, ensuring the safety
> of the orphan TCP connections on the remote systems.
>
> So, in this case, it would be OK for the OS to avoid sending out the burst
> of FINs, but *ONLY* if it also ensured those connection identifiers (at
> least) remained in TIME_WAIT. I.e., it would be possible for the OS to
> simply put them in TIME_WAIT and then allow the TCBs to be garbage
> collected either during a scan of TCBs or when a new connection on the same
> socket pair occurs. That can happen one of two ways:
> - put the TCBs in TIME_WAIT directly (or perform equivalent bookkeeping)
> - have the OS pause new connections for the TIME_WAIT period, i.e.,
> emulating the reboot pause
>

While I basically agree with what you're proposing here, I would like to
think about something extra.
In a nutshell, I am thinking that TIME_WAIT is a bit outdated mechanism
given that most TCP connections today use TLS.
As I wrote in my old I_D (
https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-disabling-paws-00#section-3.3
),
if a connection uses TLS, I think we can distinguish the packets from old
connections.

A tricky thing for this is that TCP layer cannot know if the connection
uses TLS or not.
However, in the example Neal presented, people already developed a special
API for it.
So, I am wondering if we develop another API that can notify TCP layer the
upper layer is using TLS,
we can establish a connection right away (unless there's no conflict in 4
tuples) without worrying about duplicates from old connections.
Also, we might want to update the TLS stack so that it won't close
connections even if there're a few decryption errors.
In this way, I think we can avoid 2MSL waiting time.
--
Yoshi