<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="std" ipr="trust200902" docName="draft-nishida-tcpm-agg-syn-ext-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

   <front>
   <title abbrev="Aggregated Option">
           Aggregated Option for SYN Option Space Extension
   </title>

    <author initials='Y.N' surname="Nishida" fullname='Yoshifumi Nishida'> 
      <organization> Amazon Web Services </organization>
      <address><postal> <street>410 Terry Avenue North</street>
        <city>Seattle</city> <region>WA</region><code>98109</code>
        <country>USA</country>
        </postal>
        <email>nishida@wide.ad.jp</email>
      </address>
    </author>

   <date/>
   <abstract>
     <t>
       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.
   </t>
   </abstract>
</front>

<middle>
<section title="Introduction">
  <t>
   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 <xref target="RFC0793" />, Timestamp and Window Scale <xref target="RFC7323" />,
   SACK Permitted  options <xref target="RFC2018" /> which already consume 19 bytes (10 +  4 + 3 + 2).
   In addition to them, if a connection wants to use Multipath TCP <xref target="RFC8684" />,
   it requires additional 4-12 bytes for MP_CAPABLE or 12-16 bytes for MP_JOIN option.
   Similarly, TCP Fast Open <xref target="RFC7413" /> and TCP AO <xref target="RFC5925" />
   require additional 6-18 bytes and 16 bytes respectively.
   Moreover, Experimental Option Format defined in <xref target="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 accommodate all required options, it means 
   endpoints need to give up using some features. This issue affects the extensibility of TCP.
   </t>
   <t>
     There have been various proposals in order to extend option space in SYN Segments 
     <xref target="I-D.eddy-tcp-loo" />  <xref target="I-D.yourtchenko-tcp-loic" />
     <xref target="I-D.touch-tcpm-tcp-syn-ext-opt" /> 
     <xref target="I-D.briscoe-tcpm-inner-space" />
     <xref target="I-D.allman-tcpx2-hack" />.
     
     These proposals have adopted one or both of the following two types of approach.
     <list style="symbols">     
       <t> 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)
       </t>
       <t> 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)
       </t>
     </list>
   </t>
   <t>
     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.      
     <list style="symbols">
       <t> 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.</t>
       <t> Using 3rd segments for supplemental negotiation: we propose to use 3rd segment and its acknowledge
       for additional feature information exchanges. 
       </t>
     </list>
    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 <xref target="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.
     </t>
</section>

<section title="Conventions and Terminology">
   <t>
  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 <xref target="RFC2119"/>.
   </t>
</section>

<section title="Basic Design" anchor="design">
    <t>
    The proposed scheme in this document has the following two design criteria.
    <list style="numbers">
      <t> All feature negotiations are archived during a single SYN exchange.
      No extra SYN or SYN-like segments are utilized.
      </t>
      <t>No change is required for TCP header format. Use current option space in TCP header
         and not use payload for option space.
      </t> 
    </list>
    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.
    </t>
    <section title="Aggregated Option">
      <t>
    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 <xref target="option_format" />. 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. 

    <figure title="Aggregated Option format" anchor="option_format"><artwork>
                       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   |   
   - - - - - - - - 

    </artwork></figure>
      </t>
    <t>
    <xref target="block_format" /> 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.
    </t>
    <t>
      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.
      
     <figure title="Aggregated Block format" anchor="block_format"><artwork align="center">
   0  1  2  3  4  5  6  7 
   +----------------------+
   | GID |  Option Bits   |
   +----------------------+
     </artwork></figure>
    </t>
    <t>
      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 <xref target="gid_table" /> 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. 
    </t>

<texttable anchor="gid_table" title="Mapping between GID value and Group ID">
<ttcol align="center">GID value in SYN</ttcol>
<ttcol align="center">GID value in SYN ACK</ttcol>
<ttcol align="center">Group ID Description</ttcol>
<c>0</c><c>1</c><c> group 1 </c>
<c>1</c><c>2</c><c> group 2 </c>
<c>2</c><c>3</c><c> group 3 </c>
<c>3</c><c>0</c><c> Extensions </c>
</texttable>

     <t> 
    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 <xref target="gid_table"/>, 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 <xref target="extension" /> describes some possibilities to overcome the limitation
    in case we need to support more options to be supported.
     </t>
     <t>
      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. 
      </t>
    </section>
    <section title="Additional Information Exchange Using 3rd ACK Segments">
      <t>
	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
	<xref target="twobytes_format" />.

      <figure title="2-Byte Aggregated Option format" anchor="twobytes_format">
   <artwork align="center">	
                        1            
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
    +--------------+---------------+
    |  Kind = TBD  |  Length = 2   |
    +--------------+---------------+

    </artwork></figure>

	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. 
      </t>
      <t>
        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
	<xref target="fin_format" /> 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 <xref target="twobytes_format" /> 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.

    <figure title="Fin Aggregated Option format" anchor="fin_format"><artwork>
                       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 |
   +--------------+---------------+-----------------

    </artwork></figure>

	
      </t>
      <t>
	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. 
      </t>

    </section>
    <section title="Examples of Option Exchanges with Aggregated Options">
      <t>
	We show 3 patterns of option negotiations with Aggregated Option in the following
	examples: Figure <xref target="example1" /> , Figure <xref target="example2"/>
	and Figure <xref target="example3"/>. 
	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. 
      </t>
      <t>
	As shown in <xref target="example1"/>, 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.
      </t>
   <figure title="Example of Aggregated Option #1" anchor="example1"> <artwork>
              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)
                               &lt;-----------                

      ACK + Fin Aggregated Option			       
			      ---------->
   </artwork></figure>
   <t>
     <xref target="example2"/> 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.
   </t>
   <figure title="Example of Aggregated Option #2" anchor="example2"> <artwork>
              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)
                               &lt;----------                

      ACK + Option B +
      2-Byte Aggregated Option
                              ---------->

                                             ACK + Option B +
                                             2-Byte Aggregated Option
                               &lt;---------- 

      ACK + Fin Aggregated Option
			      ---------->
   </artwork></figure>
   <t>
     <xref target="example3"/> also uses option B as <xref target="example2"/>, 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. 
   </t>
   <figure title="Example of Aggregated Option #3" anchor="example3"> <artwork>
              Initiator                                   Responder

     SYN + Non-Agg Options +
     Aggregated Option 
     (bit for option B is set)
                              ---------->
                                             SYN ACK + Non-Agg Options +
                                             option B
                               &lt;----------                

      ACK + Option B +
      2-Byte Aggregated Option
                              ---------->

                                             ACK + Option B +
                                             Fin  Aggregated Option
                               &lt;---------- 

   </artwork></figure>
    </section>
