Re: [tcpm] TCP option kind number for TCP Fast Open

Hi, Michael,

29 is unassigned and available.

Also, IMO, we should not shy away from using numbers that others are
squatting on. E.g., 31-31 was only used by TCPCT in Internet Drafts;
when it was released, it was implemented using 253 and AFAICT only in
Linux versions that have since been cleaned up.

Joe

On 10/1/2014 8:26 AM, Scharf, Michael (Michael) wrote:
> Hi all,
> 
> According to TCPM consensus, the plan is to allocate TCP option kind number 34 for TCP fast open. This number is "reserved" according to http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml.
> 
> If there are suggestions that another value would be more appropriate, please speak up ASAP. 
> 
> Best regards
> 
> Michael
> 
> 
> 
> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
> Sent: Tuesday, September 30, 2014 11:36 PM
> To: IETF-Announce
> Cc: tcpm chair; tcpm mailing list; RFC Editor
> Subject: Document Action: 'TCP Fast Open' to Experimental RFC (draft-ietf-tcpm-fastopen-10.txt)
> 
> The IESG has approved the following document:
> - 'TCP Fast Open'
>   (draft-ietf-tcpm-fastopen-10.txt) as Experimental RFC
> 
> This document is the product of the TCP Maintenance and Minor Extensions
> Working Group.
> 
> The IESG contact persons are Martin Stiemerling and Spencer Dawkins.
> 
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/
> 
> 
> 
> 
> 
> Technical Summary
> 
>    This document describes an experimental TCP mechanism 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, thus saving 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 detailed in the Applicability section.
> 
> Working Group Summary
> 
>   This document was extensively discussed and reviewed by the TCPM
>   working group and there is strong support to publish the
>   document. While being an experimental document, the TCPM working
>   group decided to ask IESG for approving an IANA allocation of a new
>   TCP option codepoint.
> 
> Document Quality
> 
>   The protocol extension described in this document is implemented and
>   deployed in the Linux TCP/IP stack, and it is supported by the Chrome
>   Web browser and all Google servers. Experimental results have been
>   discussed in the TCPM working group. An early SECDIR review 
>   concluded that the document had no substantive issues.
> 
> Personnel
> 
>   The Document Shepherd is Michael Scharf
>   <michael.scharf@alcatel-lucent.com>. The Responsible Area Director
>   is Martin Stiemerling <mls.ietf@gmail.com>.
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 