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

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 1 Oct 2014 15:26:41 +0000

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:[email-masked]] 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
  <[email-masked]>. The Responsible Area Director
  is Martin Stiemerling <[email-masked]>.

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Oct 2014 15:19:48 -0700

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:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 1 Oct 2014 22:59:05 +0000

Hi Joe,

Isn't 29 allocated to RFC 5925? Do you mean 25?

My thinking is that right now we have enough option numbers to avoid the ones for which unauthorized use has been reported. While we clearly do not accept unauthorized use of option numbers, the IETF should probably not create known interop issues as long as this can be avoided, imho. We may indeed have to discuss this question at some point in future, e.g., when more than 50% of the codepoints are allocated. But I am not sure whether this will ever happen in the foreseeable future.

Michael

________________________________________
Von: Joe Touch [[email-masked]]
Gesendet: Donnerstag, 2. Oktober 2014 00:19
An: Scharf, Michael (Michael); [email-masked]
Cc: [email-masked]
Betreff: Re: [tcpm] TCP option kind number for TCP Fast Open

Hi, Michael,

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Oct 2014 16:05:13 -0700

> Isn't 29 allocated to RFC 5925? Do you mean 25?

Yup.

> My thinking is that right now we have enough option numbers to avoid
> the ones for which unauthorized use has been reported.

It might be useful to consider that use. TCPCT was only in a draft, and
the final code ended up using 253.

And 25 was returned for reuse.

> While we clearly
> do not accept unauthorized use of option numbers, the IETF should
> probably not create known interop issues as long as this can be avoided,
> imho. We may indeed have to discuss this question at some point in
> future, e.g., when more than 50% of the codepoints are allocated. But I
> am not sure whether this will ever happen in the foreseeable future.

I disagree, if only because it makes it even more attractive to
squatters to claim we'll do this.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 2 Oct 2014 08:02:30 +0000

> squatters to claim we'll do this.

If we assign codepoints with known unauthorized use (even if we suspect that the number may not be that widely used) to protocols developed by TCPM, we may also make it more attractive for protocol implementers to avoid the IETF standardization process. I don't think causing interop issues on purpose is the right incentive for those implementers that follow our process.

Michael