Subject: [tcpm] review of rev 14 of RFC 793 bis part 1 of 2 - Editorial Comments

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Aug 2019 16:20:58 +0100

I promised to provide review comments for rev 14 of RFC 793 bis. This 
review comes in two parts, the first (this) contains what I think are 
mostly editorial issues and questions about document style for a 
document to be published in 2020.

best wishes,

Gorry

---

Document Style

Parts of this document still has a quant old-fashioned style, somnetimes 
degenerating into weirdness. I think more needs to be done to bring this 
document into the current century. See comments below:

---
I was amused at the frequent reference to "crash" or "crashing". I'm not 
sure that presents the correct view of the IETf about the stability of 
the TCP stack and certainly is not what IO would expect in an RFC that 
could be promoted to full standard. I think this needs to be changed.
e.g.
"TCP MUST be prepared to handle an illegal option length
      (e.g., zero) without crashing;"
could I suggest be:
"TCP MUST be prepared to handle an illegal option length
      (e.g., zero);"
and this
"even if a TCP crashes and loses all knowledge of the
    sequence numbers it has been using. "
could be:
"even if a TCP implementation loses knowledge of the
    sequence numbers it has been using."
etc
---
OLD:
     on some machines
- if still relevant, I suggest:
NEW:
     in some implementation architectures
---
OLD:
     foreign socket
NEW:
     remote socket
- e.g.
          (a) general information about a connection (e.g., interrupts,
          remote close, binding of unspecified foreign socket).
- what is a foreign socket in modern language - is that a remote peer?
- there are other examples, but also later:
OLD:
          If no foreign socket was specified in the OPEN, but the
          connection is established (e.g., because a LISTENing connection
          has become specific due to a foreign segment arriving for the
          local socket), then the designated buffer is sent to the
          implied foreign socket.  Users who make use of OPEN with an
          unspecified foreign socket can make use of SEND without ever
          explicitly knowing the foreign socket address.
- what is a foreign segment?
- and I'm not entirely sure what is mean by a foreign socket address.
---

The security-related text "IP security level and compartment of the 
connection"

Appendix - OLD:
    there has been discussion about
    ammending the TCP specification to prevent connections from being
    aborted due to non-matching IP security compartment and DiffServ
    codepoint values.
- Is this statement correct? I'm not aware of the Diffserv discussion 
being current, and thought (although could be corrected if someone 
provides refs) that the current proactive was not to verify the DSCP?

- This adds unnecessary and unusual terminology to reading the document.
In 3.2.1 it's a spurious example and this and it's cross reference could 
be omitted to increase clarity.
I'd also suggest removal from the core of the document the related text 
in section 3.4, etc. This could all be consolidated in appendix A1 - if 
this is required for other Specs.

The para in section 3.6 starting:
    The IP security option (IPSO) and compartment defined in [1] was
    refined in RFC 1038 that was later obsoleted by RFC 1108.
- This also appears in pseudo code on page 70 (weird)
- I suggest all text (if retained) belongs to this appendix.

+++++++++++++++++++++++++++++++++++++++++++++

Editorial comments on the remaining text:
---
OLD:
  A number of enhancements has
NEW:
  The number of enhancements has
---
OLD:
    TCP reliability consists of detecting packet losses (via sequence
    numbers) and errors (via per-segment checksums), as well as
    correction of losses and errors via retransmission.

- I think this makes it appears that errors are somehow different to loss,
and they are not. I suggest we just say "loss".
----
OLD:
    Data flow is supported bidirectionally over TCP connections, though
    applications are free to flow data only unidirectionally,
- "flow data only" reads weird, can we say send payload data or something?
---
OLD:
       If the ACK control bit is set this field contains the value of the
      next sequence number the sender of the segment is expecting to
      receive.  Once a connection is established this is always sent.
- Punctuation?
NEW:
      If the ACK control bit is set, this field contains the value of the
      next sequence number that the sender of the segment is expecting to
      receive.  Once a connection is established, this is always sent.
