]> Amazon Web Services

440 Terry Ave N Seattle WA 98109 USA nsd.ietf@gmail.com

TSV TCPM Working Group Internet-Draft TCP option space is scarce resource as its maximum length is limited to 40 bytes. This limitation becomes more significant in SYN segments as all options used in a connection should be exchanged during SYN negotiations. This document proposes a new SYN option negotiation scheme that can aggregate multiple TCP options in SYN segments into a single option so that more options can be negotiate during 3-way handshake. With its simple design, the approach does not require fundamental changes in TCP.

Introduction TCP option space is scarce resource as its maximum length is limited to 40 bytes because the length of the Data Offset field in the TCP header is 4 bits . This limitation is a critical issue especially for SYN segments. This is because although a TCP endpoint can send only one SYN segment to its peer, SYN segments need to contain all options expected to be used for the connection. As a result, the current SYN option space tends to be congested. Many TCP connections use MSS , Timestamp and Window Scale , SACK Permitted options which already consume 19 bytes (10 + 4 + 3 + 2). In addition to these options, if a connection wants to use Multipath TCP , it requires additional 4-12 bytes for MP_CAPABLE or 12-16 bytes for MP_JOIN option. Similarly, TCP Fast Open and TCP AO require additional 6-18 bytes and 16 bytes respectively. Moreover, Experimental Option Format defined in requires 16 bits or 32 bits ExID, which means the length of any experimental options will have at least 4 bytes. If an endpoint is willing to add some of extra options in addition to commonly used options, 40 bytes space may not be sufficient. If a SYN segment cannot accommodate all options that an endpoint wants to use, the endpoint needs to give up using some of them. This problem affects the extensibility of TCP. There have been various proposals in order to extend option space in SYN Segments such as , , , and . These proposals have adopted one or both of the following two types of approach.

• Extending TCP header in SYN segment: This approach tries to accommodate more options in a SYN segment by using payload (e.g override Data Offset field in TCP header).
• Using Multiple SYN or SYN-like segment: This approach uses multiple SYN segments or additional segments that can be treated as a SYN segment (e.g sending another SYN with wrong checksum or from different source port).

However, these kinds of approach induce some complexity as it needs to update fundamental TCP design and have potential risks for middlebox interventions because of it. Instead, we propose a simple alternate approach that can aggregate multiple TCP options into a single options. As this approach does not require drastic changes to TCP SYN negotiation scheme, the risk for middlebox interventions will be minimized. also proposes a scheme to aggregate multiple options as many of these options are basically about negotiating support with the peer before actual use of the option. However, our approach requires less option space as it can aggregate and condence some TCP options to create more option space for others. Note that specifically target controlled domains to nullify the implications of the presence of middleboxes. The proposed approach in the draft cannot aggregate all kinds of options. However, we believe it still will be useful especially for newly defined experimental options that would require anyway negotiating support with the peer before actually making use of longer forms of the option. Subsequent uses may utilize the EDO extension if needed. One example use case for our approach is . In order to use the feature proposed in the document, endpoints need to exchange a 4-byte TCP option during 3-way handshake so that they can check if the peer is capable of the feature. However, whether an endpoint supports the feature or not is just 1-bit information. Using 4-byte field to carry 1-bit information looks redundant. On the other hand, Aggregated Option can accommodate up to 24 TCP options like this example into a single TCP option. Also, even if more than 1-bit information needs to be carried in a TCP option for a certain feature, it is still possible to utilize aggregated options in some cases. In such cases, an endpoint can confirm that the peer supports the feature it wants to use by using the aggregated option. After that, it can continue to negotiate required parameters through 3rd segment and 4th segment. This type of approach is already used in MPTCP . Hence, we believe this scheme can be applicable to many other TCP extensions.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

• Original Option format: refers to the option format as defined in
• Aggregated Option format: refers to indication of support of a TCP option by setting the corresponding bit in the Aggregated TCP Option.

Aggregated Option Design

Option Format The aggregated option can be used to indicate that an endpoint wants to enable the specified features during SYN segment exchanges. This option uses one bit in the option field for one TCP option. The receiver of the option also uses this option to indicate that it agrees to use the requested features or not. The format of aggregated option format is shown in Figure 1. The option contains 1-byte field named called "Aggregated Block". Aggregated Option can accommodate 1-3 Aggregated Blocks.

Aggregated Option format

Figure 2 shows the format of Aggregated block. Aggregated block has 1 byte length which consists of 2 bits "Group ID" (GID) field and 6 bits "Option Bits" field. The options supported by Aggregated Option are split into 4 groups. The Group ID field is used to identify the group identifier of the option bits in the Aggregated Option and each single bit in Option Bits field represent a option in the group. If all options that an endpoint wants to aggregate belong to the same Group ID, the aggregated option needs to contain only one Aggregated Block. Otherwise, it needs to contain multiple blocks as needed.

