[tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions

[Gorry Fairhurst <[e-mail]>]

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