---
multiple OLD: " which"
- in all cases I found this is not the correct word, should it be
" that", or ", which".
---
multiple OLD: "remote TCP"
- I found that a little odd, and does not expand the acconym, could
we replace by "remote TCP endpoint" or "remote TCP peer".
---
multiple OLD: "TCPs" and "a TCP"
- This use of a "TCP" as an entity read as very ugly to me. I had to 
read the sentences several times to parse them, could we explain that we 
mean, i.e. "TCP endpoints" or "TCP implementations" etc. (usually this 
seems to mean implementation).
---
OLD:
    When simultaneous attempt occurs,
- I think the current term is simultaneous open.
NEW:
    When simultaneous open occurs,
---
OLD:
   An "XXX" indicates a segment which is lost or rejected.
- rejected seems odd here.
NEW:
   An "XXX" indicates a segment that is lost (not processed by the 
receiving TCP endpoint).
---
OLD:
    has been devised.
- weird word?
NEW:
    is specified.
---
OLD:
    SYN (pun intended)
- I didn't see the pun, can this be explained or omitted?
---
OLD:
    procedure is mildy involved
- weird, or explain
NEW:
    procedure is triggered.
---
Section 3.5
OLD:
     until he is
NEW:
     until the TCP receiver is
---
Section 3.5
OLD:
     the other side
NEW:
     the remote TCP peer
---
OLD:
Avoiding sending segments larger than the smallest MTU within an
       IP network path, because this results in either packet loss or
       fragmentation.
