Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt

From: [email-masked]
Date: Tue, 24 Mar 2020 06:53:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-16.txt
	Pages           : 106
	Date            : 2020-03-24

Abstract:
   This document specifies the Internet's Transmission Control Protocol
   (TCP).  TCP is an important transport layer protocol in the Internet
   stack, and has continuously evolved over decades of use and growth of
   the Internet.  Over this time, a number of changes have been made to
   TCP as it was specified in RFC 793, though these have only been
   documented in a piecemeal fashion.  This document collects and brings
   those changes together with the protocol specification from RFC 793.
   This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
   6528, and 6691 that updated parts of RFC 793.  It updates RFC 1122,
   and should be considered as a replacement for the portions of that
   document dealing with TCP requirements.  It updates RFC 5961 due to a
   small clarification in reset handling while in the SYN-RECEIVED
   state.

   RFC EDITOR NOTE: If approved for publication as an RFC, this should
   be marked additionally as "STD: 7" and replace RFC 793 in that role.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-16
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 24 Mar 2020 10:09:06 -0400

In this update, I think everything is addressed except for 4 topics:

1) Reserved bits description - I made no changes yet.  Discussion 
spanned a few threads, but didn't look to me like it converged. 
Michael's summary thread covers a number of options and relevant 
questions: 
https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA/

2) R1 and R2 values - Gorry questioned whether (A) applications should 
still be notified with R1 is reached, and (B) whether R1 = 3 RTOs and R2 
 >= 100s are still recommended values.  I don't think any other RFC or 
errata has revised these, so am inclined to leave it alone for now in 
this doc, but maybe bookmark it as a topic for future consideration in 
the working group.

3) Dead gateway detection - I made no changes yet; this may be another 
topic for potential future consideration.  The question is posed here: 
https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/

4) OPEN+LISTEN while same local port is in SYN-SENT/RECEIVED - I made no 
changes yet, but Gorry suggested that the text below may need updating 
with regard to modern systems (I'll be grateful for specific suggested 
changes on this):

A TCP that supports multiple concurrent users MUST provide an
OPEN call that will functionally allow an application to LISTEN
on a port while a connection block with the same local port is
in SYN-SENT or SYN-RECEIVED state (MUST-42).

On 3/24/2020 9:53 AM, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joseph Touch <[email-masked]>
Date: Tue, 24 Mar 2020 10:01:37 -0700

Some thoughts...

> On Mar 24, 2020, at 7:09 AM, Wesley Eddy <[email-masked]> wrote:
> 
> 1) Reserved bits description - I made no changes yet.  Discussion spanned a few threads, but didn't look to me like it converged.  Michael's summary thread covers a number of options and relevant questions: https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA <https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA>IMO, need to be clear that:
- MUST be ignored by endpoints that don’t support their assigned use
- MUST be set to zero by endpoints that don’t support their assigned use
- requires standards-track doc to assign (IMO)

If we want to assign any for experiments, we would do that in a standards-track update to this doc, so this decision doesn’t box us in for all time — but we’re not there yet IMO
> 2) R1 and R2 values - Gorry questioned whether (A) applications should still be notified with R1 is reached, and (B) whether R1 = 3 RTOs and R2 >= 100s are still recommended values.  I don't think any other RFC or errata has revised these, so am inclined to leave it alone for now in this doc, but maybe bookmark it as a topic for future consideration in the working group.
> 
No particular comment...
> 3) Dead gateway detection - I made no changes yet; this may be another topic for potential future consideration.  The question is posed here:https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/ <https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/>I see the original question but nothing further. I don’t see anything needed beyond what’s in RFC1122 here. This is an optimization of a given TCP implementation to help IP, not the responsibility of TCP in any way to support. I.e., at best, this doc could say that “some TCP statistics may be used by other protocols, e.g., by IP for dead gateway detection”. But not require it.
> 4) OPEN+LISTEN while same local port is in SYN-SENT/RECEIVED - I made no changes yet, but Gorry suggested that the text below may need updating with regard to modern systems (I'll be grateful for specific suggested changes on this):
> 
I would change it to talk about connections rather than users, but otherwise retain it largely as-is:

A TCP that supports multiple concurrent connections MUST provide an
OPEN call that will functionally allow an application to LISTEN
on a port while a connection block with the same local port is
in SYN-SENT or SYN-RECEIVED state (MUST-42).

This does beg the question about whether we want to address how a LISTEN on wildcard affects concurrent LISTENs on more specific values or even OPENs. I’d really like to see this addressed explicitly - it’s a property of our API that seems to be underspecified (AFAICT).

IMO:
	More specific socket-pairs SHOULD be allowed in both LISTENs and OPENs in the presence of wildcard LISTENs.

I’d even favor that being a MUST, recognizing that existing systems may not support this.

Joe

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 25 Mar 2020 20:23:15 +0000

Hi Wes,

Regarding 1), I think that has been some (supportive) list discussion on cleaning up the IANA registry.

