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

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 14:41:42 -0700

Hi, Wes (et al.),

Picking this thread back up...

On 3/28/2017 3:18 PM, Wesley Eddy wrote:
> On 3/28/2017 6:06 PM, Joe Touch wrote:
>> Some observations:
>>
>> 3.1 currently defined options
>>      this either needs to be the complete current list or indicate that
>> the list is elsewhere (the latter seems better to me)
>>      if list elsewhere, the discussion should be clear that this doc
>> defines only the following options; others are defined elsewhere
>>      is there any notion of the minimum required options? if so, is this
>> that set? (it might be useful to say so)
>
> I propose that this should be described as the minimum required set,
> and that we add pointer to the IANA registry of TCP Option Kind
> Numbers for the complete set:
> https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

IMO, the text that follows should be replaced:

     Currently defined options include (kind indicated in octal):

         Kind     Length    Meaning
         ----     ------    -------
          0         -       End of option list.
          1         -       No-Operation.
          2         4       Maximum Segment Size.

     TODO - I think we may need to include designated experimental
     options and RFC 6994 reference here

Here's a suggestion of the new text:

     The list of all currently defined options is managed by IANA [ref],
     and each option is defined in other RFCs, as indicated there. That set
     includes experimental options that can be extended to support multiple
     concurrent uses [RFC6994].

     A given TCP implementation can support any currently defined options, 
     but the following options MUST be supported (kind indicated in octal):

         Kind     Length    Meaning
         ----     ------    -------
          0         -       End of option list.
          1         -       No-Operation.
          2         4       Maximum Segment Size.

>
>
>> throughout
>>      the discussion of PMTU and MSS might benefit from an update as per
>> draft-iett-intarea-tunnels
>>      key points:
>>          PMTU discovery assumes TCP set IP to prevent both on-path (for
>> IPv4) and source fragmentation (IPv4 and IPv6), otherwise it optimizes
>> source fragment size rather than avoiding source fragmentation
>>          MSS is defined in terms of EMTU_R, which is independent of PMTU
>>          there are two effective MTUs - EMTU_S and EMTU_R. The former is
>> set and may or may not be limited by PMTU.
>
> If clarity can be improved in 793bis, that sounds good to me.  The
> text currently is patched together from bits of many other RFCs.

Some suggestions:

------------------------------------------------------------
In Sec 3.1, change:

        Maximum Segment Size Option Data: 16 bits

        If this option is present, then it communicates the maximum
        receive segment size at the TCP which sends this segment.  This

To:

        Maximum Segment Size Option Data: 16 bits

        If this option is present, then it communicates the maximum
        receive segment size at the TCP which sends this segment.  This 
        value is limited by the IP reassembly limit. This

and in Sec 7.3.1, change:

   The maximum size of a segment that TCP really sends, the "effective
   send MSS," MUST be the smaller of the send MSS (which reflects the
   available reassembly buffer size at the remote host) and the largest
   size permitted by the IP layer:

       Eff.snd.MSS =

           min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

   where:

   o  SendMSS is the MSS value received from the remote host, or the
      default 536 for IPv4 or 1220 for IPv6, if no MSS option is
      received.

   o  MMS_S is the maximum size for a transport-layer message that TCP
      may send.

   o  TCPhdrsize is the size of the fixed TCP header and any options.
      This is 20 in the (rare) case that no options are present, but may
      be larger if TCP options are to be sent.  Note that some options
      may not be included on all segments, but that for each segment
      sent, the sender should adjust the data length accordingly, within
      the Eff.snd.MSS.

   o  IPoptionsize is the size of any IP options associated with a TCP
      connection.  Note that some options may not be included on all
      packets, but that for each segment sent, the sender should adjust
      the data length accordingly, within the Eff.snd.MSS.

   The MSS value to be sent in an MSS option should be equal to the
   effective MTU minus the fixed IP and TCP headers.  By ignoring both
   IP and TCP options when calculating the value for the MSS option, if
   there are any IP or TCP options to be sent in a packet, then the
   sender must decrease the size of the TCP data accordingly.  RFC 6691
   [21] discusses this in greater detail.

   The MSS value to be sent in an MSS option must be less than or equal
   to:

      MMS_R - 20

   where MMS_R is the maximum size for a transport-layer message that
   can be received (and reassembled).  TCP obtains MMS_R and MMS_S from
   the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC
   1122.