NEW:
       Avoiding sending a TCP segment that would result in an
       I{P datagram larger than the smallest MTU along an
       IP network path, because this results in either packet loss or
       packet fragmentation.
---
Section 3.8 OLD:
     retransmission (after a timeout)
- move timeout, since this is no longer the norm.
NEW:
     retransmission
---
OLD:
    In particular, R2 for a SYN segment MUST be set large
    enough to provide retransmission of the segment for at least 3
    minutes.
- not numbered as a MUST.
---
(seventh step) OLD:
     an push flag
NEW:
     a push flag
---
OLD:
     IF our FIN
NEW:
     If the FIN segment
---
OLD:
    port
            The portion of a socket that specifies which logical input or
            output channel of a process is associated with the data.
- The definition of "port" appears to be in terms of "socket" which it 
should not be.
- What is a channel etc. This needs redefined in modern language.
---
OLD:
    internet address
            A source or destination address specific to the host level.
NEW:
    internet address
            The network layer address.
---
OLD:
    Source Address
            The source address, usually the network and host identifiers.
NEW:
    Source Address
            The network layer address of the sending endpoint.
---
OLD:
    Destination Address
            The destination address, usually the network and host
            identifiers.
NEW:
    Destination Address
            The network layer address of the remote endpoint.
---
OLD (TOS):
     containing the Differentiated Services Code Point (DSCP)
         value and two unused bits.
NEW:
     containing the Differentiated Services Code Point (DSCP)
         value and the 2-bit ECN codepoint [RFC3168].
---
OLD:
     The "tcpcrypt" [45]Experimental
- insert space
OLD:
     The "tcpcrypt" [45] Experimental
---
OLD:
     like Appropriate Byte Counting (ABC)

- Please Insert reference to ABC - RFC3465.
---
OLD:
             * Urgent pointer advance (see Section 3.8.5) (MUST-32).
- This is no requirement here.
---
OLD:
     Error responses are given as character strings.
- What does that mean? and how are these strings specified - unicode, 
ascii?
- I suspect the present intention is that:
NEW:
     Error responses in this document are identified by character strings.

+++++++++++++++++++++++++

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Aug 2019 16:39:48 +0100

I promised to provide review comments for rev 14 of RFC 793 bis. This 
review comes in two parts, the second (this) contains what I think are 
issues and questions about how to express the document intention.

best wishes,

Gorry

---

Technical Issues.
---
Section 2 - OLD:
    Anycast applications exist
    that successfully use TCP without modifications, though there is some
    risk of instability due to rerouting.
- Why "rerouting" rather than any other "change of forwarding behaviour",
I'd have expected this for instance after an ECMP rehash, or any L2 
policy change.

---
Section 3 - OLD:
      Reserved for future use.  Must be zero in generated segments and
      must be ignored in received segments, if corresponding future
      features are unimplemented by the sending or receiving host.
- why is this not an RFC2119 requirement to set and check the reserve 
fields, this
would seem much more normal and the receiver behaviour at least is required?
---
Section 3 - OLD:
      If a
      segment contains an odd number of header and text octets to be
      checksummed, the last octet is padded on the right with zeros to
      form a 16 bit word for checksum purposes.
- why is this not an RFC2119 requirement to insert the padding, this
seems required for correctness?
---
OLD:
        This option code may be used between options, for example, to
         align the beginning of a subsequent option on a word boundary.
- this seems like a RFC2119 "MAY", since it specifies permission to 
include this.
---
OLD:
         There is no guarantee that senders will use this option, so
         receivers must be prepared to process options even if they do
         not begin on a word boundary.
-  this seems like a RFC2119 "MUSR", since it specifies requirement to 
process this.
---
Section 3.1- OLD (on MSS):
         This field may be
         sent in the initial connection request (i.e., in segments with
         the SYN control bit set) and must not be sent in other segments.
-this seems like a RFC2119 "MUST NOT", since it specifies this as illegal.
---
OLD:
    However, even when the receive window is zero, a TCP must
    process the RST and URG fields of all incoming segments.
-- arguably a RFC2119 "MUST", since it specifies a requirement.
NEW:
    A TCP receiver MUST
    process the RST and URG fields of all incoming segments,
    even when the receive window is zero.
---
OLD, Section: "   Initial Sequence Number Selection"
- This I think needs to refer to "Defending against Sequence Number 
Attacks" in RFC 6528, which formally updated RFC793. I question - if the 
RFC793 text is safe and correct.
- In reviewing this, please also fix "cryptographic has of the 
concatenation"
---
OLD, Section: "   The TCP Quiet Time Concept"
- Found this section quite amusing. Is this concept widely implemented 
in stacks?
- The examples given need updated, for instance one example starts "At 2 
megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line of 
thinking becomes problematic.
- There is an odd sentence that states:
"In the absence of knowledge
    about the sequence numbers used on a particular connection, the TCP
    specification recommends that the source delay for MSL seconds before
    emitting segments on the connection, to allow time for segments from
    the earlier connection incarnation to drain from the system."
- how would the "source" know the MSL rather than use the Internet default?
- To me, this section raises many questions about whether this is best 
current practice.
---
OLD:
     As a general rule, reset (RST) must be sent whenever...
- I can't fathom what was intended, isn't this a RFC2119 SHOULD?
---
OLD:
    SYNs addressed to a non-existent connection are
    rejected by this means.
- Is that a complicated way of saying an RST is sent, or is it something 
else, please clarify,
is the word "addressed" correct here? Could this be rewritten as a "SYN 
segment that
does not match an existing connection..."
- This then leads me to ask why this does not refer to SYN cookies?
---
OLD:
       any unacceptable segment (out of window sequence number or
       unacceptable acknowledgment number) must elicit only an empty
       acknowledgment segment containing
- what does "elicit" mean here and what is an empty ACK segment?
---
OLD:
    We assume that the TCP will signal a user,
    even if no RECEIVEs are outstanding, that the other side has closed,
    so the user can terminate his side gracefully.
- what is this about?
- is the language of single user appropriate? and
what does gracefully actually mean?
---
OLD:
    Users must keep reading connections they close for
    sending until the TCP says no more data.
- Is that specifying application behaviour? and how does it "say", 
please rephrase.
---
OLD:
    The MSS value to be sent in an MSS option must be less than or equal
    to:
- is this a RFC2119 requirement?
---
OLD:
    As a result, when the effective MTU of an interface varies, TCP
    SHOULD use the smallest effective MTU of the interface to calculate
    the value to advertise in the MSS option (SHLD-6).
- what does "varies" mean here? The MSS is computed when the SYN is 
exchanged
is this actually just:
NEW:
    When multiple IP interfaces have different effective MTUs, TCP
    SHOULD use the smallest effective MTU of the interface to calculate
    the value to advertise in the MSS option (SHLD-6).
---
OLD:
3.7.5.  IPv6 Jumbograms

    In order to support TCP over IPv6 jumbograms, implementations need to
    be able to send TCP segments larger than the 64KB limit that the MSS
    option can convey.  RFC 2675 [6] defines that an MSS value of 65,535
    bytes is to be treated as infinity, and Path MTU Discovery [3] is
    used to determine the actual MSS.
- This was discussed in the 6Man WG in Montreal, and while there was no
consensus reached to obsolete jumbograms, there was encouragement
to ensure that specs describe jumbo grams appropriate, rather than
suggesting support is required. In this sense, I recommend adding
something like:
NEW:
    The Jumbo Payload option need not be implemented or understood by
    IPv6 nodes that do not support attachment to links with a MTU greater
    than 65,575 [RFC2675], and  the present IPv6 Node Requirements
    does not include support for Jumbograms [RFC8504].
---
Section 3.8.1
OLD:
    If a retransmitted packet is identical to the original packet (which
    implies not only that the data boundaries have not changed, but also
    that the window and acknowledgment fields of the header have not
    changed), then the same IP Identification field MAY be used (see
    Section 3.2.1.5 of RFC 1122) (MAY-4).
- What is this MAY about? Is it about the IPv4 IPID field and is that really
important for a TCP spec?
---
Section 3.8.3
OLD:
       pass negative advice (see [14]
       Section 3.3.1.4) to the IP layer, to trigger dead-gateway
       diagnosis.
- Is this still best current practice? - If so please explain and cite RFCs.
---
OLD:
       (e) TCP SHOULD inform the application of the delivery problem
       (unless such information has been disabled by the application; see
       Asynchronous Reports section), when R1 is reached and before R2
       (SHLD-9).  This will allow a remote login (User Telnet)
       application program to inform the user, for example.

- Is this still best current practice? - If so please is there a ref?.
---
OLD:
       (e) TCP SHOULD inform the application of the delivery problem
       (unless such information has been disabled by the application; see
       Asynchronous Reports section), when R1 is reached and before R2
       (SHLD-9).  This will allow a remote login (User Telnet)
       application program to inform the user, for example.

- Is this still best current practice?
---
OLD:
    The value of R1 SHOULD correspond to at least 3 retransmissions, at
    the current RTO (SHLD-10).  The value of R2 SHOULD correspond to at
    least 100 seconds (SHLD-11).
- Is this still best current practice?
---
Section 3.8.6.3 Delayed ACK.
OLD:
    and in a stream of full-sized segments there
    SHOULD be an ACK for at least every second segment (SHLD-19).
- Delayed ACK is specified in RFC1122 as: "...and in a stream of 
full-sized segments there SHOULD be an ACK for at least every second 
segment." Although correct, this does not specify a behaviour when 
segments are not "full-sized". When asked by people, I have think this 
should be something like:
NEW:
"the receiver SHOULD send an ACK when the data
needing acknowledgment corresponds to no more than two full-sized (MSS) 
segments."
---
Section 3.9
- Section 3.1 of RFC8303 also identifies primitives provided by TCP and 
could be used as a an additional reference to the primitives outside of 
the stylised version presented in RFC793.
---
OLD:
          We assume that the local TCP is aware of the identity of the
          processes it serves and will check the authority of the process
          to use the connection specified....
          These
          considerations are the result of concern about security, to the
          extent that no TCP be able to masquerade as another one, and so
          on.  Similarly, no process can masquerade as another without
          the collusion of the TCP.
- Is this still meaningful. What does "aware of the identity" mean? and 
what does the stack will "check the authority" mean?
- I don't6 have a clue what "no TCP be able to masquerade as another 
one" means.
- Please supply text of remove this.
---
OLD:
      set includes experimental options that can be extended to support
      multiple concurrent uses [34].
and
OLD:
          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).
- what does this mean in today's process architecture with off-loading, 
multiple cores etc?
- I think the requirement remains, but the text needs changed.
---
OLD:
             Any other control or text-bearing segment (not containing
             SYN) must have an ACK and thus would be discarded by the ACK
             processing.  An incoming RST segment could not be valid,
             since it could not have been sent in response to anything
             sent by this incarnation of the connection.  So you are
             unlikely to get here, but if you do, drop the segment, and
             return.
- what is a text bearing segment?
- "So you are unlikely to get here, but if you do," ... sounds like a 
source code
comment rather than a spec in 2020!
---