To provide some data point, here is how I would answer the first two questions in my summary – as usually as individual contributor:

Question 1: Should an IANA registry be created for bits 4, 5, and 6 with status "Reserved", which are missing on https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml?

=> Michael’s opinion: Yes, I think this should be done in 793bis

Question 2: Should the IANA registry move to a sub-registry on the Transmission Control Protocol (TCP) Parameters page (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml).

=> Michael’s opinion: Yes, I think this should be done in 793bis

A little bit more tricky is the third question, which mostly matters for the entry created by RFC 8311…

Question 3: Should past (and current) use of bits be documented in the IANA registry, and, if so, how?

=> Michael’s opinion: We could discuss whether to change the table structure (see https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1) to record past use, e.g., by adding another column and moving the statement “previously used by Historic [RFC3540] as NS (Nonce Sum)” to that new column. The new column could have a title such as “Comments”, “Past Use”, etc. That would be a purely editorial change, as it would just reorganize the table, but not change any entry. I don’t have a particularly strong opinion on that, though. Even if we decided that this was useful, we could also postpone that change to the first standards-track document that actually needs this, e.g., by reallocation bit 7 to a new use. Until this happens, the current table format still works. So my suggestion would be to do nothing unless others from the community strongly support a change by 793bis.

Of course, comments from others would really help, too.

Michael

From: tcpm <[email-masked]> On Behalf Of Wesley Eddy
Sent: Tuesday, March 24, 2020 3:09 PM
To: [email-masked]
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt

1) Reserved bits description - I made no changes yet.  Discussion spanned a few threads, but didn't look to me like it converged.  Michael's summary thread covers a number of options and relevant questions: https://mailarchive.ietf.org/arch/msg/tcpm/UOHo4tXQPpBV90U-pRmdt_LfjRA/

3) Dead gateway detection - I made no changes yet; this may be another topic for potential future consideration.  The question is posed here: https://mailarchive.ietf.org/arch/msg/tcpm/IGhHYUOCwES7I-DjsgHnFsa-zVY/

On 3/24/2020 9:53 AM, [email-masked]<mailto:[email-masked]> wrote:

        Author          : Wesley M. Eddy

 Pages           : 106

 Date            : 2020-03-24

Abstract:

   state.

tcpm mailing list

[email-masked]<mailto:[email-masked]>

---

From: Joseph Touch <[email-masked]>
Date: Wed, 25 Mar 2020 14:30:39 -0700

Hi, all, 

I didn’t see these proposed ways forward before, so I’ll add my preferences to them in particular below.

Joe

> On Mar 25, 2020, at 1:23 PM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi Wes,
>  
> Question 1: Should an IANA registry be created for bits 4, 5, and 6 with status "Reserved", which are missing on https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml? <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml?>
>  

+1

> Question 2: Should the IANA registry move to a sub-registry on the Transmission Control Protocol (TCP) Parameters page (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml <https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml>).
>  

+1
 