To:

   The maximum size of a segment that TCP really sends, the "effective
   send MSS," MUST be the smaller of the send MSS (which reflects the
   available reassembly buffer size at the remote host, the EMTU_R [RFC1122]) and the largest
   transmission size permitted by the IP layer (EMTU_S [RFC1122]):

       Eff.snd.MSS =

           min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize

   where:

   o  SendMSS is the MSS value received from the remote host, or the
      default 536 for IPv4 or 1220 for IPv6, if no MSS option is
      received.

   o  MMS_S is the maximum size for a transport-layer message that TCP
      may send.

   o  TCPhdrsize is the size of the fixed TCP header and any options.
      This is 20 in the (rare) case that no options are present, but may
      be larger if TCP options are to be sent.  Note that some options
      may not be included on all segments, but that for each segment
      sent, the sender should adjust the data length accordingly, within
      the Eff.snd.MSS.

   o  IPoptionsize is the size of any IP options associated with a TCP
      connection.  Note that some options may not be included on all
      packets, but that for each segment sent, the sender should adjust
      the data length accordingly, within the Eff.snd.MSS.

   The MSS value to be sent in an MSS option should be equal to the
   effective MTU minus the fixed IP and TCP headers.  By ignoring both
   IP and TCP options when calculating the value for the MSS option, if
   there are any IP or TCP options to be sent in a packet, then the
   sender must decrease the size of the TCP data accordingly.  RFC 6691
   [21] discusses this in greater detail.

   The MSS value to be sent in an MSS option must be less than or equal
   to:

      MMS_R - 20

   where MMS_R is the maximum size for a transport-layer message that
   can be received (and reassembled at the IP layer).  TCP obtains MMS_R and MMS_S from
   the IP layer; see the generic call GET_MAXSIZES in Section 3.4 of RFC
   1122. These are defined in terms of their IP MTU equivalents, EMTU_R and EMTU_S [RFC1122].

---------------------------------------------
In Sec 3.7.2, change:

   A TCP implementation may be aware of the MTU on directly connected
   links, but will rarely have insight about MTUs across an entire
   network path.  For IPv4, RFC 1122 provides an IP-layer recommendation
   on the default effective MTU for sending to be less than or equal to
   576 for destinations not directly connected.  For IPv6, this would be
   1280.  In all cases, however, implementation of Path MTU Discovery
   (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is
   strongly recommended in order for TCP to improve segmentation
   decisions.

   PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between
   TCP, IP, and ICMP protocols. Several adjustments to a TCP
   implementation with PMTUD are described in RFC 2923 in order to deal
   with problems experienced in practice [6].  PLPMTUD [13] is a
   Standards Track improvement to PMTUD that relaxes the requirement for
   ICMP support across a path, and improves performance in cases where
   ICMP is not consistently conveyed.  The mechanisms in all four of
   these RFCs are recommended to be included in TCP implementations.

To:

   A TCP implementation may be aware of the MTU on directly connected
   links, but will rarely have insight about MTUs across an entire
   network path.  For IPv4, RFC 1122 provides an IP-layer recommendation
   on the default effective MTU for sending to be less than or equal to
   576 for destinations not directly connected.  For IPv6, this would be
   1280.  In all cases, however, implementation of Path MTU Discovery
   (PMTUD) and Packetization Layer Path MTU Discovery (PLPMTUD) is
   strongly recommended in order for TCP to improve segmentation
   decisions. Both PMTUD and PLPMTUD help TCP choose segment sizes that
   avoid both on-path (for IPv4) and source fragmentation (IPv4 and IPv6).

   PMTUD for IPv4 [2] or IPv6 [3] is implemented in conjunction between
   TCP, IP, and ICMP protocols. It relies both on avoiding source fragmentation
   and setting the IPv4 DF (don't fragment) flag, the latter to inhibit
   on-path fragmentation. It relies on ICMP errors from routers along the path,
   whenever a segment is too large to traverse a link. Several adjustments to a TCP
   implementation with PMTUD are described in RFC 2923 in order to deal
   with problems experienced in practice [6].  PLPMTUD [13] is a
   Standards Track improvement to PMTUD that relaxes the requirement for
   ICMP support across a path, and improves performance in cases where
   ICMP is not consistently conveyed, but still tries to avoid source
   fragmentation.  The mechanisms in all four of
   these RFCs are recommended to be included in TCP implementations. 

------------------------------------------------------------