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

[Yoshifumi Nishida <[e-mail]>]

Hi Joe,

Thanks for the comments.

On Sat, Nov 20, 2021 at 1:07 PM [e-mail] <[e-mail]>
wrote:

>
> Notes below…
>
> On Nov 15, 2021, at 11:49 PM, Yoshifumi Nishida <[e-mail]>
> wrote:
>
> 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.
>
>
> We can’t rely on TLS; it’s not required and is defined as an application
> on top of TCP, rather than being integrated into it.
>
> 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.
>
>
> By the time TLS sees it, it’s too late; TCP has already acted on it (e.g.,
> ACKd it, etc.).
>

Right. But, I am thinking that the boundary between TLS and TCP might
be becoming ambiguous.
If this is the direction to be evolved, I think it would be worth thinking
about something like this.
--
Yoshi