Aggregated Block format

GID field in Aggregated Block indicate the group ID that option bits in the block belongs to. Aggregated Blocks appear in SYN and SYN ACK segments, however, different mappings between GID value in the option and Group ID are used for these two segments. This is because some implementations may copy back unknown options in SYN/ACK segments. These mappings are used not to be confused by such cases. Figure 3 shows the mapping between GID value in the option and Group ID. For example, GID value 1 in SYN represents group 2, while GID value 1 in ACK segment for SYN ACK represents group 1.

Mapping between GID value and Group ID

The allocation of the bit in Option Bits field in each group will be managed by the registry provided by IANA. Since an aggregated block has 6-bits field to indicate options, one group can have 6 options at most. As a result, the maximum number of options that can be used with Aggregated Option will be limited to 24. We believe this is sufficient number for the time being based on the current usage of option code points. The Aggregated Option MUST be only used in SYN segments. When an endpoint receives SYN segments with Aggregated Option, it checks Aggregated Blocks in the option. Otherwise, the segment MUST be silently discarded. If it contains Aggregated Blocks, the options specified in the blocks MUST be processed as well as options in original formats. When a responder sends back a SYN ACK to the initiator, it SHOULD send back its response with Aggregated Option. But, it MAY uses original format of the options for the response as long as there is enough option space.

Option Bits Registration As described in Section 3, Aggregated Option has 24 Option bits space and each bit represents a single option ID. The allocation of the Option Bits in Aggregated Option is maintained by IANA. If a new option can be aggregatable, one can request Option Bit in addition to the current procedure, requesting TCP Option Kind Number in . If an option already has assigned TCP Option Kind Number, one can request Option bit only which will represent the assigned option kind.

Utilizing 3rd and 4th Segments for Further Negotiations Aggregated Option is designed to exchange 1-bit information for each TCP extension that indicate the willingness to use the feature. Hence, if a TCP extension wants to carry more information in the TCP option for the extension, Aggregated Option is basically not applicable for it. However, it is still possible for these TCP extensions to utilize Aggregated Option in some situations. It is based on the fact that not all TCP extensions will be used right after SYN exchanges. For example, SACK options are only used when there are packet losses. If a TCP extension is not used right after SYN exchange, it is possible to exchange additional parameters by using utilizing 3rd segments and 4th segments. This approach is already used in MPTCP . As we have a solid precedence, we believe it will not be difficult to implement similar negotiation schemes for other features. However, discussing negotiation schemes with 3rd and 4th segments is out of scope of the document.

Security Considerations We believe Aggregated Option maintains the same level of security as other TCP options does.

IANA Considerations This document requests new TCP option codepoint. In addition, this document requires new registry for the option. They are described in the following subsections.

Aggregated Option This document requests to add new option: Aggregated Option to the TCP option space registry which points to this document as follows:

Aggregated Option Format

Option Bits Registry for Aggregated Option This document also requests to create a "Aggregated Option Identifiers" registry in IANA registries. The registry maintains 24 records which are mapped to the TCP Option Kind Number Records in The 24 records are divided into 4 groups so that each group contains 6 records.

Acknowledgments The authors would like to appreciate Mohamed Boucadair for his insightful comments on this document.

Contributors The contents in this document are the individual contributions from the authors and do not relate to the authors' positions at their affiliations.

References Normative References This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it 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 RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK] This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein. This document obsoletes RFC 1323 and describes changes from it. This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. ICSI In this document we aim to solve several problems caused by TCP's lack of header space for certain values by increasing the size of header without changing the semantics of the protocol. UPC University of Cambridge TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. NASA GRC/Verizon FNS Google Inc This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options. Cisco This document discusses a possible approach to TCP option space expansion, which allows placing the long TCP options into the TCP SYN segments. Independent Consultant The Aerospace Corporation This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. BT This document describes an experimental method to extend the limited space for control options in every segment of a TCP connection. It can use a dual handshake so that, from the very first SYN segment, extra option space can immediately start to be used optimistically. At the same time a dual handshake prevents a legacy server from getting confused and sending the control options to the application as user-data. The dual handshake is only one strategy - a single handshake will usually suffice once deployment has got started. The protocol is designed to traverse most known middleboxes including connection splitters, because it sits wholly within the TCP Data. It also provides reliable ordered delivery for control options. Therefore, it should allow new TCP options to be introduced i) with minimal middlebox traversal problems; ii) with incremental deployment from legacy servers; iii) without an extra round of handshaking delay iv) without having to provide its own loss recovery and ordering mechanism and v) without arbitrary limits on available space. Orange Orange This document defines an experimental TCP option that can be used to negotiate a set of options that are supported by two TCP endpoints. The main motivation for designing this option is the optimization of the option space for SYN segments. Independent Consultant MTI Systems TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 9293 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. n.d.