Aggregated Option for SYN Option Space Extension
draft-nishida-tcpm-agg-syn-ext-00
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Author |
|
Yoshifumi Nishida
|
|
Last updated |
|
2021-02-02
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
htmlized (tools)
htmlized
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group Y. Nishida
Internet-Draft Amazon Web Services
Intended status: Standards Track February 2, 2021
Expires: August 6, 2021
Aggregated Option for SYN Option Space Extension
draft-nishida-tcpm-agg-syn-ext-00
Abstract
TCP option space is scarce resource as its max 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 provide a feature to compress TCP options in SYN segments
and provide more option space. The proposed scheme does not update
the format of TCP header nor transmit any additional SYN or SYN-like
segments so that it has lower risks for middlebox interventions. In
addition, by combining another proposal for option space extension,
it is possible to provide further option space.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Nishida Expires August 6, 2021 [Page 1]
Internet-Draft Aggregated Option February 2021
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Basic Design . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Aggregated Option . . . . . . . . . . . . . . . . . . . . 4
3.2. Additional Information Exchange Using 3rd ACK Segments . 6
3.3. Examples of Option Exchanges with Aggregated Options . . 7
4. Option Bits Registration . . . . . . . . . . . . . . . . . . 9
5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Incremental Deployments for Aggregated Option . . . . . . 10
5.2. Middlebox Considerations . . . . . . . . . . . . . . . . 10
5.3. Which Options are Aggregatable . . . . . . . . . . . . . 10
5.4. Further Extensions . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Aggregated Option . . . . . . . . . . . . . . . . . . . . 11
7.2. Option Bits Registry for Aggregated Option . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
TCP option space is scarce resource as its max length is limited to
40 bytes. This limitation is a nominal issue especially for SYN
segment. This is because although a TCP endpoint can send only one
SYN segment to the 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
[RFC0793], Timestamp and Window Scale [RFC7323], SACK Permitted
options [RFC2018] which already consume 19 bytes (10 + 4 + 3 + 2).
In addition to them, if a connection wants to use Multipath TCP
[RFC8684], it requires additional 4-12 bytes for MP_CAPABLE or 12-16
bytes for MP_JOIN option. Similarly, TCP Fast Open [RFC7413] and TCP
AO [RFC5925] require additional 6-18 bytes and 16 bytes respectively.
Moreover, Experimental Option Format defined in [RFC6994] consumes
more option space as it requires additional 16 bits or 32 bits EXID
field than the standard option format. Hence, if an endpoint is
willing to activate some of extra features in addition to common
options, 40 bytes space may not be sufficient. If SYN segment cannot
Nishida Expires August 6, 2021 [Page 2]
Internet-Draft Aggregated Option February 2021
accommodate all required options, it means endpoints need to give up
using some features. This issue affects the extensibility of TCP.
There have been various proposals in order to extend option space in
SYN Segments [I-D.eddy-tcp-loo] [I-D.yourtchenko-tcp-loic]
[I-D.touch-tcpm-tcp-syn-ext-opt] [I-D.briscoe-tcpm-inner-space]
[I-D.allman-tcpx2-hack]. These proposals have adopted one or both of
the following two types of approach.
o 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)
o Using Multiple SYN or SYN-like segment: This approach tries to use
multiple SYN segment or additional segment that can be treated as
a SYN segment. (E.g sending another SYN with wrong checksum or
from different source port)
However, these approach tend to require a certain complexity and have
potential risks for middlebox interventions. In this document, in
order to reduce the risk for middlebox intervention we propose to
extend option space in SYN segments through the following approach
which utilizes "3rd segments". In this document, we define "3rd
segment" as the segments sent from initiator that contains
acknowledge for the SYN ACK segment from responder.
o Aggregated Option Format: we propose a new option format that can
aggregate multiple TCP options into a single option format so that
it can create more space than conventional option formats.
o Using 3rd segments for supplemental negotiation: we propose to use
3rd segment and its acknowledge for additional feature information
exchanges.
One important characteristic of this approach is that it does not
require any changes in SYN header format nor using multiple SYN or
SYN-like segments. In stead, it utilizes 3rd segments which should
looks legitimate segments from middleboxes' points of view. MPTCP
[RFC8684] specifications already requires the use of 3rd segment for
further information exchanges. Hence, in a sense, the proposal in
this document may look using the scheme in MPTCP for more generic
purposes. Given that the maturity and the deployment status of MPTCP
implementations, we believe that this approach has lower risks for
middlebox interventions without introducing lots of complexity in TCP
architecture.
Nishida Expires August 6, 2021 [Page 3]
Internet-Draft Aggregated Option February 2021
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Basic Design
The proposed scheme in this document has the following two design
criteria.
1. All feature negotiations are archived during a single SYN
exchange. No extra SYN or SYN-like segments are utilized.
2. No change is required for TCP header format. Use current option
space in TCP header and not use payload for option space.
These requirements ensure that the scheme can have simple
architecture and can traverse middleboxes without problems. In order
to fulfill this requirements, For this purpose, we propose a new
option format and a scheme for additional information exchange as
follows.
3.1. Aggregated Option
This aggregated option can be used only to indicate that an endpoint
want to enable the specified features in the option. This option
uses one bit to express one TCP option. This is because this option
is used only to indicate that an endpoint wants to use specified
features. The receiver of the option can only specify whether it
agrees to use the requested features or not. The format of
aggregated option format is shown in Figure 1. The option can
contains 0-3 Aggregated Blocks which have 1 byte length. The length
of the option format is varied by the number of Aggregated blocks in
the option.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--------------+---------------+ - - - - - - - +- - - - - - - -
| Kind = TBD | Length = 2-5 | Block #1 | Block #2 |
+--------------+---------------+ - - - - - - - +- - - - - - - -
| Block #3 |
- - - - - - - -
Figure 1: Aggregated Option format
Nishida Expires August 6, 2021 [Page 4]
Internet-Draft Aggregated Option February 2021
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
is split into 4 groups, such as an option defined in a standard RFC
belongs to group 1 or group 2, an option in an experimental RFC
belongs to group 3, etc. (Note: how to allocate option bits will be
discussed later) 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 one
group, the aggregated option will need to contain just one Aggregated
Block. However, if the option will need to contain multiple blocks
when an endpoint wants to use options in multiple groups.
0 1 2 3 4 5 6 7
+----------------------+
| GID | Option Bits |
+----------------------+
Figure 2: Aggregated Block format
GID field in Aggregated Block indicate the group ID that option bits
in the block belongs to. Aggregated Blocks are appeared 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 their
response segments. These mappings is used not to be confused by such
cases. Table Table 1 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.
+------------------+----------------------+----------------------+
| GID value in SYN | GID value in SYN ACK | Group ID Description |
+------------------+----------------------+----------------------+
| 0 | 1 | group 1 |
| | | |
| 1 | 2 | group 2 |
| | | |
| 2 | 3 | group 3 |
| | | |
| 3 | 0 | Extensions |
+------------------+----------------------+----------------------+
Table 1: Mapping between GID value and Group ID
Nishida Expires August 6, 2021 [Page 5]
Internet-Draft Aggregated Option February 2021
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 shown in Table 1, we currently propose to allocate 3 GID
for options and 1 GID is reserved for future extensions.
Consequently, the maximum number of options that can be aggregated
with Aggregated Option will be limited to 18. We believe this is
sufficient number for the time being based on the current usage of
option code points. In addition, Section Section 5.4 describes some
possibilities to overcome the limitation in case we need to support
more options to be supported.
Aggregated Option that contains Aggregated Blocks MUST be only used
in SYN segments. When an endpoint received SYN segments with
Aggregated Option, it checks Aggregated Blocks in the option. If the
option does not contain Aggregated Blocks, the segment MUST be
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 SYN ACK to the initiator, it
uses original formats of the options or Aggregated options depends on
remaining options space or other criteria.
3.2. Additional Information Exchange Using 3rd ACK Segments
Aggregated Option is used to negotiate the use of features that an
endpoint would like to activate. However, it does not provide a way
to negotiate additional information. This suffices for options that
do not require additional parameters such as SACK-Permit option.
However, if options need additional parameter exchanges, these
parameters will need to be sent through 3rd segment. When options
are sent in the 3rd segments, original formats of the options are
used. In this case, in order to solicit acknowledgement for this
segments, an initiator MUST include 2 bytes length Aggregated Option
to 3rd segment with the format shown in Figure 3.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--------------+---------------+
| Kind = TBD | Length = 2 |
+--------------+---------------+
Figure 3: 2-Byte Aggregated Option format
In addition, it MUST start retransmission timer even if it is a pure
ACK and MUST retransmit the same segment when the timer is expired.
Note that the 3rd segment does not have to be a pure ACK segment. If
an endpoint has data to be sent, it can send it with the segment.
Nishida Expires August 6, 2021 [Page 6]
Internet-Draft Aggregated Option February 2021
When a responder receives 2 bytes length Aggregated Option in the 3rd
segment, it MUST send back Aggregated Option to acknowledge the
arrival of the option. If responder does not need to receive
acknowledgement from initiator, it MUST send back a segment with
Aggregated Option with the format shown in Figure 4 to indicate the
end of option exchanges. If responder need to send additional
options that requires acknowledgement, it MUST send 2-bytes
Aggregated Option shown in Figure 3 and MUST start retransmission
timer for retransmission. An endpoint that receives Fin Aggregated
Option MUST not use Aggregated Options in subseqent segments.
Similarly, an endpoint that sends Fin Aggregated Option MUST not use
Aggregated Options once the segment is acknowledged.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+--------------+---------------+----------------+
| Kind = TBD | Length = 3 |1 1 0 0 0 0 0 0 |
+--------------+---------------+-----------------
Figure 4: Fin Aggregated Option format
When an endpoint sends a segment with 2 byte Aggregated Option, it
MUST retransmit the segment until it receives an ACK for the segment
with Aggregated Option (2 byte or Fin Aggregated Option). When it
receives an ACK for the segment without Aggregated Option, it MUST
ignore and discard the ACK.
3.3. Examples of Option Exchanges with Aggregated Options
We show 3 patterns of option negotiations with Aggregated Option in
the following examples: Figure Figure 5 , Figure Figure 6 and
Figure Figure 7. In these examples, we use hypothetical option A and
B. Option A is an option that does not require additional
information such as SACK Permit option. While Option B are an option
that needs to exchanges additional parameters. "Non-Agg options" in
the examples represent the options that are not aggregated, which are
sent with their original formats.
As shown in Figure 5, as option A does not require additional
information, exchanging SYN and SYN ACK segments with Aggregated
Options are enough for feature negotiation. In this case, initiator
sends back 3rd segment with Fin Aggregated Option only to indicate
the end of option negotiation.
Nishida Expires August 6, 2021 [Page 7]
Internet-Draft Aggregated Option February 2021
Initiator Responder
SYN + Non-Agg Options +
Aggregated Option
(bit for option A is set)
---------->
SYN ACK + Non-Agg Options +
Aggregated Option
(bit for option A is set)
<-----------
ACK + Fin Aggregated Option
---------->
Figure 5: Example of Aggregated Option #1
Figure 6 is an example that uses option B which require additional
information exchange. In this case, After exchanging Aggregated
Options during SYN exchanges, initiator sends 3rd ACK segment with
2-Byte Aggregated Options in addition to the original form of option
B. Similarly, responder sends back the ACK for the segment with
2-Bytes Aggregated Options in addition to the original form of Option
B. After that, initiator sends an ACK with Fin Aggregated Option
only to indicate the end of option negotiation.
Initiator Responder
SYN + Non-Agg Options +
Aggregated Option
(bit for option B is set)
---------->
SYN ACK + Non-Agg Options +
Aggregated Option
(bit for option B is set)
<----------
ACK + Option B +
2-Byte Aggregated Option
---------->
ACK + Option B +
2-Byte Aggregated Option
<----------
ACK + Fin Aggregated Option
---------->
Figure 6: Example of Aggregated Option #2
Nishida Expires August 6, 2021 [Page 8]
Internet-Draft Aggregated Option February 2021
Figure 7 also uses option B as Figure 6, however, initiator only
sends two segments for option negotiations. In this case, when
responder sends SYN-ACK, it sends back the segment with original form
of Option B. In this case, when responder sends back the ACK for 3rd
segment, it sends the segment with Fin Aggregated Option to indicate
the end of option negotiation. In this case, while sender utilizes
extra option space with Aggregated Option in 3rd segment, responder
uses option space only in SYN ACK segment. This use case can be
useful when only option space in SYN segment needs to be extended.
Initiator Responder
SYN + Non-Agg Options +
Aggregated Option
(bit for option B is set)
---------->
SYN ACK + Non-Agg Options +
option B
<----------
ACK + Option B +
2-Byte Aggregated Option
---------->
ACK + Option B +
Fin Aggregated Option
<----------
Figure 7: Example of Aggregated Option #3
4. Option Bits Registration
As described in Section Section 3, Aggregated Option has 18 Option
bits space and each bit represents a single option ID. The
allocation of the Option Bits in Aggregated Option is maintained by
IANA [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 [TCPParameters] . If a option already has
assigned TCP Option Kind Number, one can only request Option bit
which will represent the option kind.
5. Discussions
Nishida Expires August 6, 2021 [Page 9]
Internet-Draft Aggregated Option February 2021
5.1. Incremental Deployments for Aggregated Option
An endpoint MAY send the original form of an option and Aggregated
Option for the option in SYN segments if option space is available.
This may look redundant, but it can be useful when an endpoint sends
a SYN segment to a new destination. In this case, if the peers
support the option and Aggregated Option, they can send back
Aggregated Option in addition to the response for normal option
format. The endpoint cache this information and when it opens
another connection to the the same destination with a short interval,
it can send only Aggregated Option this time. If an endpoint did not
receive SYN ACK when it sent Aggregated Option to a new destination,
the retransmitted SYN segment SHOULD NOT include Aggregated Option.
5.2. Middlebox Considerations
As Aggregated Option will be a new option, there is a potential risk
that the option will be removed from the segment or the segment that
carries the option will be discarded by the middleboxes. While we
believe the risk for this risk is low from the past studies
[HONDA11], if endpoints try to aggregate well-known TCP options such
as SACK-Permit, MSS, TimeStamp to new destinations, it is recommended
to follow incremental deployment approach described in the previous
section. On the other hand, the risk for the removal of Aggregated
Option and new options can be considered mostly in the same level.
In this case, endpoints MAY send only the aggregated option to new
destinations.
If a middlebox strips Aggregated options in SYN segments but keeps
other options unchanged, the proposed scheme can behave safely. When
Aggregated Option in SYN segment from initiator is removed on
outgoing path, both endpoint will not activate any features in the
Aggregated Option. When Aggregated Option is removed on return path,
there will be a situation where the responder enables the features in
Aggregated Option while initiator disables the features. However,
the responder still can aware that the Aggregated Option is removed
on the return path when it receives the 3rd segments without
Aggregate Option. In this case, the responder can decide whether it
can continue the connection or reset it based on the features in the
Aggregated Option.
5.3. Which Options are Aggregatable
While we think most of options can be aggregated by using Aggregated
Option, there will be some limitations. One example would be TCP AO
[RFC5925] as it has to carry security information in SYN segments.
If an option must carry additional information for the feature like
TCP AO, we cannot aggregate the option. TCP Fast Open [RFC7413]
Nishida Expires August 6, 2021 [Page 10]
Internet-Draft Aggregated Option February 2021
would be another example as it needs to carry cached cookie
information in SYN segments. Sending cookie info in the 3rd segments
is not desirable from the objective of TCP Fast Open. However, when
initiator sends Fast Open Cookie Request, the request can be
aggregated as it does not carry additional information. Hence, we
still believe that it will be useful to aggregate TCP Fast Open
option in some cases.
5.4. Further Extensions
The proposed approach can aggregate 18 options with Aggregated
Options. We believe this is enough number for the time being based
on the current usages of TCP options. It is also possible to
accommodate more options by using Group id 4 which is currently
reserved for future extensions.
Aggregated Option can extend available space for TCP options in SYN
segments by utilizing 3rd segments and its acknowledgement. However,
there might be a situation where this is still not enough to
accommodate all TCP options that an endpoint would like to activate.
In this case, one possible approach is to utilize TCP Extended Data
Offset Option (EDO) [I-D.ietf-tcpm-tcp-edo]. As EDO supported Option
does not carry any information, it can be aggregated in Aggregated
Option. Once both endpoints agree to use the feature by SYN
exchange, an endpoint can start using EDO to extend option space in
the 3rd segments and its acknowledgement. This approach will create
more space for options in SYN segments although further discussions
will be required for more detailed design.
6. Security Considerations
We believe Aggregated Option maintains the same level of security as
other TCP options does, but further discussions will be required.
7. 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.
7.1. Aggregated Option
This document requests to add new option: Aggregated Option to the
TCP option space registry which points to this document as follows:
Nishida Expires August 6, 2021 [Page 11]
Internet-Draft Aggregated Option February 2021
+------+--------+--------------------+----------------+
| Kind | Length | Meaning | Reference |
+------+--------+--------------------+----------------+
| TBD | N | Aggregated Option | This Document |
+------+--------+--------------------+----------------+
Table 2: Aggregated Option Format
7.2. 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
[TCPParameters] The 24 records are divided into 4 groups so that each
group contains 6 records.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[HONDA11] Honda, M., "Is it still possible to extend TCP?", IMC
2011 , November 2011.
[I-D.allman-tcpx2-hack]
Allman, M., "TCPx2: Don't Fence Me In", draft-allman-
tcpx2-hack-00 (work in progress), May 2006.
[I-D.briscoe-tcpm-inner-space]
Briscoe, B., "Inner Space for TCP Options", draft-briscoe-
tcpm-inner-space-01 (work in progress), October 2014.
[I-D.eddy-tcp-loo]
Eddy, W. and A. Langley, "Extending the Space Available
for TCP Options", draft-eddy-tcp-loo-04 (work in
progress), July 2008.
[I-D.ietf-tcpm-tcp-edo]
Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
draft-ietf-tcpm-tcp-edo-10 (work in progress), July 2018.
Nishida Expires August 6, 2021 [Page 12]
Internet-Draft Aggregated Option February 2021
[I-D.touch-tcpm-tcp-syn-ext-opt]
Touch, J. and T. Faber, "TCP SYN Extended Option Space
Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-
ext-opt-09 (work in progress), July 2018.
[I-D.yourtchenko-tcp-loic]
Yourtchenko, A., "Introducing TCP Long Options by Invalid
Checksum", draft-yourtchenko-tcp-loic-00 (work in
progress), April 2011.
[IANA] "IANA Home Page", <https://www.iana.org/>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<https://www.rfc-editor.org/info/rfc6994>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[TCPParameters]
"Transmission Control Protocol (TCP) Parameters",
<https://www.iana.org/assignments/tcp-parameters/tcp-
parameters.xhtml#tcp-parameters-1>.
Nishida Expires August 6, 2021 [Page 13]
Internet-Draft Aggregated Option February 2021
Author's Address
Yoshifumi Nishida
Amazon Web Services
410 Terry Avenue North
Seattle, WA 98109
USA
Email: nishida@wide.ad.jp
Nishida Expires August 6, 2021 [Page 14]