Section Appendix A. Other Implementation Notes

This section includes additional notes and references on TCP
   implementation decisions that are currently not a part of the RFC
   series or included within the TCP standard.  These items can be
   considered by implementers, but there was not yet a consensus to
   include them in the standard.
A.1.  IP Security Compartment and Precedence
   The IPv4 specification [1] includes a precedence value in the (now
   obsoleted) Type of Service (TOS) field.  It was modified in [20] and
   then obsoleted by the definition of Differentiated Services
   (Diffserv) [4].  Setting and conveying TOS between the network layer,
   TCP implementation, and applications is obsolete and is replaced by
   Diffserv in the current TCP specification.
   RFC 793 required checking the IP security compartment and precedence
   on incoming TCP segments for consistency within a connection and with
   application requests.  Each of these aspects of IP have become
   outdated, without specific updates to RFC 793.  The issues with
   precedence were fixed by [25], which is Standards Track, and so this
   present TCP specification includes those changes.  However, the state
   of IP security options that may be used by Multi-Level Secure (MLS)
   systems is not as apparent in the IETF currently.
   Resetting connections when incoming packets do not meet expected
   security compartment or precedence expectations has been recognized
   as a possible attack vector [63], and there has been discussion about
   amending the TCP specification to prevent connections from being
   aborted due to nonmatching IP security compartment and Diffserv
   codepoint values.
A.1.1.  Precedence
   In Diffserv, the former precedence values are treated as Class
   Selector codepoints, and methods for compatible treatment are
   described in the Diffserv architecture.  The RFC TCP specification
   defined by RFCs 793 and 1122 included logic intending to have
   connections use the highest precedence requested by either endpoint
   application, and to keep the precedence consistent throughout a
   connection.  This logic from the obsolete TOS is not applicable to
   Diffserv and should not be included in TCP implementations, though
   changes to Diffserv values within a connection are discouraged.  For
   discussion of this, see RFC 7657 (Sections 5.1, 5.3, and 6) [50].
   The obsoleted TOS processing rules in TCP assumed bidirectional (or
   symmetric) precedence values used on a connection, but the Diffserv
   architecture is asymmetric.  Problems with the old TCP logic in this
   regard were described in [25], and the solution described is to
   document (although not marked as updating RFC 793), current
   implementations are expected to be robust in these conditions.  Note
   that the Diffserv field value used in each direction is a part of the
   interface between TCP and the network layer, and values in use can be
   indicated both ways between TCP and the application.
A.1.2.  MLS Systems
   The IP Security Option (IPSO) and compartment defined in [1] was
   refined in RFC 1038, which was later obsoleted by RFC 1108.  The
   Commercial IP Security Option (CIPSO) is defined in FIPS-188
   (withdrawn by NIST in 2015) and is supported by some vendors and
   operating systems.  RFC 1108 is now Historic, though RFC 791 itself
   has not been updated to remove the IP Security Option.  For IPv6, a
   similar option (Common Architecture Label IPv6 Security Option
   (CALIPSO)) has been defined [36].  RFC 793 includes logic that
   includes the IP security/compartment information in treatment of TCP
   segments.  References to the IP "security/compartment" in this
   document may be relevant for Multi-Level Secure (MLS) system
   implementers but can be ignored for non-MLS implementations,
   consistent with running code on the Internet.  See Appendix A.1 for
   further discussion.  Note that RFC 5570 describes some MLS networking
   scenarios where IPSO, CIPSO, or CALIPSO may be used.  In these
   special cases, TCP implementers should see Section 7.3.1 of RFC 5570
   and follow the guidance in that document.
A.2.  Sequence Number Validation
   There are cases where the TCP sequence number validation rules can
   prevent ACK fields from being processed.  This can result in
   connection issues, as described in [64], which includes descriptions
   of potential problems in conditions of simultaneous open, self-
   connects, simultaneous close, and simultaneous window probes.  The
   document also describes potential changes to the TCP specification to
   mitigate the issue by expanding the acceptable sequence numbers.
   In Internet usage of TCP, these conditions rarely occur.  Common
   operating systems include different alternative mitigations, and the
   standard has not been updated yet to codify one of them, but
   implementers should consider the problems described in [64].
A.3.  Nagle Modification
   In common operating systems, both the Nagle algorithm and delayed
   acknowledgments are implemented and enabled by default.  TCP is used
   by many applications that have a request-response style of
   communication, where the combination of the Nagle algorithm and
   delayed acknowledgments can result in poor application performance.
   A modification to the Nagle algorithm is described in [68] that
   improves the situation for these applications.
   This modification is implemented in some common operating systems and
   does not impact TCP interoperability.  Additionally, many
   applications simply disable Nagle since this is generally supported
   by a socket option.  The TCP standard has not been updated to include
   this Nagle modification, but implementers may find it beneficial to
   consider.
A.4.  Low Watermark Settings
   Some operating system kernel TCP implementations include socket
   options that allow specifying the number of bytes in the buffer until
   the socket layer will pass sent data to TCP (SO_SNDLOWAT) or to the
   application on receiving (SO_RCVLOWAT).
   In addition, another socket option (TCP_NOTSENT_LOWAT) can be used to
   control the amount of unsent bytes in the write queue.  This can help
   a sending TCP application to avoid creating large amounts of buffered
   data (and corresponding latency).  As an example, this may be useful
   for applications that are multiplexing data from multiple upper-level
   streams onto a connection, especially when streams may be a mix of
   interactive/real-time and bulk data transfer.