Subject: [tcpm] Meeting Notes

From: [email-masked]
Date: Fri, 12 Nov 2021 11:34:56 +0100

Dear all,

a first version of the meeting notes has been uploaded:
https://datatracker.ietf.org/meeting/112/materials/minutes-112-tcpm-01
If you have comments, please let the chairs know.

Thanks a lot to Gorry for taking the notes and anyone improving the
notes during the meeting!

Best regards
Michael

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 12 Nov 2021 08:58:29 -0800

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

(I would be glad to assist with documenting that approach if useful).

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Nov 12, 2021, at 2:34 AM, [email-masked] wrote:
> 
> Dear all,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: [email-masked]
Date: Fri, 12 Nov 2021 19:37:16 +0100

> On 12. Nov 2021, at 17:58, [email-masked] wrote:
> 
> Hi, all,
> 
Just on this question:

If time permits, we accept presentations without IDs if we think that having a discussion
in TCPM makes sense. In this particular case, the presentation was the last one and we used
only the remaining meeting time.

In my experience a presentation in the meeting is triggering a discussion much easier than
just a post to the mailing list.

This is my view as one of the co-chairs, the other two can chime in here.

Best regards
Michael
> 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
>

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 13 Nov 2021 09:24:20 -0800

On the issue below:

> On Nov 12, 2021, at 10:37 AM, [email-masked] wrote:
> 

Without IDs sure, but without a single mention on the list?

> just a post to the mailing list.

It trades a limited resource (meeting time) for the presenter’s effort; that seems the wrong optimization to me.

FWIW, it didn’t take all that long for me to summarize the issue, the proposed approach, *and* a solution not presented to the list.

Joe

---

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 14 Nov 2021 11:07:29 +0000

Hi Joe,

At least since I chair TCPM (i.e., since 2011), there has been no formal requirement of list discussion prior to a presentation at the very end of the TCPM meeting. This in particular applies to any TCP topic related to running code.

My impression is that in many cases such talks at the end of the TCPM slot have triggered interesting follow-up discussions.

In over 10 years I only recall some very few cases in which such presenations clearly were a waste of time (yes, the chairs indeed have made mistakes!).

So, all in all, I believe that the relatively liberal policy of accepting presentations has served us well. In a nutshell, my own philosophy has always been: Be liberal in accepting presentation requests, and be conservative in sending WG adoption calls…

Of course, such policies can be changed in future. There will be opportunities, soon-ish…

Michael

From: tcpm <[email-masked]> On Behalf Of [email-masked]
Sent: Saturday, November 13, 2021 6:24 PM
To: Michael Tuexen <[email-masked]>
Cc: Extensions <[email-masked]>
Subject: Re: [tcpm] Meeting Notes // TCP silent close issue

On the issue below:

On Nov 12, 2021, at 10:37 AM, [email-masked] <mailto:[email-masked]>  wrote:

Just on this question:

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 15 Nov 2021 23:49:22 -0800

Hi Joe, everyone,

On Fri, Nov 12, 2021 at 8:58 AM [email-masked] <[email-masked]>
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?)
>
> 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:

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

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 20 Nov 2021 13:07:19 -0800

Notes below…

> On Nov 15, 2021, at 11:49 PM, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi Joe, everyone,
> 
> On Fri, Nov 12, 2021 at 8:58 AM [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, all,
> 
> 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 <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.).

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 29 Nov 2021 02:21:56 -0800

Hi Joe,

Thanks for the comments.

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

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

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