</section>
<section title="Option Bits Registration">
  <t>
    As described in Section <xref target="design" />, 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 <xref target="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 <xref target="TCPParameters" /> .
    If a option already has assigned TCP Option Kind Number, one can only request Option bit which
    will represent the option kind. 
  </t>
</section>      
<section title="Discussions" anchor="discussions">
  <section title="Incremental Deployments for Aggregated Option">
    <t>
      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.
    </t>
    
  </section>

  <section title="Middlebox Considerations">
    <t> 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 <xref target="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.
    </t>
    <t>
      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. 
    </t>
  </section>
  
    <section title="Which Options are Aggregatable">
    <t>
      While we think most of options can be aggregated by using Aggregated Option, there will be some limitations.
      One example would be TCP AO <xref target="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 <xref target="RFC7413" /> 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. 
   </t>
    </section>
    <section title="Further Extensions" anchor="extension" >
    <t>
      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.
    </t>
    <t>
      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) <xref target="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.
     </t>
    </section>
</section>

<section title="Security Considerations">
<t>
  We believe Aggregated Option maintains the same level of security as other TCP options does,
  but further discussions will be required. 
</t>
</section>
<section title="IANA Considerations">
<t>
  This document requests new TCP option codepoint.
  In addition, this document requires new registry for the option.
  They are described in the following subsections.
</t>
<section title="Aggregated Option">
  <t>
    This document requests to add new option: Aggregated Option to the TCP option space registry
    which points to this document as follows:
  </t>

<texttable anchor="iana_table" title="Aggregated Option Format">
<ttcol align="center">Kind</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="center">Meaning</ttcol>
<ttcol align="center">Reference</ttcol>
<c>TBD </c> <c>N</c><c> Aggregated Option </c><c> This Document </c>
</texttable>
</section>

<section title="Option Bits Registry for Aggregated Option">
<t>
  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 <xref target="TCPParameters" /> The 24 records are divided into 4 groups so that 
  each group contains 6 records. 
</t>
</section>
 </section>
</middle>

<back>
<references title='Normative References'> 
	  <?rfc include="reference.RFC.2119" ?> 
</references>
<references title='Informative References'>
    <?rfc include="reference.RFC.0793" ?> 
    <?rfc include="reference.RFC.7323" ?> 
    <?rfc include="reference.RFC.2018" ?> 
    <?rfc include="reference.RFC.8684" ?>
    <?rfc include="reference.RFC.7413" ?> 
    <?rfc include="reference.RFC.5925" ?> 
    <?rfc include="reference.RFC.6994" ?>
    <?rfc include="reference.I-D.ietf-tcpm-tcp-edo"?>
    <?rfc include="reference.I-D.eddy-tcp-loo"?>
    <?rfc include="reference.I-D.touch-tcpm-tcp-syn-ext-opt" ?>
    <?rfc include="reference.I-D.yourtchenko-tcp-loic" ?>
    <?rfc include="reference.I-D.briscoe-tcpm-inner-space" ?>
    <?rfc include="reference.I-D.allman-tcpx2-hack" ?>
    <reference anchor="IANA" target="https://www.iana.org/">
        <front>
          <title>IANA Home Page</title>
          <author/>
           <date/>
      </front>
    </reference>

    <reference anchor="TCPParameters" target="https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1">
        <front>
          <title>Transmission Control Protocol (TCP) Parameters</title>
          <author/>
           <date/>
      </front>
    </reference>
  <reference anchor="HONDA11" target="">
   <front>
     <title> Is it still possible to extend TCP? </title>
    <author initials="M." surname="Honda" fullname="">  <organization />  </author>
    <date month="November" year="2011" />
   </front>
   <seriesInfo name="IMC 2011" value="" />
  </reference>
</references>
</back>

</rfc>