> => Michael’s opinion: We could discuss whether to change the table structure (see https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1 <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml#tcp-header-flags-1>) to record past use, e.g., by adding another column and moving the statement “previously used by Historic [RFC3540] as NS (Nonce Sum)” to that new column. The new column could have a title such as “Comments”, “Past Use”, etc. That would be a purely editorial change, as it would just reorganize the table, but not change any entry. I don’t have a particularly strong opinion on that, though. Even if we decided that this was useful, we could also postpone that change to the first standards-track document that actually needs this, e.g., by reallocation bit 7 to a new use. Until this happens, the current table format still works. So my suggestion would be to do nothing unless others from the community strongly support a change by 793bis.

I favor the approach we use for IANA ports here.

Document official assignments officially.

Document unofficial uses vaguely - enough to say “someone uses it” but NOT specifically who or how. The latter ends up effectively endorsing squatting.

IANA does this by saying “known unauthorized use”.

Joe

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 25 Mar 2020 22:03:46 +0000

Hi Joe,

Regarding question 3): For header bits, at least as far as I know, there is no unauthorized use as of today. My comment was about authorized use.

Bit 7 is reserved now but was officially allocated to NS before. So, question 3) is about whether and where to record that *official* use of bit 7.

Right now, https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml records the past use in the table column “Name”. That works as of today, but if bit 7 is reallocated, the question is whether and where to record a past and completed assignment. Even more tricky is the question how to record the use of bits allocated to RFC 3168 by newer RFCs, e.g., as foreseen by AccECN. All of this is about official IETF allocations by future RFCs.

As I have now looked at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml, I see that this registry has a column “Assignment Notes”. This would also be a reasonable name for a new column in the header flag registry. If we decided to go down that road, the IANA table after publication of 793bis could look like more or less as follows …

Bit          Name                                                                   Reference          Assignment Notes
4             Reserved                                                           [793bis]
5             Reserved                                                           [793bis]
6             Reserved                                                           {793bis]
7             Reserved                                                            [RFC8311]           Previously used by Historic [RFC3540] as NS (Nonce Sum)
8             CWR (Congestion Window Reduced)      [RFC3168]
9             ECE (ECN-Echo)                                                [RFC3168]

As I wrote, I think that change could be done by 793bis, as it is purely editorial, but I don’t have a very strong feeling whether this is really MUST HAVE.

Unfortunately, it is possible that there could be future unauthorized use of header bits, e.g., if the IETF decided not to standardize one solution or several solutions that claim header bits. I agree that we could use then a term such as “known unauthorized use”. But right now I think how to deal with that problem would be outside the scope of 793bis.

Michael

From: Joseph Touch <[email-masked]>
Sent: Wednesday, March 25, 2020 10:31 PM
To: Scharf, Michael <[email-masked]>
Cc: Wes Eddy <[email-masked]>; [email-masked]
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt

Hi, all,

Joe

On Mar 25, 2020, at 1:23 PM, Scharf, Michael <[email-masked]<mailto:[email-masked]>> wrote:

Hi Wes,

+1

+1

Joe

---

From: Joseph Touch <[email-masked]>
Date: Wed, 25 Mar 2020 16:39:55 -0700

Hi, Michael,

Sure - this is all fine. It’s tricky but informal anyway.

Joe

> On Mar 25, 2020, at 3:03 PM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi Joe,
>  
> Right now, https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml <https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml>records the past use in the table column “Name”. That works as of today, but if bit 7 is reallocated, the question is whether and where to record a past and completed assignment. Even more tricky is the question how to record the use of bits allocated to RFC 3168 by newer RFCs, e.g., as foreseen by AccECN. All of this is about official IETF allocations by future RFCs.
>  
> As I have now looked at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml>, I see that this registry has a column “Assignment Notes”. This would also be a reasonable name for a new column in the header flag registry. If we decided to go down that road, the IANA table after publication of 793bis could look like more or less as follows …
>  
> From: Joseph Touch <[email-masked] <mailto:[email-masked]>> 
> To: Scharf, Michael <[email-masked] <mailto:[email-masked]>>
> Cc: Wes Eddy <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Mar 25, 2020, at 1:23 PM, Scharf, Michael <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Wes,
>