Re: [tcpm] TCP option kind number for TCP Fast Open
Joe Touch <touch@isi.edu> Wed, 01 October 2014 23:05 UTC
Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E241A883C for <tcpm@ietfa.amsl.com>; Wed, 1 Oct 2014 16:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJfLc9hz9ehX for <tcpm@ietfa.amsl.com>; Wed, 1 Oct 2014 16:05:20 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C861A883A for <tcpm@ietf.org>; Wed, 1 Oct 2014 16:05:20 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s91N5CaT018252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 16:05:12 -0700 (PDT)
Message-ID: <542C88A9.8020805@isi.edu>
Date: Wed, 01 Oct 2014 16:05:13 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <655C07320163294895BBADA28372AF5D1663EADD@FR712WXCHMBA13.zeu.alcatel-lucent.com>, <542C7E04.1080003@isi.edu> <655C07320163294895BBADA28372AF5D1664DF83@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D1664DF83@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nmYzZm2k2hoIj1Kpyw_bR9po_r8
Cc: "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>
Subject: Re: [tcpm] TCP option kind number for TCP Fast Open
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Oct 2014 23:05:22 -0000
On 10/1/2014 3:59 PM, Scharf, Michael (Michael) wrote: > Hi Joe, > > 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 > > Michael > > > ________________________________________ > Von: Joe Touch [touch@isi.edu] > Gesendet: Donnerstag, 2. Oktober 2014 00:19 > An: Scharf, Michael (Michael); tcpm@ietf.org > Cc: tcpm-chairs@tools.ietf.org > Betreff: 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 >>
- [tcpm] TCP option kind number for TCP Fast Open Scharf, Michael (Michael)
- Re: [tcpm] TCP option kind number for TCP Fast Op… Joe Touch
- Re: [tcpm] TCP option kind number for TCP Fast Op… Scharf, Michael (Michael)
- Re: [tcpm] TCP option kind number for TCP Fast Op… Joe Touch
- Re: [tcpm] TCP option kind number for TCP Fast Op… Scharf, Michael (Michael)