From nobody Wed Oct 1 08:26:49 2014 Return-Path: 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 60C371ACE40 for ; Wed, 1 Oct 2014 08:26:47 -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 WiYiK-pW7s4i for ; Wed, 1 Oct 2014 08:26:45 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561FE1ACE37 for ; Wed, 1 Oct 2014 08:26:45 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C7400CF69FEA1; Wed, 1 Oct 2014 15:26:39 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s91FQfmf029491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 17:26:41 +0200 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.168]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 17:26:41 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCP option kind number for TCP Fast Open Thread-Index: AQHP3YwZrmMIXZ4VDES0k1p4A2Qfmw== Date: Wed, 1 Oct 2014 15:26:41 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1663EADD@FR712WXCHMBA13.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JZ6waaGjoVsBBX-34ZSnlOxYPYs Cc: "tcpm-chairs@tools.ietf.org" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:26:47 -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.ia= na.org/assignments/tcp-parameters/tcp-parameters.xhtml. If there are suggestions that another value would be more appropriate, plea= se speak up ASAP.=20 Best regards Michael -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Th= e 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-t= cpm-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=20 concluded that the document had no substantive issues. Personnel The Document Shepherd is Michael Scharf . The Responsible Area Director is Martin Stiemerling . From nobody Wed Oct 1 15:20:17 2014 Return-Path: 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 BA8551A87C7 for ; Wed, 1 Oct 2014 15:20:14 -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 9Ds0fyFwxS-U for ; Wed, 1 Oct 2014 15:20:13 -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 E99151A87C1 for ; Wed, 1 Oct 2014 15:20:12 -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 s91MJl2o009764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 15:19:47 -0700 (PDT) Message-ID: <542C7E04.1080003@isi.edu> Date: Wed, 01 Oct 2014 15:19:48 -0700 From: Joe Touch 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)" , "tcpm@ietf.org" References: <655C07320163294895BBADA28372AF5D1663EADD@FR712WXCHMBA13.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1663EADD@FR712WXCHMBA13.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/AtYEa9WNpXvv6FSrkLyI8AYUH4E Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:20:14 -0000 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 > . The Responsible Area Director > is Martin Stiemerling . > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Oct 1 15:59:12 2014 Return-Path: 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 31DEF1A87DE for ; Wed, 1 Oct 2014 15:59:10 -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 rRy3FGxmtzBZ for ; Wed, 1 Oct 2014 15:59:07 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A031A87AC for ; Wed, 1 Oct 2014 15:59:07 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C41E8FEAA3562; Wed, 1 Oct 2014 22:59:01 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s91Mx6cv022208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 00:59:06 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 00:59:06 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] TCP option kind number for TCP Fast Open Thread-Index: AQHP3YwZrmMIXZ4VDES0k1p4A2Qfm5wbrwAAgAAn+hE= Date: Wed, 1 Oct 2014 22:59:05 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1664DF83@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1663EADD@FR712WXCHMBA13.zeu.alcatel-lucent.com>, <542C7E04.1080003@isi.edu> In-Reply-To: <542C7E04.1080003@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.144.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EZ2jx4Om6xIjIc4pvZNLvnMbhrc Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:59:10 -0000 Hi Joe,=0A= =0A= Isn't 29 allocated to RFC 5925? Do you mean 25?=0A= =0A= My thinking is that right now we have enough option numbers to avoid the on= es for which unauthorized use has been reported. While we clearly do not ac= cept unauthorized use of option numbers, the IETF should probably not creat= e 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 e= ver happen in the foreseeable future.=0A= =0A= Michael=0A= =0A= =0A= ________________________________________=0A= Von: Joe Touch [touch@isi.edu]=0A= Gesendet: Donnerstag, 2. Oktober 2014 00:19=0A= An: Scharf, Michael (Michael); tcpm@ietf.org=0A= Cc: tcpm-chairs@tools.ietf.org=0A= Betreff: Re: [tcpm] TCP option kind number for TCP Fast Open=0A= =0A= Hi, Michael,=0A= =0A= 29 is unassigned and available.=0A= =0A= Also, IMO, we should not shy away from using numbers that others are=0A= squatting on. E.g., 31-31 was only used by TCPCT in Internet Drafts;=0A= when it was released, it was implemented using 253 and AFAICT only in=0A= Linux versions that have since been cleaned up.=0A= =0A= Joe=0A= =0A= On 10/1/2014 8:26 AM, Scharf, Michael (Michael) wrote:=0A= > Hi all,=0A= >=0A= > According to TCPM consensus, the plan is to allocate TCP option kind numb= er 34 for TCP fast open. This number is "reserved" according to http://www.= iana.org/assignments/tcp-parameters/tcp-parameters.xhtml.=0A= >=0A= > If there are suggestions that another value would be more appropriate, pl= ease speak up ASAP.=0A= >=0A= > Best regards=0A= >=0A= > Michael=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of = The IESG=0A= > Sent: Tuesday, September 30, 2014 11:36 PM=0A= > To: IETF-Announce=0A= > Cc: tcpm chair; tcpm mailing list; RFC Editor=0A= > Subject: Document Action: 'TCP Fast Open' to Experimental RFC (draft-ietf= -tcpm-fastopen-10.txt)=0A= >=0A= > The IESG has approved the following document:=0A= > - 'TCP Fast Open'=0A= > (draft-ietf-tcpm-fastopen-10.txt) as Experimental RFC=0A= >=0A= > This document is the product of the TCP Maintenance and Minor Extensions= =0A= > Working Group.=0A= >=0A= > The IESG contact persons are Martin Stiemerling and Spencer Dawkins.=0A= >=0A= > A URL of this Internet Draft is:=0A= > http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > Technical Summary=0A= >=0A= > This document describes an experimental TCP mechanism TCP Fast Open=0A= > (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets=0A= > and consumed by the receiving end during the initial connection=0A= > handshake, thus saving up to one full round trip time (RTT)=0A= > compared to the standard TCP, which requires a three-way handshake=0A= > (3WHS) to complete before data can be exchanged. However TFO=0A= > deviates from the standard TCP semantics since the data in the SYN=0A= > could be replayed to an application in some rare=0A= > circumstances. Applications should not use TFO unless they can=0A= > tolerate this issue detailed in the Applicability section.=0A= >=0A= > Working Group Summary=0A= >=0A= > This document was extensively discussed and reviewed by the TCPM=0A= > working group and there is strong support to publish the=0A= > document. While being an experimental document, the TCPM working=0A= > group decided to ask IESG for approving an IANA allocation of a new=0A= > TCP option codepoint.=0A= >=0A= > Document Quality=0A= >=0A= > The protocol extension described in this document is implemented and=0A= > deployed in the Linux TCP/IP stack, and it is supported by the Chrome= =0A= > Web browser and all Google servers. Experimental results have been=0A= > discussed in the TCPM working group. An early SECDIR review=0A= > concluded that the document had no substantive issues.=0A= >=0A= > Personnel=0A= >=0A= > The Document Shepherd is Michael Scharf=0A= > . The Responsible Area Director=0A= > is Martin Stiemerling .=0A= >=0A= >=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= From nobody Wed Oct 1 16:05:25 2014 Return-Path: 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 ; 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 ; 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 ; 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 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)" , "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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> . The Responsible Area Director >> is Martin Stiemerling . >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From nobody Wed Oct 1 17:43:00 2014 Return-Path: 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 3048C1A8855 for ; Wed, 1 Oct 2014 17:42:59 -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 S6_sStSyKc4H for ; Wed, 1 Oct 2014 17:42:58 -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 F2B4F1A8851 for ; Wed, 1 Oct 2014 17:42:57 -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 s920gn00004631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Oct 2014 17:42:49 -0700 (PDT) Message-ID: <542C9F8B.8020908@isi.edu> Date: Wed, 01 Oct 2014 17:42:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140930061026.13961.61916.idtracker@ietfa.amsl.com> In-Reply-To: <20140930061026.13961.61916.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140930061026.13961.61916.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 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/54J1nqt1uibOhOykjxKC95MJ0o8 Subject: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 00:42:59 -0000 Hi, all, The WG version of draft-touch-tcpm-tcp-edo-03 has been published as draft-ietf-tcpm-tcp-edo-00.txt It includes the following change in response to the call for WG adoption: - extended discussion of middlebox interactions (see Sec 6) Other modifications were limited to language, notation, or references. Joe -------- Original Message -------- Subject: New Version Notification for draft-ietf-tcpm-tcp-edo-00.txt Date: Mon, 29 Sep 2014 23:10:26 -0700 From: internet-drafts@ietf.org To: Wesley M. Eddy , Dr. Joseph D. Touch , Joe Touch , Wesley Eddy A new version of I-D, draft-ietf-tcpm-tcp-edo-00.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-ietf-tcpm-tcp-edo Revision: 00 Title: TCP Extended Data Offset Option Document date: 2014-09-29 Group: tcpm Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-edo-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ Htmlized: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-00 Abstract: TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options such as SACK with either TCP Multipath or TCP AO. It also explains why the initial SYN of a connection cannot be extending as a single segment. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Oct 2 01:02:36 2014 Return-Path: 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 D5E021A0169 for ; Thu, 2 Oct 2014 01:02:34 -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 HfXZ9ghfW-Jy for ; Thu, 2 Oct 2014 01:02:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573271A016D for ; Thu, 2 Oct 2014 01:02:33 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 58B8140AEB26; Thu, 2 Oct 2014 08:02:30 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9282TNa005864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 10:02:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 10:02:30 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] TCP option kind number for TCP Fast Open Thread-Index: AQHP3YwZrmMIXZ4VDES0k1p4A2Qfm5wbrwAAgAAn+hH//+S2gIAAtLlw Date: Thu, 2 Oct 2014 08:02:30 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1665214E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D1663EADD@FR712WXCHMBA13.zeu.alcatel-lucent.com>, <542C7E04.1080003@isi.edu> <655C07320163294895BBADA28372AF5D1664DF83@FR712WXCHMBA15.zeu.alcatel-lucent.com> <542C88A9.8020805@isi.edu> In-Reply-To: <542C88A9.8020805@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5qeE2MwIhRIhsGN9WwmBXm9G3Ws Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 08:02:35 -0000 > > 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. >=20 > I disagree, if only because it makes it even more attractive to > squatters to claim we'll do this. If we assign codepoints with known unauthorized use (even if we suspect tha= t the number may not be that widely used) to protocols developed by TCPM, w= e may also make it more attractive for protocol implementers to avoid the I= ETF standardization process. I don't think causing interop issues on purpos= e is the right incentive for those implementers that follow our process. Michael From nobody Thu Oct 2 04:51:09 2014 Return-Path: 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 9DDCA1A1AEB for ; Thu, 2 Oct 2014 04:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 gpEKGfmxZyGF for ; Thu, 2 Oct 2014 04:51:04 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3993C1A1ACE for ; Thu, 2 Oct 2014 04:51:03 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 2 Oct 2014 12:50:56 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 2 Oct 2014 12:51:00 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 2 Oct 2014 12:50:58 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.135.252]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s92Bov3U014372; Thu, 2 Oct 2014 12:50:58 +0100 Message-ID: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 2 Oct 2014 12:50:12 +0100 To: Joe Touch , "Eddy Wesley M. [VZ]" From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YDB3sBAKXErey4v8ze90sfwiNZY Cc: tcpm IETF list Subject: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:51:06 -0000 Joe, Wes, It is known that new TCP options are removed on x% of paths. It is also known that y% of paths are asymmteric Let's assume z% of the TCP-option-removing middleboxes are on the asymmetric part of a path. (x y and z are left as an exercise for the experimenter. I'm offline at the mo, but I know there are papers that give good estimates of x and y at least). Also some middleboxes behave asymmetrically, for instance firewalls have stricter rules for traffic arriving from the public side vs the private side. Such a device might remove unknown TCP options in one direction, but not the other. ==Legend== C = TCP client S = TCP server EDO = EDO delivered !X-EDO-X! = Middlebox removes EDO TCP option Extra-opts = TCP options beyond the Data Offset (preserved) ???!!! = confused or crashes ==Scenarios== 1. EDO not removed from SYN, but middlebox removes EDO from SYN/ACK 1.1 Extra Options on SYN/ACK C -> EDO -> S C <- !X-EDO-X! Extra-opts <- S C ???!!! 1.2 Extra Options on subsequent segment from server C -> EDO -> S C <- !X-EDO-X! <- S ... C <- !X-EDO-X! Extra-opts <- S C ???!!! 2. EDO not removed from SYN or SYN/ACK 2.1 Middlebox removes EDO from subsequent segment from server C -> EDO -> S C <- EDO Extra-opts <- S ... C <- !X-EDO-X! Extra-opts <- S C ???!!! 2.2 Middlebox removes EDO from subsequent segment from client C -> EDO -> S C <- EDO Extra-opts <- S ... C -> Extra-opts !X-EDO-X! -> S ???!!! S ==Commentary== Case #1: The passive opener (server) thinks that the connection supports EDO, so it sends a SYN/ACK confirming this. But before it reaches the client, a middlebox removes unknown TCP options, but forwards the payload unchanged, including the extra TCP options. Without the EDO option, the client believes everything beyond the Data Offset in the SYN/ACK is payload, so it passes both the extra TCP options and the actual payload to the app. Outcome in both cases under #1: TCP delivers corrupt user-data to the client. Case #2: The 3WHS negotiating EDO completes correctly, so both ends correctly think that the connection supports EDO. But later in the connection, a middlebox starts removing unknown TCP options, but continues to forward the payload unchanged. This is probably much less likely than case 1.1, but might be due to a path change, or the behaviour of a middlbox being different for segments with SYN=0. Again, without the EDO option, the receiving end believes everything beyond the Data Offset is payload, so it passes both the extra TCP options and the actual payload to the app. Outcome in case #2.1: TCP delivers corrupt user-data to the client. Outcome in case #2.2: TCP delivers corrupt user-data to the server. ==Implications== I found the above problem when I was working through all the possible problems if I was to integrate EDO with draft-briscoe-tcpm-syn-op-sis (to extend TCP option space on non-SYN packets subsequent to extending space on the SYN). In the light of the above, I won't be integrating EDO with syn-op-sis. I don't think we should introduce anything to TCP with a known risk of delivering corrupt user-data, even if the risk is low. If there were a middlebox behaviour that 'just' blocked the new feature, it would be another matter. But if asymmetry does cause TCP to deliver corrupt data to certain users, the same users will continually experience bizarre and unreliable behaviour - very expensive for customer support people to diagnose. I shall be adding a section to the syn-op-sis draft to define how syn-op-sis can be used to extend the TCP option space on any packet as well as the SYN (it's fairly obvious). I believe it will be immune to the above problem. (Joe, I'll also add an Appendix for the alternative protocol structure I mentioned in response to you not liking the trailer-based structure.) As you know, I was amazed when it was proposed that EDO should go forward for proposed standard. I said in the TCPM meeting that it should be at least experimental, because these days any new TCP options need to be tested against a wide range of middlebox behaviours. With the above problems, I think we should revisit the decision even to adopt EDO. Sorry guys, EDO looked promising, but our job is to ensure TCP continues to be robust. Regards Bob ________________________________________________________________ Bob Briscoe, BT From nobody Thu Oct 2 07:31:22 2014 Return-Path: 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 877101A0275 for ; Thu, 2 Oct 2014 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 lVObJZkz2b3Q for ; Thu, 2 Oct 2014 07:31:18 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5851A026E for ; Thu, 2 Oct 2014 07:31:17 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Oct 2014 15:31:15 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 2 Oct 2014 15:31:15 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 2 Oct 2014 15:31:15 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s92EVDnC015019; Thu, 2 Oct 2014 15:31:13 +0100 Message-ID: <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 2 Oct 2014 15:31:12 +0100 To: "Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]" From: Bob Briscoe In-Reply-To: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa .gov> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aEHjIFozI5cCZSEW7d-VPFRqPV4 Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:31:21 -0000 Wes, I agree that combining EDO with generic middlebox hardening would be nice. However, it's hard to provide a general-purpose middlebox hardening solution for all cases; most generic solutions introduce overhead - complexity, processing or extra round-trip latency - and each case has different sensitivities to different types of overhead. For instance, in the design of MPTCP, there's a 3-way check to protect against asymmetric option removal . It's MPTCP-specific because MPTCP is perceived as more relevant to longer flows, so the extra start-up latency of this 3-way check is less of a concern. Also, if EDO used a 3-way check, it would not be able to extend the option space on any of the 3WHS segments, which would reduce its usefulness. Section 6 of the above MPTCP RFC discusses asymmetric option removal (see Fig 16) and how MPTCP was hardened against it. It is also a useful enumeration of other possible middlebox problems (and how MPTCP was designed to work round them and to work with them). ==Segment Coalescing== A colleague (Phil Eardley) has just pointed out that segment coalescing could be a problem for EDO. I suspect segments in the 3WHS won't get coalesced because there's nothing to coalesce with. But then later segments might be coalesced. If this were the case, it would mean even a 3-way EDO capability negotiation would appear to have worked. But then subsequent segments could end up with a corrupted coalesced payload, with TCP options embedded at regular intervals throughout. Regards Bob At 14:29 02/10/2014, Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] wrote: >Hi Bob, I think there's a generic problem that many options share >of detecting middlebox compatibility issues, and that for some >subset of them (EDO included) those issues could cause corruption of user data. > >This motivates stronger ways to validate segments (e.g. the form of >TCP-AO that's compatible with NAT, with the TCP option flag set ... >possibly with some new unkeyed algorithm). It should be done in >common and not re-invented on a per-option basis IMHO. > > > >-----Original Message----- >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: Thursday, October 02, 2014 7:50 AM >To: Joe Touch; Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] >Cc: tcpm IETF list >Subject: Asymmetric Middleboxes and Extended Data Offset (EDO) > >Joe, Wes, > >It is known that new TCP options are removed on x% of paths. >It is also known that y% of paths are asymmteric Let's assume z% of >the TCP-option-removing middleboxes are on the asymmetric part of a path. > >(x y and z are left as an exercise for the experimenter. I'm offline >at the mo, but I know there are papers that give good estimates of x >and y at least). > >Also some middleboxes behave asymmetrically, for instance firewalls >have stricter rules for traffic arriving from the public side vs the >private side. Such a device might remove unknown TCP options in one >direction, but not the other. > >==Legend== >C = TCP client >S = TCP server >EDO = EDO delivered >!X-EDO-X! = Middlebox removes EDO TCP option >Extra-opts = TCP options beyond the Data Offset (preserved) >???!!! = confused or crashes > >==Scenarios== > >1. EDO not removed from SYN, but middlebox removes EDO from SYN/ACK >1.1 Extra Options on SYN/ACK > > C -> EDO -> S > C <- !X-EDO-X! Extra-opts <- S > C ???!!! > >1.2 Extra Options on subsequent segment from server > > C -> EDO -> S > C <- !X-EDO-X! <- S > ... > C <- !X-EDO-X! Extra-opts <- S > C ???!!! > >2. EDO not removed from SYN or SYN/ACK >2.1 Middlebox removes EDO from subsequent segment from server > > C -> EDO -> S > C <- EDO Extra-opts <- S > ... > C <- !X-EDO-X! Extra-opts <- S > C ???!!! > >2.2 Middlebox removes EDO from subsequent segment from client > > C -> EDO -> S > C <- EDO Extra-opts <- S > ... > C -> Extra-opts !X-EDO-X! -> S > ???!!! S > > >==Commentary== > >Case #1: >The passive opener (server) thinks that the connection supports EDO, >so it sends a SYN/ACK confirming this. But before it reaches the >client, a middlebox removes unknown TCP options, but forwards the >payload unchanged, including the extra TCP options. > >Without the EDO option, the client believes everything beyond the >Data Offset in the SYN/ACK is payload, so it passes both the extra >TCP options and the actual payload to the app. > >Outcome in both cases under #1: > TCP delivers corrupt user-data to the client. > >Case #2: >The 3WHS negotiating EDO completes correctly, so both ends correctly >think that the connection supports EDO. But later in the connection, >a middlebox starts removing unknown TCP options, but continues to >forward the payload unchanged. This is probably much less likely >than case 1.1, but might be due to a path change, or the behaviour >of a middlbox being different for segments with SYN=0. > >Again, without the EDO option, the receiving end believes everything >beyond the Data Offset is payload, so it passes both the extra TCP >options and the actual payload to the app. > >Outcome in case #2.1: > TCP delivers corrupt user-data to the client. >Outcome in case #2.2: > TCP delivers corrupt user-data to the server. > >==Implications== > >I found the above problem when I was working through all the >possible problems if I was to integrate EDO with >draft-briscoe-tcpm-syn-op-sis (to extend TCP option space on non-SYN >packets subsequent to extending space on the SYN). > >In the light of the above, I won't be integrating EDO with >syn-op-sis. I don't think we should introduce anything to TCP with a >known risk of delivering corrupt user-data, even if the risk is low. >If there were a middlebox behaviour that 'just' blocked the new >feature, it would be another matter. But if asymmetry does cause TCP >to deliver corrupt data to certain users, the same users will >continually experience bizarre and unreliable behaviour - very >expensive for customer support people to diagnose. > >I shall be adding a section to the syn-op-sis draft to define how >syn-op-sis can be used to extend the TCP option space on any packet >as well as the SYN (it's fairly obvious). I believe it will be >immune to the above problem. (Joe, I'll also add an Appendix for the >alternative protocol structure I mentioned in response to you not >liking the trailer-based structure.) > >As you know, I was amazed when it was proposed that EDO should go >forward for proposed standard. I said in the TCPM meeting that it >should be at least experimental, because these days any new TCP >options need to be tested against a wide range of middlebox >behaviours. With the above problems, I think we should revisit the >decision even to adopt EDO. > >Sorry guys, EDO looked promising, but our job is to ensure TCP >continues to be robust. > > >Regards > > >Bob > > >________________________________________________________________ >Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From nobody Thu Oct 2 08:02:39 2014 Return-Path: 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 264781A1A58 for ; Thu, 2 Oct 2014 08:02:38 -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 5x1X9ilE9i9C for ; Thu, 2 Oct 2014 08:02:34 -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 B8D5F1A1A0A for ; Thu, 2 Oct 2014 08:02:34 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s92F0tJi004888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 08:00:58 -0700 (PDT) Message-ID: <542D68A8.7020203@isi.edu> Date: Thu, 02 Oct 2014 08:00:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , "Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]" References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> In-Reply-To: <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> 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/tkLEwHPIs0AdxqIiI2C2y3zqykU Cc: tcpm IETF list Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:02:38 -0000 Hi, Bob and Wes (et al.), First, IMO "option-removing" middleboxes ought to be considered broken and fixed. Let's not treat this otherwise on that end. Second, it's trivial to protect against that event by simply: a) not using the EDO space until after the SYN/ACK b) requiring it on every segment once enabled (b) makes EDO robust to erroneous middleboxes, regardless of asymmetry. (a) is required to differentiate asymmetric errors like this and legitimate legacy servers. FWIW, I don't think we need to do anything in the final ACK of the TWHS. We treat it like any other segment - once the option makes it in both directions, removal of the option effectively kills the packet (and terminates the connection). IF this is a significant concern, we can add it to EDO trivially, but I'd like to know how prevalent this is and whether it can be corrected by fixing the error first. However, I don't quite see a way around avoiding SYN/ACK use of any extension unless we pull the same trick with SYN/ACKs we use with SYNs (OOB segment or dual-SYN/ACK). Joe On 10/2/2014 7:31 AM, Bob Briscoe wrote: > Wes, > > I agree that combining EDO with generic middlebox hardening would be > nice. However, it's hard to provide a general-purpose middlebox > hardening solution for all cases; most generic solutions introduce > overhead - complexity, processing or extra round-trip latency - and each > case has different sensitivities to different types of overhead. > > For instance, in the design of MPTCP, there's a 3-way check to protect > against asymmetric option removal > . It's MPTCP-specific > because MPTCP is perceived as more relevant to longer flows, so the > extra start-up latency of this 3-way check is less of a concern. Also, > if EDO used a 3-way check, it would not be able to extend the option > space on any of the 3WHS segments, which would reduce its usefulness. > > Section 6 of the above MPTCP RFC > discusses asymmetric > option removal (see Fig 16) and how MPTCP was hardened against it. It is > also a useful enumeration of other possible middlebox problems (and how > MPTCP was designed to work round them and to work with them). > > > ==Segment Coalescing== > > A colleague (Phil Eardley) has just pointed out that segment coalescing > could be a problem for EDO. I suspect segments in the 3WHS won't get > coalesced because there's nothing to coalesce with. But then later > segments might be coalesced. > > If this were the case, it would mean even a 3-way EDO capability > negotiation would appear to have worked. But then subsequent segments > could end up with a corrupted coalesced payload, with TCP options > embedded at regular intervals throughout. > > Regards > > > Bob > > At 14:29 02/10/2014, Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] wrote: >> Hi Bob, I think there's a generic problem that many options share of >> detecting middlebox compatibility issues, and that for some subset of >> them (EDO included) those issues could cause corruption of user data. >> >> This motivates stronger ways to validate segments (e.g. the form of >> TCP-AO that's compatible with NAT, with the TCP option flag set ... >> possibly with some new unkeyed algorithm). It should be done in >> common and not re-invented on a per-option basis IMHO. >> >> >> >> -----Original Message----- >> From: Bob Briscoe [mailto:bob.briscoe@bt.com] >> Sent: Thursday, October 02, 2014 7:50 AM >> To: Joe Touch; Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] >> Cc: tcpm IETF list >> Subject: Asymmetric Middleboxes and Extended Data Offset (EDO) >> >> Joe, Wes, >> >> It is known that new TCP options are removed on x% of paths. >> It is also known that y% of paths are asymmteric Let's assume z% of >> the TCP-option-removing middleboxes are on the asymmetric part of a path. >> >> (x y and z are left as an exercise for the experimenter. I'm offline >> at the mo, but I know there are papers that give good estimates of x >> and y at least). >> >> Also some middleboxes behave asymmetrically, for instance firewalls >> have stricter rules for traffic arriving from the public side vs the >> private side. Such a device might remove unknown TCP options in one >> direction, but not the other. >> >> ==Legend== >> C = TCP client >> S = TCP server >> EDO = EDO delivered >> !X-EDO-X! = Middlebox removes EDO TCP option >> Extra-opts = TCP options beyond the Data Offset (preserved) >> ???!!! = confused or crashes >> >> ==Scenarios== >> >> 1. EDO not removed from SYN, but middlebox removes EDO from SYN/ACK >> 1.1 Extra Options on SYN/ACK >> >> C -> EDO -> S >> C <- !X-EDO-X! Extra-opts <- S >> C ???!!! >> >> 1.2 Extra Options on subsequent segment from server >> >> C -> EDO -> S >> C <- !X-EDO-X! <- S >> ... >> C <- !X-EDO-X! Extra-opts <- S >> C ???!!! >> >> 2. EDO not removed from SYN or SYN/ACK >> 2.1 Middlebox removes EDO from subsequent segment from server >> >> C -> EDO -> S >> C <- EDO Extra-opts <- S >> ... >> C <- !X-EDO-X! Extra-opts <- S >> C ???!!! >> >> 2.2 Middlebox removes EDO from subsequent segment from client >> >> C -> EDO -> S >> C <- EDO Extra-opts <- S >> ... >> C -> Extra-opts !X-EDO-X! -> S >> ???!!! S >> >> >> ==Commentary== >> >> Case #1: >> The passive opener (server) thinks that the connection supports EDO, >> so it sends a SYN/ACK confirming this. But before it reaches the >> client, a middlebox removes unknown TCP options, but forwards the >> payload unchanged, including the extra TCP options. >> >> Without the EDO option, the client believes everything beyond the Data >> Offset in the SYN/ACK is payload, so it passes both the extra TCP >> options and the actual payload to the app. >> >> Outcome in both cases under #1: >> TCP delivers corrupt user-data to the client. >> >> Case #2: >> The 3WHS negotiating EDO completes correctly, so both ends correctly >> think that the connection supports EDO. But later in the connection, a >> middlebox starts removing unknown TCP options, but continues to >> forward the payload unchanged. This is probably much less likely than >> case 1.1, but might be due to a path change, or the behaviour of a >> middlbox being different for segments with SYN=0. >> >> Again, without the EDO option, the receiving end believes everything >> beyond the Data Offset is payload, so it passes both the extra TCP >> options and the actual payload to the app. >> >> Outcome in case #2.1: >> TCP delivers corrupt user-data to the client. >> Outcome in case #2.2: >> TCP delivers corrupt user-data to the server. >> >> ==Implications== >> >> I found the above problem when I was working through all the possible >> problems if I was to integrate EDO with draft-briscoe-tcpm-syn-op-sis >> (to extend TCP option space on non-SYN packets subsequent to extending >> space on the SYN). >> >> In the light of the above, I won't be integrating EDO with syn-op-sis. >> I don't think we should introduce anything to TCP with a known risk of >> delivering corrupt user-data, even if the risk is low. If there were a >> middlebox behaviour that 'just' blocked the new feature, it would be >> another matter. But if asymmetry does cause TCP to deliver corrupt >> data to certain users, the same users will continually experience >> bizarre and unreliable behaviour - very expensive for customer support >> people to diagnose. >> >> I shall be adding a section to the syn-op-sis draft to define how >> syn-op-sis can be used to extend the TCP option space on any packet as >> well as the SYN (it's fairly obvious). I believe it will be immune to >> the above problem. (Joe, I'll also add an Appendix for the alternative >> protocol structure I mentioned in response to you not liking the >> trailer-based structure.) >> >> As you know, I was amazed when it was proposed that EDO should go >> forward for proposed standard. I said in the TCPM meeting that it >> should be at least experimental, because these days any new TCP >> options need to be tested against a wide range of middlebox >> behaviours. With the above problems, I think we should revisit the >> decision even to adopt EDO. >> >> Sorry guys, EDO looked promising, but our job is to ensure TCP >> continues to be robust. >> >> >> Regards >> >> >> Bob >> >> >> ________________________________________________________________ >> Bob Briscoe, BT > > ________________________________________________________________ > Bob Briscoe, BT From nobody Thu Oct 2 08:07:48 2014 Return-Path: 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 9D7C91A701D for ; Thu, 2 Oct 2014 06:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 gv76T0wB9HrF for ; Thu, 2 Oct 2014 06:29:14 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 758DD1A033B for ; Thu, 2 Oct 2014 06:29:14 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (ndjsppt104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 8CBD72D803C; Thu, 2 Oct 2014 08:29:13 -0500 (CDT) Received: from NDJSCHT112.ndc.nasa.gov (ndjscht112-pub.ndc.nasa.gov [198.117.1.212]) by ndjsppt104.ndc.nasa.gov (8.14.7/8.14.7) with ESMTP id s92DTDMB030643; Thu, 2 Oct 2014 08:29:13 -0500 Received: from NDJSMBX103.ndc.nasa.gov ([169.254.5.12]) by NDJSCHT112.ndc.nasa.gov ([198.117.1.212]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 08:29:13 -0500 From: "Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.]" To: Bob Briscoe , Joe Touch Thread-Topic: Asymmetric Middleboxes and Extended Data Offset (EDO) Thread-Index: AQHP3jcm1KRRIqkkIkW51RI53x6FDJwcyHmQ Date: Thu, 2 Oct 2014 13:29:12 +0000 Message-ID: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> In-Reply-To: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.88.97.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-02_04:2014-10-02,2014-10-02,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pAMDXtZJuy2d8j2t6KZdAg8y9yI X-Mailman-Approved-At: Thu, 02 Oct 2014 08:07:45 -0700 Cc: tcpm IETF list Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:29:16 -0000 Hi Bob, I think there's a generic problem that many options share of detec= ting middlebox compatibility issues, and that for some subset of them (EDO = included) those issues could cause corruption of user data. This motivates stronger ways to validate segments (e.g. the form of TCP-AO = that's compatible with NAT, with the TCP option flag set ... possibly with = some new unkeyed algorithm). It should be done in common and not re-invent= ed on a per-option basis IMHO. -----Original Message----- From: Bob Briscoe [mailto:bob.briscoe@bt.com]=20 Sent: Thursday, October 02, 2014 7:50 AM To: Joe Touch; Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] Cc: tcpm IETF list Subject: Asymmetric Middleboxes and Extended Data Offset (EDO) Joe, Wes, It is known that new TCP options are removed on x% of paths. It is also known that y% of paths are asymmteric Let's assume z% of the TCP= -option-removing middleboxes are on the asymmetric part of a path. (x y and z are left as an exercise for the experimenter. I'm offline at the= mo, but I know there are papers that give good estimates of x and y at lea= st). Also some middleboxes behave asymmetrically, for instance firewalls have st= ricter rules for traffic arriving from the public side vs the private side.= Such a device might remove unknown TCP options in one direction, but not t= he other. =3D=3DLegend=3D=3D C =3D TCP client S =3D TCP server EDO =3D EDO delivered !X-EDO-X! =3D Middlebox removes EDO TCP option Extra-opts =3D TCP options beyond the Data Offset (preserved) ???!!! =3D confused or crashes =3D=3DScenarios=3D=3D 1. EDO not removed from SYN, but middlebox removes EDO from SYN/ACK 1.1 Extra Options on SYN/ACK C -> EDO -> S C <- !X-EDO-X! Extra-opts <- S C ???!!! 1.2 Extra Options on subsequent segment from server C -> EDO -> S C <- !X-EDO-X! <- S ... C <- !X-EDO-X! Extra-opts <- S C ???!!! 2. EDO not removed from SYN or SYN/ACK 2.1 Middlebox removes EDO from subsequent segment from server C -> EDO -> S C <- EDO Extra-opts <- S ... C <- !X-EDO-X! Extra-opts <- S C ???!!! 2.2 Middlebox removes EDO from subsequent segment from client C -> EDO -> S C <- EDO Extra-opts <- S ... C -> Extra-opts !X-EDO-X! -> S ???!!! S =3D=3DCommentary=3D=3D Case #1: The passive opener (server) thinks that the connection supports EDO, so it = sends a SYN/ACK confirming this. But before it reaches the client, a middle= box removes unknown TCP options, but forwards the payload unchanged, includ= ing the extra TCP options. Without the EDO option, the client believes everything beyond the Data Offs= et in the SYN/ACK is payload, so it passes both the extra TCP options and t= he actual payload to the app.=20 Outcome in both cases under #1:=20 TCP delivers corrupt user-data to the client. Case #2: The 3WHS negotiating EDO completes correctly, so both ends correctly think = that the connection supports EDO. But later in the connection, a middlebox = starts removing unknown TCP options, but continues to forward the payload u= nchanged. This is probably much less likely than case 1.1, but might be due= to a path change, or the behaviour of a middlbox being different for segme= nts with SYN=3D0. Again, without the EDO option, the receiving end believes everything beyond= the Data Offset is payload, so it passes both the extra TCP options and th= e actual payload to the app.=20 Outcome in case #2.1:=20 TCP delivers corrupt user-data to the client. Outcome in case #2.2:=20 TCP delivers corrupt user-data to the server. =3D=3DImplications=3D=3D I found the above problem when I was working through all the possible probl= ems if I was to integrate EDO with draft-briscoe-tcpm-syn-op-sis (to extend= TCP option space on non-SYN packets subsequent to extending space on the S= YN). In the light of the above, I won't be integrating EDO with syn-op-sis. I do= n't think we should introduce anything to TCP with a known risk of deliveri= ng corrupt user-data, even if the risk is low. If there were a middlebox be= haviour that 'just' blocked the new feature, it would be another matter. Bu= t if asymmetry does cause TCP to deliver corrupt data to certain users, the= same users will continually experience bizarre and unreliable behaviour - = very expensive for customer support people to diagnose. I shall be adding a section to the syn-op-sis draft to define how syn-op-si= s can be used to extend the TCP option space on any packet as well as the S= YN (it's fairly obvious). I believe it will be immune to the above problem.= (Joe, I'll also add an Appendix for the alternative protocol structure I m= entioned in response to you not liking the trailer-based structure.) As you know, I was amazed when it was proposed that EDO should go forward f= or proposed standard. I said in the TCPM meeting that it should be at least= experimental, because these days any new TCP options need to be tested aga= inst a wide range of middlebox behaviours. With the above problems, I think= we should revisit the decision even to adopt EDO. Sorry guys, EDO looked promising, but our job is to ensure TCP continues to= be robust.=20 Regards Bob ________________________________________________________________ Bob Briscoe, BT=20 From nobody Thu Oct 2 08:29:00 2014 Return-Path: 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 B8F9D1A1A0A for ; Thu, 2 Oct 2014 08:28:57 -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 II-eygxxlXKb for ; Thu, 2 Oct 2014 08:28:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373391A19EE for ; Thu, 2 Oct 2014 08:28:56 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2A225F1EB6FE2; Thu, 2 Oct 2014 15:28:51 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s92FSp86002133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 17:28:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 17:28:51 +0200 From: "Scharf, Michael (Michael)" To: John Leslie , Bob Briscoe Thread-Topic: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 Thread-Index: AQHP2N+vAX26V97X60WfyOqHqL1HjJwSDaMAgABPsQCAAK++AIAAUh6AgAmXTAA= Date: Thu, 2 Oct 2014 15:28:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16655B47@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> In-Reply-To: <20140926145037.GA82183@verdi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/F12PMVHJ6bVqtOiOsp-cMNBnKVU Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:28:57 -0000 > I believe that much deserves to be settled _before_ tcpm-fastopen > is published as an RFC. (NB that document currently has been approved > for publication, but is waiting on a Point-Raised writeup.) I don't think that this (good!) discussion should affect draft-ietf-tcpm-fa= stopen. We explicitly decided that the existing TCP fast open spec shall be= experimental. I think this kind of discussion can be sorted out if / once we move fast op= en to PS. This almost certainly won't happen within quite a number of IETF = meetings. Thus, we probably have enough time to fully understand and discus= s the interaction with SYN option extension solutions. Michael From nobody Thu Oct 2 09:15:26 2014 Return-Path: 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 50B661A8784 for ; Thu, 2 Oct 2014 09:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 n6y47hSWDclK for ; Thu, 2 Oct 2014 09:15:04 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A161A87B0 for ; Thu, 2 Oct 2014 09:14:59 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 2 Oct 2014 17:14:57 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 2 Oct 2014 17:14:56 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Thu, 2 Oct 2014 17:14:52 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s92GEowA015383; Thu, 2 Oct 2014 17:14:50 +0100 Message-ID: <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 2 Oct 2014 17:14:49 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <542D68A8.7020203@isi.edu> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1caLouFDWOFM6pWI0WAHx0bX4Fk Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:15:13 -0000 Joe, At 16:00 02/10/2014, Joe Touch wrote: >Hi, Bob and Wes (et al.), > >First, IMO "option-removing" middleboxes ought to be considered broken >and fixed. Let's not treat this otherwise on that end. It is our job to make the IETF's protocols robust against attack - at least against low cost attacks. If our protocols can be corrupted by simple middlebox behaviours that we already know about, they will certainly not be robust against deliberate attacks. One can think of an erroneous middlebox as an attack on users by a company intent on profiting while complying with just enough of the protocols to make their product saleable. Saying such behaviour "ought to be fixed" is equivalent to saying "self-interest ought to be fixed". It is also similar to saying "attackers ought not to be self-interested, so we shouldn't have to secure our protocols". >Second, it's trivial to protect against that event by simply: > > a) not using the EDO space until after the SYN/ACK > b) requiring it on every segment once enabled > >(b) makes EDO robust to erroneous middleboxes, regardless of asymmetry. > >(a) is required to differentiate asymmetric errors like this and >legitimate legacy servers. > >FWIW, I don't think we need to do anything in the final ACK of the TWHS. >We treat it like any other segment - once the option makes it in both >directions, removal of the option effectively kills the packet (and >terminates the connection). Correct. >IF this is a significant concern, we can add it to EDO trivially, but >I'd like to know how prevalent this is and whether it can be corrected >by fixing the error first. > >However, I don't quite see a way around avoiding SYN/ACK use of any >extension unless we pull the same trick with SYN/ACKs we use with SYNs >(OOB segment or dual-SYN/ACK). And what about the second part of my email on segment coalescing? That's much tougher, and probably much more prevalent than asymmetric middlebox behaviour. I've had the core of an idea on how we can detect coalescing when extending option space beyond the initial SYN. It's based on the non-deterministic option structure within the payload that I used in syn-op-sis. I'll think it through further before I claim it might work (bearing in mind option space extension is beyond my day-job). Cheers Bob >Joe > >On 10/2/2014 7:31 AM, Bob Briscoe wrote: > > Wes, > > > > I agree that combining EDO with generic middlebox hardening would be > > nice. However, it's hard to provide a general-purpose middlebox > > hardening solution for all cases; most generic solutions introduce > > overhead - complexity, processing or extra round-trip latency - and each > > case has different sensitivities to different types of overhead. > > > > For instance, in the design of MPTCP, there's a 3-way check to protect > > against asymmetric option removal > > . It's MPTCP-specific > > because MPTCP is perceived as more relevant to longer flows, so the > > extra start-up latency of this 3-way check is less of a concern. Also, > > if EDO used a 3-way check, it would not be able to extend the option > > space on any of the 3WHS segments, which would reduce its usefulness. > > > > Section 6 of the above MPTCP RFC > > discusses asymmetric > > option removal (see Fig 16) and how MPTCP was hardened against it. It is > > also a useful enumeration of other possible middlebox problems (and how > > MPTCP was designed to work round them and to work with them). > > > > > > ==Segment Coalescing== > > > > A colleague (Phil Eardley) has just pointed out that segment coalescing > > could be a problem for EDO. I suspect segments in the 3WHS won't get > > coalesced because there's nothing to coalesce with. But then later > > segments might be coalesced. > > > > If this were the case, it would mean even a 3-way EDO capability > > negotiation would appear to have worked. But then subsequent segments > > could end up with a corrupted coalesced payload, with TCP options > > embedded at regular intervals throughout. > > > > Regards > > > > > > Bob > > > > At 14:29 02/10/2014, Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] wrote: > >> Hi Bob, I think there's a generic problem that many options share of > >> detecting middlebox compatibility issues, and that for some subset of > >> them (EDO included) those issues could cause corruption of user data. > >> > >> This motivates stronger ways to validate segments (e.g. the form of > >> TCP-AO that's compatible with NAT, with the TCP option flag set ... > >> possibly with some new unkeyed algorithm). It should be done in > >> common and not re-invented on a per-option basis IMHO. > >> > >> > >> > >> -----Original Message----- > >> From: Bob Briscoe [mailto:bob.briscoe@bt.com] > >> Sent: Thursday, October 02, 2014 7:50 AM > >> To: Joe Touch; Eddy, Wesley M. (GRC-LCI0)[MTI SYSTEMS, INC.] > >> Cc: tcpm IETF list > >> Subject: Asymmetric Middleboxes and Extended Data Offset (EDO) > >> > >> Joe, Wes, > >> > >> It is known that new TCP options are removed on x% of paths. > >> It is also known that y% of paths are asymmteric Let's assume z% of > >> the TCP-option-removing middleboxes are on the asymmetric part of a path. > >> > >> (x y and z are left as an exercise for the experimenter. I'm offline > >> at the mo, but I know there are papers that give good estimates of x > >> and y at least). > >> > >> Also some middleboxes behave asymmetrically, for instance firewalls > >> have stricter rules for traffic arriving from the public side vs the > >> private side. Such a device might remove unknown TCP options in one > >> direction, but not the other. > >> > >> ==Legend== > >> C = TCP client > >> S = TCP server > >> EDO = EDO delivered > >> !X-EDO-X! = Middlebox removes EDO TCP option > >> Extra-opts = TCP options beyond the Data Offset (preserved) > >> ???!!! = confused or crashes > >> > >> ==Scenarios== > >> > >> 1. EDO not removed from SYN, but middlebox removes EDO from SYN/ACK > >> 1.1 Extra Options on SYN/ACK > >> > >> C -> EDO -> S > >> C <- !X-EDO-X! Extra-opts <- S > >> C ???!!! > >> > >> 1.2 Extra Options on subsequent segment from server > >> > >> C -> EDO -> S > >> C <- !X-EDO-X! <- S > >> ... > >> C <- !X-EDO-X! Extra-opts <- S > >> C ???!!! > >> > >> 2. EDO not removed from SYN or SYN/ACK > >> 2.1 Middlebox removes EDO from subsequent segment from server > >> > >> C -> EDO -> S > >> C <- EDO Extra-opts <- S > >> ... > >> C <- !X-EDO-X! Extra-opts <- S > >> C ???!!! > >> > >> 2.2 Middlebox removes EDO from subsequent segment from client > >> > >> C -> EDO -> S > >> C <- EDO Extra-opts <- S > >> ... > >> C -> Extra-opts !X-EDO-X! -> S > >> ???!!! S > >> > >> > >> ==Commentary== > >> > >> Case #1: > >> The passive opener (server) thinks that the connection supports EDO, > >> so it sends a SYN/ACK confirming this. But before it reaches the > >> client, a middlebox removes unknown TCP options, but forwards the > >> payload unchanged, including the extra TCP options. > >> > >> Without the EDO option, the client believes everything beyond the Data > >> Offset in the SYN/ACK is payload, so it passes both the extra TCP > >> options and the actual payload to the app. > >> > >> Outcome in both cases under #1: > >> TCP delivers corrupt user-data to the client. > >> > >> Case #2: > >> The 3WHS negotiating EDO completes correctly, so both ends correctly > >> think that the connection supports EDO. But later in the connection, a > >> middlebox starts removing unknown TCP options, but continues to > >> forward the payload unchanged. This is probably much less likely than > >> case 1.1, but might be due to a path change, or the behaviour of a > >> middlbox being different for segments with SYN=0. > >> > >> Again, without the EDO option, the receiving end believes everything > >> beyond the Data Offset is payload, so it passes both the extra TCP > >> options and the actual payload to the app. > >> > >> Outcome in case #2.1: > >> TCP delivers corrupt user-data to the client. > >> Outcome in case #2.2: > >> TCP delivers corrupt user-data to the server. > >> > >> ==Implications== > >> > >> I found the above problem when I was working through all the possible > >> problems if I was to integrate EDO with draft-briscoe-tcpm-syn-op-sis > >> (to extend TCP option space on non-SYN packets subsequent to extending > >> space on the SYN). > >> > >> In the light of the above, I won't be integrating EDO with syn-op-sis. > >> I don't think we should introduce anything to TCP with a known risk of > >> delivering corrupt user-data, even if the risk is low. If there were a > >> middlebox behaviour that 'just' blocked the new feature, it would be > >> another matter. But if asymmetry does cause TCP to deliver corrupt > >> data to certain users, the same users will continually experience > >> bizarre and unreliable behaviour - very expensive for customer support > >> people to diagnose. > >> > >> I shall be adding a section to the syn-op-sis draft to define how > >> syn-op-sis can be used to extend the TCP option space on any packet as > >> well as the SYN (it's fairly obvious). I believe it will be immune to > >> the above problem. (Joe, I'll also add an Appendix for the alternative > >> protocol structure I mentioned in response to you not liking the > >> trailer-based structure.) > >> > >> As you know, I was amazed when it was proposed that EDO should go > >> forward for proposed standard. I said in the TCPM meeting that it > >> should be at least experimental, because these days any new TCP > >> options need to be tested against a wide range of middlebox > >> behaviours. With the above problems, I think we should revisit the > >> decision even to adopt EDO. > >> > >> Sorry guys, EDO looked promising, but our job is to ensure TCP > >> continues to be robust. > >> > >> > >> Regards > >> > >> > >> Bob > >> > >> > >> ________________________________________________________________ > >> Bob Briscoe, BT > > > > ________________________________________________________________ > > Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From nobody Thu Oct 2 09:26:26 2014 Return-Path: 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 03FCB1A8837 for ; Thu, 2 Oct 2014 09:26:20 -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 cQMnh6PKk8qq for ; Thu, 2 Oct 2014 09:26:12 -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 405831A8838 for ; Thu, 2 Oct 2014 09:26:12 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s92GPktT021423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 09:25:49 -0700 (PDT) Message-ID: <542D7C8B.2050401@isi.edu> Date: Thu, 02 Oct 2014 09:25:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> In-Reply-To: <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> 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/Es0WFox6XpFUV9T4tT4hj0NCK_U Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:26:20 -0000 On 10/2/2014 9:14 AM, Bob Briscoe wrote: > Joe, > > At 16:00 02/10/2014, Joe Touch wrote: >> Hi, Bob and Wes (et al.), >> >> First, IMO "option-removing" middleboxes ought to be considered broken >> and fixed. Let's not treat this otherwise on that end. > > It is our job to make the IETF's protocols robust against attack - at > least against low cost attacks. If our protocols can be corrupted by > simple middlebox behaviours that we already know about, they will > certainly not be robust against deliberate attacks. None of our protocols is robust in this way except those that add authentication. It isn't useful to try to build non-authentication extensions to be robust to those sorts of attacks - those extensions need to be compatible with real security protection (which they are). > One can think of an erroneous middlebox as an attack on users by a > company intent on profiting while complying with just enough of the > protocols to make their product saleable. That's a fine game, but it ends up backfiring. There were a half-dozen companies in the late 1990s that violated TCP rules to "accelerate" transfers. Customers found out what was going on and they're no longer in business. > Saying such behaviour "ought to be fixed" is equivalent to saying > "self-interest ought to be fixed". It is also similar to saying > "attackers ought not to be self-interested, so we shouldn't have to > secure our protocols". I'm saying that bugs should be treated as such. None of our non-security protocols are designed to be robust to byzantine attacks. >> Second, it's trivial to protect against that event by simply: >> >> a) not using the EDO space until after the SYN/ACK >> b) requiring it on every segment once enabled >> >> (b) makes EDO robust to erroneous middleboxes, regardless of asymmetry. >> >> (a) is required to differentiate asymmetric errors like this and >> legitimate legacy servers. >> >> FWIW, I don't think we need to do anything in the final ACK of the TWHS. >> We treat it like any other segment - once the option makes it in both >> directions, removal of the option effectively kills the packet (and >> terminates the connection). > > Correct. > >> IF this is a significant concern, we can add it to EDO trivially, but >> I'd like to know how prevalent this is and whether it can be corrected >> by fixing the error first. >> >> However, I don't quite see a way around avoiding SYN/ACK use of any >> extension unless we pull the same trick with SYN/ACKs we use with SYNs >> (OOB segment or dual-SYN/ACK). > > And what about the second part of my email on segment coalescing? That's > much tougher, and probably much more prevalent than asymmetric middlebox > behaviour. Yes, but we're talking about segment coalescing where the middlebox deliberately copies options it doesn't understand. That's a recipe for disaster for options anyway. Yes, we need to understand how prevalent that is and whether to recommend existing methods that would either prevent (cause to fail) or detect such rewriting, but I don't think it's useful to build that into each option. Joe From nobody Thu Oct 2 17:57:36 2014 Return-Path: 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 8A9C31ACFBA for ; Thu, 2 Oct 2014 17:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 CpVD2cN6K83U for ; Thu, 2 Oct 2014 17:57:32 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790FE1ACFAE for ; Thu, 2 Oct 2014 17:57:32 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 3 Oct 2014 01:57:30 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 3 Oct 2014 01:57:29 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Fri, 3 Oct 2014 01:57:28 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.43]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s930vQAu017004; Fri, 3 Oct 2014 01:57:26 +0100 Message-ID: <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 3 Oct 2014 01:57:25 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <542D7C8B.2050401@isi.edu> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aCXlAHPvsHcK2hhziqEBSKagjAs Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 00:57:35 -0000 Joe, At 17:25 02/10/2014, Joe Touch wrote: >On 10/2/2014 9:14 AM, Bob Briscoe wrote: > > Joe, > > > > At 16:00 02/10/2014, Joe Touch wrote: > >> Hi, Bob and Wes (et al.), > >> > >> First, IMO "option-removing" middleboxes ought to be considerd broken > >> and fixed. Let's not treat this otherwise on that end. > > > > It is our job to make the IETF's protocols robust against attack - at > > least against low cost attacks. If our protocols can be corrupted by > > simple middlebox behaviours that we already know about, they will > > certainly not be robust against deliberate attacks. > >None of our protocols is robust in this way except those that add >authentication. It isn't useful to try to build non-authentication >extensions to be robust to those sorts of attacks So you are saying that the 'trivial' protection you added to EDO was not useful, even tho it solved the problem? 1) Altho carefully designed protocol structure does not address /all possible/ byzantine behaviours, it can harden a protocol against most or even all known middlebox behaviours... 2) ...without the overhead of authentication... 3) ...and authentication is not a panacea anyway - an authenticated message proves nothing if it's not delivered - all authentication solutions sit within a broader scheme that has to be /structurally/ secure. >- those extensions >need to be compatible with real security protection (which they are). I think you're using the term 'real security' when you mean cryptography. Security is a much broader art than just cryptography. I recently gave a presentation about the overlloked role of structural security. Many security professionals unconsciously allow their attention to stray from any security problems that are not amenable to cryptographic solutions. And they blinker themselves into using crytography as the hammer for every nail to the exclusion of more appropriate techniques. Using protocol structure to protect against the self-interested behaviour of middlebox manufacturers /is/ real security. As your own 'trivial' solution demonstrates. > > One can think of an erroneous middlebox as an attack on users by a > > company intent on profiting while complying with just enough of the > > protocols to make their product saleable. > >That's a fine game, but it ends up backfiring. There were a half-dozen >companies in the late 1990s that violated TCP rules to "accelerate" >transfers. Customers found out what was going on and they're no longer >in business. I think you mean "It ended up backfiring in half-a-dozen cases, and I can't prove why they went bust, but I wish it was because they violated TCP rules". There are dozens, probably hundreds, of companies still making healthy profits out of middleboxes that violate TCP rules. > > Saying such behaviour "ought to be fixed" is equivalent to saying > > "self-interest ought to be fixed". It is also similar to saying > > "attackers ought not to be self-interested, so we shouldn't have to > > secure our protocols". > >I'm saying that bugs should be treated as such. None of our non-security >protocols are designed to be robust to byzantine attacks. In this thread alone, three have been mentioned: - MPTCP - EDO with your recent trivial alteration. - Syn-op-sis > >> Second, it's trivial to protect against that event by simply: > >> > >> a) not using the EDO space until after the SYN/ACK > >> b) requiring it on every segment once enabled > >> > >> (b) makes EDO robust to erroneous middleboxes, regardless of asymmetry. > >> > >> (a) is required to differentiate asymmetric errors like this and > >> legitimate legacy servers. > >> > >> FWIW, I don't think we need to do anything in the final ACK of the TWHS. > >> We treat it like any other segment - once the option makes it in both > >> directions, removal of the option effectively kills the packet (and > >> terminates the connection). > > > > Correct. > > > >> IF this is a significant concern, we can add it to EDO trivially, but > >> I'd like to know how prevalent this is and whether it can be corrected > >> by fixing the error first. > >> > >> However, I don't quite see a way around avoiding SYN/ACK use of any > >> extension unless we pull the same trick with SYN/ACKs we use with SYNs > >> (OOB segment or dual-SYN/ACK). > > > > And what about the second part of my email on segment coalescing? That's > > much tougher, and probably much more prevalent than asymmetric middlebox > > behaviour. > >Yes, but we're talking about segment coalescing where the middlebox >deliberately copies options it doesn't understand. That's a recipe for >disaster for options anyway. > >Yes, we need to understand how prevalent that is and whether to >recommend existing methods that would either prevent (cause to fail) or >detect such rewriting, but I don't think it's useful to build that into >each option. So, for instance, if we added a payload_size field to EDO, would that be 'not useful' for detecting segment coalescing? Should we deny that payload-size is useful and require EDO to use authentication instead? For a minimum protocol, we have to protect against muddle but not meddle. Then, if the implementer chooses, s/he can use authentication to protect against meddle as an optional extra. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Thu Oct 2 18:07:13 2014 Return-Path: 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 BB6A31ACFBC for ; Thu, 2 Oct 2014 18:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aigwLvVi5wVe for ; Thu, 2 Oct 2014 18:07:10 -0700 (PDT) Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id E37C01ACFB7 for ; Thu, 2 Oct 2014 18:07:09 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s93178Js008018 for ; Thu, 2 Oct 2014 21:07:08 -0400 Received: (qmail 7696 invoked by uid 0); 3 Oct 2014 01:07:08 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 3 Oct 2014 01:07:08 -0000 Message-ID: <542DF6BA.6010301@mti-systems.com> Date: Thu, 02 Oct 2014 21:07:06 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , Bob Briscoe References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> In-Reply-To: <542D7C8B.2050401@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/B9LlXbjx1Jx6rSXa4KTREfy5fUI Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:07:11 -0000 On 10/2/2014 12:25 PM, Joe Touch wrote: >> >> And what about the second part of my email on segment coalescing? That's >> much tougher, and probably much more prevalent than asymmetric middlebox >> behaviour. > > Yes, but we're talking about segment coalescing where the middlebox > deliberately copies options it doesn't understand. That's a recipe for > disaster for options anyway. > > Yes, we need to understand how prevalent that is and whether to > recommend existing methods that would either prevent (cause to fail) or > detect such rewriting, but I don't think it's useful to build that into > each option. > Segment coalescing with blind copying of options will definitely be a problem. I assume that's a real behavior someone may do, but haven't actually noticed it. To my knowledge, none of the various RFCs that talk about different middlebox behaviors have a "don't do that" message about this. Sort of like RFC 3360 for RST generation (https://tools.ietf.org/html/rfc3360), maybe a quick list of very harmful option-handling practices would be in order (this would include blind-copy coalescing, asymmetric filtering, and others). -- Wes Eddy MTI Systems From nobody Thu Oct 2 18:11:46 2014 Return-Path: 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 057831A8857 for ; Thu, 2 Oct 2014 18:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 G-FmLmRlSVVa for ; Thu, 2 Oct 2014 18:11:36 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 58E181ACFBC for ; Thu, 2 Oct 2014 18:11:36 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s931BYvN014627 for ; Thu, 2 Oct 2014 21:11:34 -0400 Received: (qmail 10640 invoked by uid 0); 3 Oct 2014 01:11:34 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 3 Oct 2014 01:11:34 -0000 Message-ID: <542DF7C5.1020801@mti-systems.com> Date: Thu, 02 Oct 2014 21:11:33 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , Bob Briscoe References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <542DF6BA.6010301@mti-systems.com> In-Reply-To: <542DF6BA.6010301@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/L9LtXs81i97qP_F_qJ7TUU3XOfI Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:11:39 -0000 On 10/2/2014 9:07 PM, Wesley Eddy wrote: > > Segment coalescing with blind copying of options will definitely be a > problem. I assume that's a real behavior someone may do, but haven't > actually noticed it. > > To my knowledge, none of the various RFCs that talk about different > middlebox behaviors have a "don't do that" message about this. > Sort of like RFC 3360 for RST generation > (https://tools.ietf.org/html/rfc3360), maybe a quick list of very > harmful option-handling practices would be in order (this would include > blind-copy coalescing, asymmetric filtering, and others). > > And, yes, I know that legislating the problem away is not realistic, but it's hard to expect people to implement the correct practices if they aren't written down, or if we don't even necessarily agree on what those correct practices are. It may be easier to say what NOT to do, which we can probably agree on. -- Wes Eddy MTI Systems From nobody Thu Oct 2 18:14:34 2014 Return-Path: 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 BEF521ACFBA for ; Thu, 2 Oct 2014 18:14:31 -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 oeATgpO88Gzv for ; Thu, 2 Oct 2014 18:14:29 -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 03B1E1A8861 for ; Thu, 2 Oct 2014 18:14:25 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s931Do2b010665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 18:13:51 -0700 (PDT) Message-ID: <542DF84E.4020404@isi.edu> Date: Thu, 02 Oct 2014 18:13:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Bob Briscoe References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> In-Reply-To: <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/rbU0tizhrmmfOb_wtpCxBvh3Akg Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:14:31 -0000 On 10/2/2014 5:57 PM, Bob Briscoe wrote: > Joe, > > > At 17:25 02/10/2014, Joe Touch wrote: > > >> On 10/2/2014 9:14 AM, Bob Briscoe wrote: >> > Joe, >> > >> > At 16:00 02/10/2014, Joe Touch wrote: >> >> Hi, Bob and Wes (et al.), >> >> >> >> First, IMO "option-removing" middleboxes ought to be considerd broken >> >> and fixed. Let's not treat this otherwise on that end. >> > >> > It is our job to make the IETF's protocols robust against attack - at >> > least against low cost attacks. If our protocols can be corrupted by >> > simple middlebox behaviours that we already know about, they will >> > certainly not be robust against deliberate attacks. >> >> None of our protocols is robust in this way except those that add >> authentication. It isn't useful to try to build non-authentication >> extensions to be robust to those sorts of attacks > > So you are saying that the 'trivial' protection you added to EDO was not > useful, even tho it solved the problem? It won't prevent the "attack"; it turns the attack into a DOS event. > 1) Altho carefully designed protocol structure does not address /all > possible/ byzantine behaviours, it can harden a protocol against most or > even all known middlebox behaviours... > 2) ...without the overhead of authentication... > 3) ...and authentication is not a panacea anyway - an authenticated > message proves nothing if it's not delivered - all authentication > solutions sit within a broader scheme that has to be /structurally/ secure. I agree it's useful to put in reasonable safeguards, but I don't think we should be designing against byzantine or malicious events. >> - those extensions >> need to be compatible with real security protection (which they are). > > I think you're using the term 'real security' when you mean > cryptography. Security is a much broader art than just cryptography. I was being informal. Cryptography isn't the right term, unless the intent is to hide the packet format from the middlebox. Ultimately, only integrity protection will suffice. > I recently gave a presentation about the overlloked role of structural > security. Many security professionals unconsciously allow their > attention to stray from any security problems that are not amenable to > cryptographic solutions. And they blinker themselves into using > crytography as the hammer for every nail to the exclusion of more > appropriate techniques. > > Using protocol structure to protect against the self-interested > behaviour of middlebox manufacturers /is/ real security. As your own > 'trivial' solution demonstrates. It's not security, IMO. It's error avoidance. >> > One can think of an erroneous middlebox as an attack on users by a >> > company intent on profiting while complying with just enough of the >> > protocols to make their product saleable. >> >> That's a fine game, but it ends up backfiring. There were a half-dozen >> companies in the late 1990s that violated TCP rules to "accelerate" >> transfers. Customers found out what was going on and they're no longer >> in business. > > I think you mean "It ended up backfiring in half-a-dozen cases, and I > can't prove why they went bust, but I wish it was because they violated > TCP rules". They got tarred and feathered for it at the time. Maybe not all of them, but some did. > There are dozens, probably hundreds, of companies still making healthy > profits out of middleboxes that violate TCP rules. > > >> > Saying such behaviour "ought to be fixed" is equivalent to saying >> > "self-interest ought to be fixed". It is also similar to saying >> > "attackers ought not to be self-interested, so we shouldn't have to >> > secure our protocols". >> >> I'm saying that bugs should be treated as such. None of our non-security >> protocols are designed to be robust to byzantine attacks. > > In this thread alone, three have been mentioned: > - MPTCP > - EDO with your recent trivial alteration. > - Syn-op-sis None of them are robust to byzantine attacks, one of which could easily combine the SYN solutions with an inserted TFO that isn't where you think it would be safe. >> >> Second, it's trivial to protect against that event by simply: >> >> >> >> a) not using the EDO space until after the SYN/ACK >> >> b) requiring it on every segment once enabled >> >> >> >> (b) makes EDO robust to erroneous middleboxes, regardless of >> asymmetry. >> >> >> >> (a) is required to differentiate asymmetric errors like this and >> >> legitimate legacy servers. >> >> >> >> FWIW, I don't think we need to do anything in the final ACK of the >> TWHS. >> >> We treat it like any other segment - once the option makes it in both >> >> directions, removal of the option effectively kills the packet (and >> >> terminates the connection). >> > >> > Correct. >> > >> >> IF this is a significant concern, we can add it to EDO trivially, but >> >> I'd like to know how prevalent this is and whether it can be corrected >> >> by fixing the error first. >> >> >> >> However, I don't quite see a way around avoiding SYN/ACK use of any >> >> extension unless we pull the same trick with SYN/ACKs we use with SYNs >> >> (OOB segment or dual-SYN/ACK). >> > >> > And what about the second part of my email on segment coalescing? >> That's >> > much tougher, and probably much more prevalent than asymmetric >> middlebox >> > behaviour. >> >> Yes, but we're talking about segment coalescing where the middlebox >> deliberately copies options it doesn't understand. That's a recipe for >> disaster for options anyway. >> >> Yes, we need to understand how prevalent that is and whether to >> recommend existing methods that would either prevent (cause to fail) or >> detect such rewriting, but I don't think it's useful to build that into >> each option. > > So, for instance, if we added a payload_size field to EDO, would that be > 'not useful' for detecting segment coalescing? Strictly, so would a new TCP option called "the real segment length", so long as the coalescing device didn't know about it. That's what you're basically doing by adding the info to EDO. > Should we deny that > payload-size is useful and require EDO to use authentication instead? If we want to build an option to detect and/or protect against coalescing, fine. But I don't see why we should bundle that in another option. It might be useful for other options besides ours. > For a minimum protocol, we have to protect against muddle but not > meddle. Then, if the implementer chooses, s/he can use authentication to > protect against meddle as an optional extra. I support the idea of an option to detect and/or protect against middleboxes, but again I don't see why we need that bundled with EDO. Joe From nobody Thu Oct 2 18:48:18 2014 Return-Path: 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 B38F01ACFCB for ; Thu, 2 Oct 2014 18:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 aT_3r1345_YU for ; Thu, 2 Oct 2014 18:48:14 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FB91ACFCD for ; Thu, 2 Oct 2014 18:48:13 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 3 Oct 2014 02:48:10 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 3 Oct 2014 02:48:10 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Fri, 3 Oct 2014 02:48:09 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.43]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s931m6YS017276; Fri, 3 Oct 2014 02:48:06 +0100 Message-ID: <201410030148.s931m6YS017276@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 3 Oct 2014 02:48:05 +0100 To: Wesley Eddy From: Bob Briscoe In-Reply-To: <542DF7C5.1020801@mti-systems.com> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <542DF6BA.6010301@mti-systems.com> <542DF7C5.1020801@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/bBLQ-s4KAl6oHtxn8bszAd0P3Ks Cc: "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" , tcpm IETF list , Joe Touch Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 01:48:16 -0000 Wes, Personally, I wouldn't spend time on writing a list of bad practices for an audience that won't read the list. A better way to reach the indended audience is to write how they /should/ do practice X (e.g. segmentation offloading). Then we're producing a spec that is useful for tendering exercises. It then becomes worth these vendors complying, otherwise they cannot win the tenders. Perhaps a 'Requirements for Internet Middleboxes' would also be something that could be tendered against. Rather than listing bad practices, it would give required practice. We (speaking as an operator) could then add this RFC to our template list of RFCs for which compliance is required in all our tenders. Then non-compliance would be punishable by loss of business. Another practice I have started to do in recent drafts I'm involved in is to include directives on required middlebox behaviour (even for an e2e protocol). Example: (search through for 'middlebox') Bob At 02:11 03/10/2014, Wesley Eddy wrote: >On 10/2/2014 9:07 PM, Wesley Eddy wrote: > > > > Segment coalescing with blind copying of options will definitely be a > > problem. I assume that's a real behavior someone may do, but haven't > > actually noticed it. > > > > To my knowledge, none of the various RFCs that talk about different > > middlebox behaviors have a "don't do that" message about this. > > Sort of like RFC 3360 for RST generation > > (https://tools.ietf.org/html/rfc3360), maybe a quick list of very > > harmful option-handling practices would be in order (this would include > > blind-copy coalescing, asymmetric filtering, and others). > > > > > > >And, yes, I know that legislating the problem away is not realistic, >but it's hard to expect people to implement the correct practices if >they aren't written down, or if we don't even necessarily agree on >what those correct practices are. It may be easier to say what NOT >to do, which we can probably agree on. > > >-- >Wes Eddy >MTI Systems ________________________________________________________________ Bob Briscoe, BT From nobody Thu Oct 2 21:13:50 2014 Return-Path: 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 3DE421ACFDB for ; Thu, 2 Oct 2014 21:13:48 -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 Svp2DBb73G4n for ; Thu, 2 Oct 2014 21:13:46 -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 E478A1ACFDA for ; Thu, 2 Oct 2014 21:13:46 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s934DRJ1008171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 21:13:30 -0700 (PDT) Message-ID: <542E2268.90404@isi.edu> Date: Thu, 02 Oct 2014 21:13:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , Wesley Eddy References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <542DF6BA.6010301@mti-systems.com> <542DF7C5.1020801@mti-systems.com> <201410030148.s931m6YS017276@bagheera.jungle.bt.co.uk> In-Reply-To: <201410030148.s931m6YS017276@bagheera.jungle.bt.co.uk> 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/HUxIhlv1lLsEMwWql9CC5zvS8Sk Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 04:13:48 -0000 On 10/2/2014 6:48 PM, Bob Briscoe wrote: > Wes, > > Personally, I wouldn't spend time on writing a list of bad practices for > an audience that won't read the list. > > A better way to reach the indended audience is to write how they > /should/ do practice X (e.g. segmentation offloading). That's easy: If you're not the endpoint, don't modify the segment. Was there something in RFCs 1122 and 1812 that was unclear on this? Everything else we do are "laws for the lawless", or - at best - things that might work today (like segment coalescing) but *will* have unknown consequences for the future (like EDO). There's no real utility in doing that. Joe From nobody Thu Oct 2 21:56:25 2014 Return-Path: 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 2E83B1ACFF3 for ; Thu, 2 Oct 2014 21:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no 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 AlEDG6U1xlHZ for ; Thu, 2 Oct 2014 21:56:22 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB971ACFE0 for ; Thu, 2 Oct 2014 21:56:22 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0B23E2781D0 for ; Fri, 3 Oct 2014 13:56:20 +0900 (JST) Received: by mail-lb0-f182.google.com with SMTP id z11so379877lbi.27 for ; Thu, 02 Oct 2014 21:56:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.35.199 with SMTP id k7mr2892769lbj.76.1412312178121; Thu, 02 Oct 2014 21:56:18 -0700 (PDT) Received: by 10.114.98.39 with HTTP; Thu, 2 Oct 2014 21:56:18 -0700 (PDT) In-Reply-To: <542E2268.90404@isi.edu> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <542DF6BA.6010301@mti-systems.com> <542DF7C5.1020801@mti-systems.com> <201410030148.s931m6YS017276@bagheera.jungle.bt.co.uk> <542E2268.90404@isi.edu> Date: Thu, 2 Oct 2014 21:56:18 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c37286b0641e05047d8dec Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ttn479jg459gP_GUI41qNBi4ees Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 04:56:24 -0000 --001a11c37286b0641e05047d8dec Content-Type: text/plain; charset=UTF-8 On Thu, Oct 2, 2014 at 9:13 PM, Joe Touch wrote: > > > On 10/2/2014 6:48 PM, Bob Briscoe wrote: > > Wes, > > > > Personally, I wouldn't spend time on writing a list of bad practices for > > an audience that won't read the list. > > > > A better way to reach the indended audience is to write how they > > /should/ do practice X (e.g. segmentation offloading). > > That's easy: > > If you're not the endpoint, don't modify the segment. > > Was there something in RFCs 1122 and 1812 that was unclear on this? > > Everything else we do are "laws for the lawless", or - at best - things > that might work today (like segment coalescing) but *will* have unknown > consequences for the future (like EDO). There's no real utility in doing > that. > My concern is it might not be very rare case as we have observed a certain number of middleboxes that coalesce segments. it may look like an ex post facto law. -- Yoshi --001a11c37286b0641e05047d8dec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 2, 2014 at 9:13 PM, Joe Touch <touch@isi.edu> wr= ote:


On 10/2/2014 6:48 PM, Bob Briscoe wrote:
> Wes,
>
> Personally, I wouldn't spend time on writing a list of bad practic= es for
> an audience that won't read the list.
>
> A better way to reach the indended audience is to write how they
> /should/ do practice X (e.g. segmentation offloading).

That's easy:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If you're not the endpoint, don't modif= y the segment.

Was there something in RFCs 1122 and 1812 that was unclear on this?

Everything else we do are "laws for the lawless", or - at best - = things
that might work today (like segment coalescing) but *will* have unknown
consequences for the future (like EDO). There's no real utility in doin= g
that.

My concern is it might not be ver= y rare case as we have observed a certain number of middleboxes that coales= ce segments. it may look like an ex post facto law.
--
= Yoshi
--001a11c37286b0641e05047d8dec-- From nobody Thu Oct 2 22:33:06 2014 Return-Path: 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 0B3631A0079 for ; Thu, 2 Oct 2014 22:33:04 -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 2gDeg1Df12iA for ; Thu, 2 Oct 2014 22:33:01 -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 DC6D81A0074 for ; Thu, 2 Oct 2014 22:33:01 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s935WhLG020167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 22:32:46 -0700 (PDT) Message-ID: <542E34FC.7050303@isi.edu> Date: Thu, 02 Oct 2014 22:32:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <542DF6BA.6010301@mti-systems.com> <542DF7C5.1020801@mti-systems.com> <201410030148.s931m6YS017276@bagheera.jungle.bt.co.uk> <542E2268.90404@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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/jM-rNAuOi7yobHTjCBqbP4z50qw Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 05:33:04 -0000 On 10/2/2014 9:56 PM, Yoshifumi Nishida wrote: > On Thu, Oct 2, 2014 at 9:13 PM, Joe Touch > wrote: > > On 10/2/2014 6:48 PM, Bob Briscoe wrote: > > Wes, > > > > Personally, I wouldn't spend time on writing a list of bad practices for > > an audience that won't read the list. > > > > A better way to reach the indended audience is to write how they > > /should/ do practice X (e.g. segmentation offloading). > > That's easy: > > If you're not the endpoint, don't modify the segment. ... > My concern is it might not be very rare case as we have observed a > certain number of middleboxes that coalesce segments. it may look like > an ex post facto law. The same was true for "nodes that don't speak IP". Let's find them and get them fixed or removed, because they interfere with TCP on many levels (ACK clocking, Nagle if enabled, etc.). Joe From nobody Fri Oct 3 01:00:31 2014 Return-Path: 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 6C1391ACFF3 for ; Fri, 3 Oct 2014 01:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 VUEuA9C_0fzj for ; Fri, 3 Oct 2014 01:00:28 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2151B1A00B8 for ; Fri, 3 Oct 2014 01:00:28 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.22) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5425273600AA229C; Fri, 3 Oct 2014 11:00:13 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <21652_1412250682_542D3C39_21652_326_1_201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> Date: Fri, 3 Oct 2014 11:00:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21652_1412250682_542D3C39_21652_326_1_201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/I8HB3kRdP2JTibP7BDzMwDHed_s Cc: tcpm IETF list , "Wesley M. \(GRC-MS00\)\[Verizon\] Eddy" , Joe Touch Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:00:30 -0000 On 02 Oct 2014, at 14:50, Bob Briscoe wrote: > As you know, I was amazed when it was proposed that EDO should go = forward for proposed standard. I said in the TCPM meeting that it should = be at least experimental, because these days any new TCP options need to = be tested against a wide range of middlebox behaviours. With the above = problems, I think we should revisit the decision even to adopt EDO. I don=92t think we need to make hasty changes to the milestone status at = this time. Things are still evolving, and there may be ways to address = the issues in some acceptable manner. Even if we found a complete = showstopper, I think it would be valuable to publish a RFC to document = what was tried, although obviously the document status would need to be = something different then. For now, I think the middlebox section should document the known failure = scenarios in sufficient detail, for example based on what you wrote in = your mail. - Pasi From nobody Fri Oct 3 04:14:21 2014 Return-Path: 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 85D7E1AD035 for ; Fri, 3 Oct 2014 04:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 w1078Iy2Z7sq for ; Fri, 3 Oct 2014 04:14:15 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266B81A02D6 for ; Fri, 3 Oct 2014 04:14:14 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 3 Oct 2014 12:14:11 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 3 Oct 2014 12:14:10 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Fri, 3 Oct 2014 12:14:10 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.69]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s93BE6Mw019580; Fri, 3 Oct 2014 12:14:07 +0100 Message-ID: <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 3 Oct 2014 12:14:06 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <542DF84E.4020404@isi.edu> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yiuHVnAPqRDN2Nyu1JjvuLOIcAc Cc: tcpm IETF list , "Eddy, Wesley M. \(GRC-LCI0\)\[MTI SYSTEMS, INC.\]" Subject: Re: [tcpm] Asymmetric Middleboxes and Extended Data Offset (EDO) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 11:14:18 -0000 Joe, It might appear as if we still disagree, but that is either due to differences of terminology or differences of preference. This rather adversarial conversation has nonetheless been useful and produced useful insights. We differ on: - whether the field of cryptography excludes integrity checking and authentication - whether the field of security includes measures to protect against self-interested but non-malicious parties - whether self-interested actions are byzantine - for protocol safety, where to draw the line between trivial protocol-specific measures and heavier protocol-independent measures. We agree that: - basic protocols do not need to be designed against malicious or devious adversaries - protection against malice should be made available in additional protocols - it is worth including simple measures in a basic protocol to protect against known or likely behaviour of middleboxes (but we need measures to get them fixed too) - it would be better if a general-purpose protocol were available to detect or even prevent known middlebox behaviours There are three suggested additions to EDO: a) defer extra options until after the SYN/ACK b) require EDO on all segments c) include the payload size in the EDO option - a) and b) together should detect asymmetric (or intermittent) option removal. - c) should detect non-malicious segment coalescing. - Once either of these behaviours is detected, the connection has to abort. - Detection-only solutions turn middlebox corruption into DoS (ie. denying the extended option service). ===Next Steps=== I shall produce an update to syn-op-sis to extend it to all segments of a connection. I believe syn-op-sis has more potential to be enhanced to improve on EDO: - it should enable extra options on the SYN/ACK (ie. all segments). - it already /prevents/ corruption due to option removal - however, I think it will only /detect/ corruption due to coalescing I guess you'll update EDO with whichever of a)b)c) you decide on. We need experiments (including those already written up) to determine how prevalent various middlebox behaviours are. I don't know where this leaves SYN-EOS OOB. It is currently integrated with EDO, but if EDO defers extra option until after the SYN/ACK, then OOB + EDO together will not give any extra space on the SYN/ACK. Bob At 02:13 03/10/2014, Joe Touch wrote: >On 10/2/2014 5:57 PM, Bob Briscoe wrote: > > Joe, > > > > > > At 17:25 02/10/2014, Joe Touch wrote: > > > > > >> On 10/2/2014 9:14 AM, Bob Briscoe wrote: > >> > Joe, > >> > > >> > At 16:00 02/10/2014, Joe Touch wrote: > >> >> Hi, Bob and Wes (et al.), > >> >> > >> >> First, IMO "option-removing" middleboxes ought to be considerd broken > >> >> and fixed. Let's not treat this otherwise on that end. > >> > > >> > It is our job to make the IETF's protocols robust against attack - at > >> > least against low cost attacks. If our protocols can be corrupted by > >> > simple middlebox behaviours that we already know about, they will > >> > certainly not be robust against deliberate attacks. > >> > >> None of our protocols is robust in this way except those that add > >> authentication. It isn't useful to try to build non-authentication > >> extensions to be robust to those sorts of attacks > > > > So you are saying that the 'trivial' protection you added to EDO was not > > useful, even tho it solved the problem? > >It won't prevent the "attack"; it turns the attack into a DOS event. > > > 1) Altho carefully designed protocol structure does not address /all > > possible/ byzantine behaviours, it can harden a protocol against most or > > even all known middlebox behaviours... > > 2) ...without the overhead of authentication... > > 3) ...and authentication is not a panacea anyway - an authenticated > > message proves nothing if it's not delivered - all authentication > > solutions sit within a broader scheme that has to be /structurally/ secure. > >I agree it's useful to put in reasonable safeguards, but I don't think >we should be designing against byzantine or malicious events. > > >> - those extensions > >> need to be compatible with real security protection (which they are). > > > > I think you're using the term 'real security' when you mean > > cryptography. Security is a much broader art than just cryptography. > >I was being informal. Cryptography isn't the right term, unless the >intent is to hide the packet format from the middlebox. > >Ultimately, only integrity protection will suffice. > > > I recently gave a presentation about the overlloked role of structural > > security. Many security professionals unconsciously allow their > > attention to stray from any security problems that are not amenable to > > cryptographic solutions. And they blinker themselves into using > > crytography as the hammer for every nail to the exclusion of more > > appropriate techniques. > > > > Using protocol structure to protect against the self-interested > > behaviour of middlebox manufacturers /is/ real security. As your own > > 'trivial' solution demonstrates. > >It's not security, IMO. It's error avoidance. > > >> > One can think of an erroneous middlebox as an attack on users by a > >> > company intent on profiting while complying with just enough of the > >> > protocols to make their product saleable. > >> > >> That's a fine game, but it ends up backfiring. There were a half-dozen > >> companies in the late 1990s that violated TCP rules to "accelerate" > >> transfers. Customers found out what was going on and they're no longer > >> in business. > > > > I think you mean "It ended up backfiring in half-a-dozen cases, and I > > can't prove why they went bust, but I wish it was because they violated > > TCP rules". > >They got tarred and feathered for it at the time. Maybe not all of them, >but some did. > > > There are dozens, probably hundreds, of companies still making healthy > > profits out of middleboxes that violate TCP rules. > > > > > >> > Saying such behaviour "ought to be fixed" is equivalent to saying > >> > "self-interest ought to be fixed". It is also similar to saying > >> > "attackers ought not to be self-interested, so we shouldn't have to > >> > secure our protocols". > >> > >> I'm saying that bugs should be treated as such. None of our non-security > >> protocols are designed to be robust to byzantine attacks. > > > > In this thread alone, three have been mentioned: > > - MPTCP > > - EDO with your recent trivial alteration. > > - Syn-op-sis > >None of them are robust to byzantine attacks, one of which could easily >combine the SYN solutions with an inserted TFO that isn't where you >think it would be safe. > > >> >> Second, it's trivial to protect against that event by simply: > >> >> > >> >> a) not using the EDO space until after the SYN/ACK > >> >> b) requiring it on every segment once enabled > >> >> > >> >> (b) makes EDO robust to erroneous middleboxes, regardless of > >> asymmetry. > >> >> > >> >> (a) is required to differentiate asymmetric errors like this and > >> >> legitimate legacy servers. > >> >> > >> >> FWIW, I don't think we need to do anything in the final ACK of the > >> TWHS. > >> >> We treat it like any other segment - once the option makes it in both > >> >> directions, removal of the option effectively kills the packet (and > >> >> terminates the connection). > >> > > >> > Correct. > >> > > >> >> IF this is a significant concern, we can add it to EDO trivially, but > >> >> I'd like to know how prevalent this is and whether it can be corrected > >> >> by fixing the error first. > >> >> > >> >> However, I don't quite see a way around avoiding SYN/ACK use of any > >> >> extension unless we pull the same trick with SYN/ACKs we use with SYNs > >> >> (OOB segment or dual-SYN/ACK). > >> > > >> > And what about the second part of my email on segment coalescing? > >> That's > >> > much tougher, and probably much more prevalent than asymmetric > >> middlebox > >> > behaviour. > >> > >> Yes, but we're talking about segment coalescing where the middlebox > >> deliberately copies options it doesn't understand. That's a recipe for > >> disaster for options anyway. > >> > >> Yes, we need to understand how prevalent that is and whether to > >> recommend existing methods that would either prevent (cause to fail) or > >> detect such rewriting, but I don't think it's useful to build that into > >> each option. > > > > So, for instance, if we added a payload_size field to EDO, would that be > > 'not useful' for detecting segment coalescing? > >Strictly, so would a new TCP option called "the real segment length", so >long as the coalescing device didn't know about it. That's what you're >basically doing by adding the info to EDO. > > > Should we deny that > > payload-size is useful and require EDO to use authentication instead? > >If we want to build an option to detect and/or protect against >coalescing, fine. But I don't see why we should bundle that in another >option. It might be useful for other options besides ours. > > > For a minimum protocol, we have to protect against muddle but not > > meddle. Then, if the implementer chooses, s/he can use authentication to > > protect against meddle as an optional extra. > >I support the idea of an option to detect and/or protect against >middleboxes, but again I don't see why we need that bundled with EDO. > >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Sat Oct 4 13:24:44 2014 Return-Path: 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 8F1DF1A0295 for ; Sat, 4 Oct 2014 13:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 v03E1hV4t2qV for ; Sat, 4 Oct 2014 13:24:38 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77B1A0292 for ; Sat, 4 Oct 2014 13:24:37 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 04921C94A9; Sat, 4 Oct 2014 16:24:31 -0400 (EDT) Date: Sat, 4 Oct 2014 16:24:31 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20141004202431.GA72713@verdi> References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/y8rZRQ67125lCSCquuccOzOpc1M Cc: tcpm IETF list , Joe Touch Subject: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 20:24:41 -0000 Bob Briscoe wrote: > > There are three suggested additions to EDO: > a) defer extra options until after the SYN/ACK > b) require EDO on all segments Please don't! > c) include the payload size in the EDO option what about: d) set the Data Offset field to zero when using EDO? (I may have missed something, but it seems to me that would prevent the horror Bob mentioned.) > - a) and b) together should detect asymmetric (or intermittent) > option removal. > - c) should detect non-malicious segment coalescing. > - Once either of these behaviours is detected, the connection has to abort. > - Detection-only solutions turn middlebox corruption into DoS (ie. > denying the extended option service). I'm not sure we need to limit our thinking to detection-only -- but that seems sufficient for our first RFC (if it's Experimental status). > ===Next Steps=== > > I shall produce an update to syn-op-sis to extend it to all segments > of a connection. I believe syn-op-sis has more potential to be > enhanced to improve on EDO: > - it should enable extra options on the SYN/ACK (ie. all segments). > - it already /prevents/ corruption due to option removal > - however, I think it will only /detect/ corruption due to coalescing I will be very interested to read this... > I guess you'll update EDO with whichever of a)b)c) you decide on. Um... tcp-edo is now a Working Group document. I believe we should discuss what changes are appropriate before the Document Editor posts a new version. > We need experiments (including those already written up) to determine > how prevalent various middlebox behaviours are. I agree experiments are needed. I prefer getting an Experimental document out fairly quickly to trying to do all needed Experiments before publishing. > I don't know where this leaves SYN-EOS OOB. It is currently > integrated with EDO, but if EDO defers extra option until after the > SYN/ACK, then OOB + EDO together will not give any extra space on the > SYN/ACK. syn-eos-oob should be a separate document. (IMHO) Joe should be free to do whatever he wants with it (As Bob should be free to do whatever he wants with syn-op-sis). -- John Leslie From nobody Sat Oct 4 21:33:33 2014 Return-Path: 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 2EE1B1A049A for ; Sat, 4 Oct 2014 21:33:31 -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 ZLZDv69qmH7J for ; Sat, 4 Oct 2014 21:33:29 -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 ECB4A1A0469 for ; Sat, 4 Oct 2014 21:33:28 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s954WwaT008133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 4 Oct 2014 21:33:01 -0700 (PDT) Message-ID: <5430C9FB.2010000@isi.edu> Date: Sat, 04 Oct 2014 21:32:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , Bob Briscoe References: <201410021150.s92Bov3U014372@bagheera.jungle.bt.co.uk> <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> In-Reply-To: <20141004202431.GA72713@verdi> 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/37dSkKEM2qkxbAUnco1ZFpaybOk Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 04:33:31 -0000 On 10/4/2014 1:24 PM, John Leslie wrote: > Bob Briscoe wrote: >> > >> There are three suggested additions to EDO: >> a) defer extra options until after the SYN/ACK >> b) require EDO on all segments > > Please don't! I'm not sure about your concern; we're talking about putting EDO in all segments of a connection *on which* EDO has been negotiated. Nobody is expecting EDO to be turned on for all connections. >> c) include the payload size in the EDO option > > what about: > > d) set the Data Offset field to zero when using EDO? > > (I may have missed something, but it seems to me that would prevent > the horror Bob mentioned.) That just means that middleboxes won't see *any* of the options, including whether a segment is using TCP-AO (and thus modifying the segment would trash it). It doesn't address the scenario Bob described. Extended options could still be merged with user data if the segments are merged or rewritten in without consideration for EDO. >> - a) and b) together should detect asymmetric (or intermittent) >> option removal. >> - c) should detect non-malicious segment coalescing. >> - Once either of these behaviours is detected, the connection has to abort. >> - Detection-only solutions turn middlebox corruption into DoS (ie. >> denying the extended option service). > > I'm not sure we need to limit our thinking to detection-only -- but > that seems sufficient for our first RFC (if it's Experimental status). It would help if you could give an example of any other option that corrects middlebox corruption; otherwise, we should set our expectations for this option accordingly. >> ===Next Steps=== >> >> I shall produce an update to syn-op-sis to extend it to all segments >> of a connection. I believe syn-op-sis has more potential to be >> enhanced to improve on EDO: >> - it should enable extra options on the SYN/ACK (ie. all segments). >> - it already /prevents/ corruption due to option removal >> - however, I think it will only /detect/ corruption due to coalescing > > I will be very interested to read this... > >> I guess you'll update EDO with whichever of a)b)c) you decide on. > > Um... tcp-edo is now a Working Group document. > > I believe we should discuss what changes are appropriate before the > Document Editor posts a new version. That's what we're doing... >> We need experiments (including those already written up) to determine >> how prevalent various middlebox behaviours are. > > I agree experiments are needed. I prefer getting an Experimental > document out fairly quickly to trying to do all needed Experiments > before publishing. By that logic, all work on all new TCP options should halt dead in its tracks. What we do need is to understand the prevalence of the byzantine failures we've been discussing (and no, let's not call them just "behaviors"; there needs to be a limit to what we allow on-path. at some point, that "behavior" is an attack or a bug and should be fixed rather than "observed"). >> I don't know where this leaves SYN-EOS OOB. It is currently >> integrated with EDO, but if EDO defers extra option until after the >> SYN/ACK, then OOB + EDO together will not give any extra space on the >> SYN/ACK. > > syn-eos-oob should be a separate document. (IMHO) It is. Bob's referring to the mechanism in syn-eos-oob that turns on EDO for the rest of the connection; that has no impact on the EDO-only document. Joe > > Joe should be free to do whatever he wants with it (As Bob should > be free to do whatever he wants with syn-op-sis). > > -- > John Leslie > From nobody Sun Oct 5 17:38:10 2014 Return-Path: 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 CB6D01A01D5 for ; Sun, 5 Oct 2014 17:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] 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 mtnUjibnKHSG for ; Sun, 5 Oct 2014 17:38:07 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4EB1A01C6 for ; Sun, 5 Oct 2014 17:38:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 15521C94BF; Sun, 5 Oct 2014 20:38:01 -0400 (EDT) Date: Sun, 5 Oct 2014 20:38:01 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20141006003801.GB72713@verdi> References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <201409301554.s8UFsjCl006183@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409301554.s8UFsjCl006183@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/L1pnQWGJ6XfIV5iSHBP9G8A0O38 Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 00:38:08 -0000 Bob Briscoe wrote: > > I've got a bit behind in this conversation - I'm on another part of > my job at the mo. So apologies that my response to this old posting > on this thread arrives out of order. I've been over-extended myself this past week. :^( I'm not sure this still deserves a response, but I'd like to cover a few points... > At 20:53 26/09/2014, John Leslie wrote: >> Bob Briscoe wrote: >>> At 15:50 26/09/2014, John Leslie wrote: >>>> Bob Briscoe wrote: > >>>> For any Experimental-status document, I recommend: >>>>... >>>> - that any acknowledgment of extra option space in an initial SYN >>>> include a checksum or hash of the extra options to ensure that both >>>> ends have the same view of what options have been signaled; >>> >>> Not convinced on this one. Each TCP option has its own way for the >>> 'server' to confirm whether it supports an option requested by the >>> client. >> >> And this one should also have its own way. I see so many things that >> could get in the way that I _strongly_ recommend some checksum/hash. >> >>> And support for the option to extend the option space is confirmed by >>> the server. >> >> One bit of information (support-yes-or-no) just isn't sufficient, >> IMHO. > > I believe you're trying to recover some determinism because of the > non-determinism I've introduced. No. I'm trying to detect an arbitrarily-large class of implementation problems which may pop up. Granted, there's nothing to _do_ about them except recognize that _somebody_ isn't speaking the protocol we specify; but for something this radical, that's important information. :^( > If so, I strongly believe that it's better to lessen the original > non-determinism (e.g. by a larger magic number), rather than to add > more message exchanges. (I don't see any additional "message exchange" here: like any checksum, discarding packets which fail the checksum is the default behavior.) > If both achieve the same higher level of determinism, I'd much rather > use the one that avoids adding more branches to the protocol logic. As I said, that's not my aim. >>> So it seems redundant for the server to feedback yet another >>> confirmation via a checksum of all the extra options requested. >> >> Redundancy is your friend when complexity multiplies. > > I believe the opposite is true. If you provide two different ways to > say the same thing, you create more complexity - to check they are > both saying the same thing. And if they are not, you have to decide > which one not to believe. This makes the spec and the code more complex. This isn't two ways to say the same thing: it's just a sanity check to see if I should trust what you're saying at all. Once implemenations settle down (ROTFL), the checksum will never fail. >... >>>> IMHO, the SYN sender should never use SYN-U unless extra option >>>> space in the SYN is needed; and it's probably better to never use >>>> SYN-U for connections where latency of setup is the over-riding factor. >>>> But YMMV. I wonder whether such overlap is worth the trouble to try >>>> to design into the protocol. > > You're allowed your humble opinion. However, if you analyse the > SYNOPSIS protocol, you will conclude with absolute certainty that the > upgraded SYNOPSIS connection has no latency cost. So if a SYN-U gets > options through middleboxes, I predict it will be used whether or not > the extra space is needed. This issue is partly Overcome-By-Events, since Bob is working on a version of syn-op-sis to cover _every_ packet in a TCP connection. I will wait to read it... >>> In the syn-op-sis spec there is a choice between two variants of the >>> protocol (I recommend the choice can be made by implementers, not the >>> IETF). >> >> This is a dangerous idea. Experimental results get hopelessly cloudy >> when implementations are _fundamentally_ different... > > I've put forward two pairs of variants. For the first pair of > variants, I have asked the IETF to decide between them (so I put the > one I least recommend in an Appendix). I'm not sure we all feel competent to make that choice... :^( > But for the other pair of variants, I realised that the choice of > variants can be left to the implementer, so I put it in the body > (Section 6). (This really does complicate evaluation of the Experiment...) > I didn't come to these conclusions without a lot of thought (whereas > up to draft-01 I hadn't fully thought this through)... > > The only difference in the section 6 variant is the SYN-L. It became > clear to me that this is not a fundamental difference when I realised > that a middlebox could reduce the SYN-L to a SYN and it would turn > the protocol into the other variant. So the rest of the protocol is > identical. > > The reason for allowing either at run-time is that the SYN-L variant > is more likely to be preferred after most servers have been upgraded, > but not at the start of deployment (explained in the Appendix linked below). That sounds like looking too far ahead. During an Experimental period, rather few servers will be updated. >>> The choice I've recommended removes any risk of extra latency >>> on the upgraded connection. I've included a discussion of the >>> tradeoff between them in Appendix B.1: >>> >> Interesting reading... But I'd prefer keeping the Experiment simple. -- John Leslie From nobody Sun Oct 5 18:31:14 2014 Return-Path: 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 EF7061A0282 for ; Sun, 5 Oct 2014 18:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] 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 dnqd7FdMjQoo for ; Sun, 5 Oct 2014 18:31:08 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 430341A0273 for ; Sun, 5 Oct 2014 18:31:08 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A5C5BC94A8; Sun, 5 Oct 2014 21:31:04 -0400 (EDT) Date: Sun, 5 Oct 2014 21:31:04 -0400 From: John Leslie To: Joe Touch Message-ID: <20141006013104.GC72713@verdi> References: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5430C9FB.2010000@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/1a7RRxfPU4ImjJkFEZNAcZZywxE Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 01:31:12 -0000 Joe Touch wrote: > On 10/4/2014 1:24 PM, John Leslie wrote: >> Bob Briscoe wrote: >>> >> >>> There are three suggested additions to EDO: >>> a) defer extra options until after the SYN/ACK >>> b) require EDO on all segments >> >> Please don't! > > I'm not sure about your concern; we're talking about putting EDO in all > segments of a connection *on which* EDO has been negotiated. Nobody is > expecting EDO to be turned on for all connections. It's hard to know at every connection start whether at some later point extra options will prove useful. >>> c) include the payload size in the EDO option >> >> what about: >> >> d) set the Data Offset field to zero when using EDO? >> >> (I may have missed something, but it seems to me that would prevent >> the horror Bob mentioned.) > > That just means that middleboxes won't see *any* of the options, > including whether a segment is using TCP-AO (and thus modifying the > segment would trash it). Middleboxes which don't understand EDO, indeed, won't see the extra options. But this really doesn't matter, because they'll either pass it correctly or drop it -- the same choices as if they _did_ understand EDO. (I could have sworn it was Joe who said broken middleboxes need to be replaced. ;) > It doesn't address the scenario Bob described. Extended options could > still be merged with user data if the segments are merged or rewritten > in without consideration for EDO. The Data-Offset-Zero case can't lead to merging, because clueless middleboxes won't be able to find _any_ options to merge. ==== It might help for me to detail what I think Data-Offset-Zero means. The original SYN includes a two-byte option announcing that the sender speaks EDO -- that is, it will understand if it receives an EDO packet and it knows how to send one. The SYN-ACK MAY include a four-byte option announcing the option space is larger than 40 bytes. Or it may include in the regular option space a two-byte option simply announcing that it speaks EDO but doesn't want to use it yet. If either of these doesn't happen, the connection is not EDO-capable. But recall that the original SYN-sender knows how to speak EDO; thus the SYN-ACK, upon sending an EDO option, MAY assume the connection to be EDO-capable. (This assumption may prove false if there is a middlebox which doesn't understand EDO. The ambiguity will be short-lived in that case because the SYN-ACK with the EDO option won't arrive.) If the connection _is_ EDO-capable, both endpoints will know that a Data Offset of zero indicates the presence of a four-byte EDO option stating the actual length of the option space. Thus they can start parsing the option space before learning its actual length. Middleboxes which don't understand EDO will of necessity drop the packet instead of misinterpreting some of the actual options as application data. The packet drop will indicate the probable presence of such a middlebox. (I need not go into detail here about how to deal with that, but questions will be welcomed.) Middleboxes which aren't trying to violate layering will simply pass the IP packet without any damage (or drop it, if it violates some rule they're trying to enforce). If a meddlebox drops the SYN or SYN-ACK EDO option, the endpoints won't even try to speak EDO. If paths change and a different middlebox drops a packet, we simply detect the problem when it arises. ==== >> I'm not sure we need to limit our thinking to detection-only -- but >> that seems sufficient for our first RFC (if it's Experimental status). > > It would help if you could give an example of any other option that > corrects middlebox corruption; otherwise, we should set our expectations > for this option accordingly. One _can_ only "correct" middlebox corruption by detecting it and routing around it. Data-Offset-Zero will certainly detect it; and the endpoints can route around it by avoiding EDO. >>> We need experiments (including those already written up) to determine >>> how prevalent various middlebox behaviours are. >> >> I agree experiments are needed. I prefer getting an Experimental >> document out fairly quickly to trying to do all needed Experiments >> before publishing. > > By that logic, all work on all new TCP options should halt dead in its > tracks. I can't think of a way to parse what I wrote so as to lead to that conclusion. (I have to guess you missed the "to" before "trying to do".) Let me restate it: I prefer getting an Experimental document out fairly quickly for EDO. This threatens to drag on interminably if we try to do all the needed experiments before publishing an Experimental-track document. Also, if we describe the experiments in such a document, it will be easier for folks to help us with them. > What we do need is to understand the prevalence of the byzantine > failures we've been discussing (and no, let's not call them just > "behaviors"; there needs to be a limit to what we allow on-path. at some > point, that "behavior" is an attack or a bug and should be fixed rather > than "observed"). I sympathize! But eliminating bad behavior in-the-wild just doesn't happen. We _can_ raise the awareness of it; and that will help _reduce_ it. Just bad-mouthing it general won't even reach the folk who can help us reduce the bad behavior. :^( -- John Leslie From nobody Mon Oct 6 02:30:50 2014 Return-Path: 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 5C0921A1B7B for ; Mon, 6 Oct 2014 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 muj6QC0-JBqt for ; Mon, 6 Oct 2014 02:30:45 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AF61A1B25 for ; Mon, 6 Oct 2014 02:30:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2B540D930E; Mon, 6 Oct 2014 11:30:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qOvz31r8lGw3; Mon, 6 Oct 2014 11:30:41 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id EA74BD930B; Mon, 6 Oct 2014 11:30:41 +0200 (MEST) Message-ID: <54326141.5050803@tik.ee.ethz.ch> Date: Mon, 06 Oct 2014 11:30:41 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yuchung Cheng , "Zimmermann, Alexander" , "gorry@erg.abdn.ac.uk" References: <20140913074311.28129.72796.idtracker@ietfa.amsl.com> <0db9fb03774c3c5002530064864d496e.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XowtY-by362SL6VoTsmqXwmMGgQ Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 09:30:49 -0000 Hi Yucheng, On 22.09.2014 21:40, Yuchung Cheng wrote: > The latest Linux uses an algorithm by Neal Cardwell that incidentally is similar > to the proposed newcwv draft sec 4.2. The key differences are > > 1) it uses FlightSize instead of the pipe variable > 2) it takes care of the TSO deferral. The TSO deferral part is important because > TCP may not always fill cwnd in order to build bigger packet. > > http://patchwork.ozlabs.org/patch/351512/ Would you and/or Neal be able to write this algorithm down in a small draft, so that it is easier to compare the differences between your approach and newcwv? Mirja > > Note there is a preceeding bug-fix patch done by Eric Dumazet, where TSO and TCP > small queue, could trick TCP not to slow start fast. This demonstrates the > complexity to determine if TCP is cwnd limited or not, in modern networking stack. > > http://patchwork.ozlabs.org/patch/344293/ > > Linux does not implement newcwv. I guess it's not clear if the other parts are > useful or not, other than not being so conservative in growing cwnd. Lastly, I > would recommend newcwv draft to be more specific on the algorithm in Sec 4.2. > > HTH > > From nobody Mon Oct 6 03:11:55 2014 Return-Path: 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 65E981A1B85 for ; Mon, 6 Oct 2014 03:11:53 -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 b_lTvtvCXcdW for ; Mon, 6 Oct 2014 03:11:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C151A1B83 for ; Mon, 6 Oct 2014 03:11:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 4F6CE2FB942C8 for ; Mon, 6 Oct 2014 10:11:48 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s96ABjOK032487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Oct 2014 12:11:50 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 12:11:48 +0200 From: "Scharf, Michael (Michael)" To: tcpm IETF list Thread-Topic: DCTCP in linux net-next Thread-Index: AQHP4U3wUglLfHXJ2UC+yFG2mZTVRg== Date: Mon, 6 Oct 2014 10:11:47 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1665C15C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wo9PNA86gwrkyxamzl7niIAlBnM Subject: [tcpm] DCTCP in linux net-next X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 10:11:53 -0000 RGF2ZSBUYWh0IHBvc3RlZCB0aGVzZSB0d28gbGlua3Mgb24gdGhlIEFRTSBsaXN0LCBidXQgdGhl eSBzZWVtIHF1aXRlIHJlbGV2YW50IHRvIFRDUE0gYXMgd2VsbDoNCg0KaHR0cHM6Ly9naXQua2Vy bmVsLm9yZy9jZ2l0L2xpbnV4L2tlcm5lbC9naXQvZGF2ZW0vbmV0LW5leHQuZ2l0L2NvbW1pdC8/ aWQ9ZTMxMThlODM1OWJiN2M1OTU1NWFjYTYwYzcyNTEwNmU2ZDc4YzVjZQ0KDQpodHRwOi8vdGhy ZWFkLmdtYW5lLm9yZy9nbWFuZS5saW51eC5uZXR3b3JrLzMzMjI1OQ0KDQpNaWNoYWVsDQoNCg== From nobody Mon Oct 6 10:09:04 2014 Return-Path: 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 491941A8702 for ; Mon, 6 Oct 2014 10:08:56 -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 dfFkrXe4gS9M for ; Mon, 6 Oct 2014 10:08:46 -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 D85F21A8717 for ; Mon, 6 Oct 2014 10:08:34 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s96H84v8012722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Oct 2014 10:08:04 -0700 (PDT) Message-ID: <5432CC74.6020107@isi.edu> Date: Mon, 06 Oct 2014 10:08:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John Leslie References: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> <20141006013104.GC72713@verdi> In-Reply-To: <20141006013104.GC72713@verdi> Content-Type: text/plain; charset=windows-1252 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/GNEK2jbcRIKr8nBPGaKDwMn8NeY Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 17:08:57 -0000 On 10/5/2014 6:31 PM, John Leslie wrote: > Joe Touch wrote: >> On 10/4/2014 1:24 PM, John Leslie wrote: >>> Bob Briscoe wrote: >>>> >>> >>>> There are three suggested additions to EDO: >>>> a) defer extra options until after the SYN/ACK >>>> b) require EDO on all segments >>> >>> Please don't! >> >> I'm not sure about your concern; we're talking about putting EDO in all >> segments of a connection *on which* EDO has been negotiated. Nobody is >> expecting EDO to be turned on for all connections. > > It's hard to know at every connection start whether at some later > point extra options will prove useful. TCP option capabilities are negotiated during the SYN exchange. The only benefit to making them optional afterwards is to save option space - a problem EDO doesn't face. We've discussed turning on options mid-connection before, and that's a separate issue we're not considering here. >>>> c) include the payload size in the EDO option >>> >>> what about: >>> >>> d) set the Data Offset field to zero when using EDO? >>> >>> (I may have missed something, but it seems to me that would prevent >>> the horror Bob mentioned.) >> >> That just means that middleboxes won't see *any* of the options, >> including whether a segment is using TCP-AO (and thus modifying the >> segment would trash it). > > Middleboxes which don't understand EDO, indeed, won't see the extra > options. But this really doesn't matter, because they'll either pass > it correctly or drop it -- the same choices as if they _did_ understand > EDO. Or ignore it but merge segments - or 'adjust' segment boundaries. Either of these additional operations would affect the extended option contents unless the middlebox knew about EDO. > (I could have sworn it was Joe who said broken middleboxes need to > be replaced. ;) I still do. >> It doesn't address the scenario Bob described. Extended options could >> still be merged with user data if the segments are merged or rewritten >> in without consideration for EDO. > > The Data-Offset-Zero case can't lead to merging, because clueless > middleboxes won't be able to find _any_ options to merge. The ones we've been discussing merge *segments* which will corrupt the options. > ==== > > It might help for me to detail what I think Data-Offset-Zero means. > > The original SYN includes a two-byte option announcing that the > sender speaks EDO -- that is, it will understand if it receives an > EDO packet and it knows how to send one. > > The SYN-ACK MAY include a four-byte option announcing the option > space is larger than 40 bytes. Or it may include in the regular > option space a two-byte option simply announcing that it speaks EDO > but doesn't want to use it yet. > > If either of these doesn't happen, the connection is not EDO-capable. > But recall that the original SYN-sender knows how to speak EDO; thus > the SYN-ACK, upon sending an EDO option, MAY assume the connection to > be EDO-capable. (This assumption may prove false if there is a middlebox > which doesn't understand EDO. The ambiguity will be short-lived in that > case because the SYN-ACK with the EDO option won't arrive.) FWIW, that's already how EDO works as per the draft. > If the connection _is_ EDO-capable, both endpoints will know that > a Data Offset of zero indicates the presence of a four-byte EDO option > stating the actual length of the option space. Thus they can start > parsing the option space before learning its actual length. There are some options that might warrant handling first - e.g., TCP-AO. > Middleboxes which don't understand EDO will of necessity drop the > packet instead of misinterpreting some of the actual options as > application data. We can't assume that. These are already boxes that don't follow spec. > The packet drop will indicate the probable presence > of such a middlebox. (I need not go into detail here about how to > deal with that, but questions will be welcomed.) > > Middleboxes which aren't trying to violate layering will simply > pass the IP packet without any damage (or drop it, if it violates > some rule they're trying to enforce). > > If a meddlebox drops the SYN or SYN-ACK EDO option, the endpoints > won't even try to speak EDO. If paths change and a different middlebox > drops a packet, we simply detect the problem when it arises. How do we differentiate this from a packet drop due to congestion? And what can we do when it happens anyway? > ==== > >>> I'm not sure we need to limit our thinking to detection-only -- but >>> that seems sufficient for our first RFC (if it's Experimental status). >> >> It would help if you could give an example of any other option that >> corrects middlebox corruption; otherwise, we should set our expectations >> for this option accordingly. > > One _can_ only "correct" middlebox corruption by detecting it and > routing around it. Data-Offset-Zero will certainly detect it; and the > endpoints can route around it by avoiding EDO. The endpoints will see packet loss only. Endpoints don't route around anything per se, and they treat loss via backoff and retransmission. >>>> We need experiments (including those already written up) to determine >>>> how prevalent various middlebox behaviours are. >>> >>> I agree experiments are needed. I prefer getting an Experimental >>> document out fairly quickly to trying to do all needed Experiments >>> before publishing. >> >> By that logic, all work on all new TCP options should halt dead in its >> tracks. > > I can't think of a way to parse what I wrote so as to lead to that > conclusion. (I have to guess you missed the "to" before "trying to do".) > > Let me restate it: > > I prefer getting an Experimental document out fairly quickly for EDO. The track has nothing to do with the speed of WG handling. There are no experiments we're waiting for in the case of EDO - it's the OOB case that definitely needs experiments, and probably also the SYNOPSIS case too. >> What we do need is to understand the prevalence of the byzantine >> failures we've been discussing (and no, let's not call them just >> "behaviors"; there needs to be a limit to what we allow on-path. at some >> point, that "behavior" is an attack or a bug and should be fixed rather >> than "observed"). > > I sympathize! > > But eliminating bad behavior in-the-wild just doesn't happen. We > _can_ raise the awareness of it; and that will help _reduce_ it. > Just bad-mouthing it general won't even reach the folk who can help > us reduce the bad behavior. :^( Please post us your draft on how to have routers handle IP packets whose type isn't 4, or better - whose Ethertype isn't 0x0800. At some point we need to declare a system "broken" and get it fixed. We don't make cars that fly just because bridges fail. Joe From nobody Mon Oct 6 15:25:05 2014 Return-Path: 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 956D81A8F3C for ; Mon, 6 Oct 2014 15:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 g85ISuqrlnIW for ; Mon, 6 Oct 2014 15:24:58 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A891A900A for ; Mon, 6 Oct 2014 15:24:24 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so3271900igb.8 for ; Mon, 06 Oct 2014 15:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RFAadOtQAn5Mq68aVYY/i8C+dv+KgjDfXbazkf6mukI=; b=ibw08crXiOxQVQBd5qgZc/xXLE4DZDZcby5pcL7hcsZXub737sAbJrpbQqr5nQ9Ubf IdBmrUjhCKVBr7Hqt4eebza3+x+lnLwLCYquCVIn7Y8BbOK64JP/8sRFftDxUwuHJiJ6 KumzuBcS6Ss53pmqdhhg3E9bODPpFtVlHOV7iweYDwbSj/XibwA9d2WsReCvLwlU1mmh GodWpwro7aFCBs6aoJkqhuHx/GJpMag+NDp/HFupuViEfKwuV3Eb6jUW5XuNyw2BBzDX nJx/NzYoJ6E3zZ1Vu8Lk2Zw04o/4wOZUuUwMp0vB7bW3YRENsuPeo3UGCc73Py83TEop wETQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=RFAadOtQAn5Mq68aVYY/i8C+dv+KgjDfXbazkf6mukI=; b=XI1JEXbL90rqK0VwacUKj2fzX7g5c1gEPIJp139j48qgxrgUd+cvYJSJr6VuZazA16 ycyrSuAhcV8SbR7hIc5JmUnN/RZQminzxjKF9o2LfmivYw3aqr13NblV5yWmubZFU0Rp mx9Y+IUz7P6fQp/RHBhWL7QIBpFAz0OdyCQRPdC7HwzYC/sqMR8s7cMHy76PjkvYSfPU 7xebgrk5GtmZUwHRbyUHukZKRnr2H98cLxvq+if9snw+4Q4dNUrc4r4f0fRNuPgtD0P+ KgmS4yxZwGu8oROmrqHZ/8Fmeq75I3cPSRCarBANbJ61/5SGCJxKRSdSeIsLRavi5D2z F5SQ== X-Gm-Message-State: ALoCoQlvDpR2XV0dyYNLbkMIh1JdKfnTy1T9Rid7T3kHZDE+k7w/VI3V5rh0y738D1junwPIR03p X-Received: by 10.50.72.43 with SMTP id a11mr25593272igv.23.1412634263733; Mon, 06 Oct 2014 15:24:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.168 with HTTP; Mon, 6 Oct 2014 15:23:43 -0700 (PDT) In-Reply-To: <54326141.5050803@tik.ee.ethz.ch> References: <20140913074311.28129.72796.idtracker@ietfa.amsl.com> <0db9fb03774c3c5002530064864d496e.squirrel@www.erg.abdn.ac.uk> <54326141.5050803@tik.ee.ethz.ch> From: Yuchung Cheng Date: Mon, 6 Oct 2014 15:23:43 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Plfko0nzoDuSecequfPO370U97s Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:25:01 -0000 +ncardwell@google.com Neal: would you like to formalize the algorithm? On Mon, Oct 6, 2014 at 2:30 AM, Mirja K=C3=BChlewind wrote: > Hi Yucheng, > > On 22.09.2014 21:40, Yuchung Cheng wrote: >> >> The latest Linux uses an algorithm by Neal Cardwell that incidentally is >> similar >> to the proposed newcwv draft sec 4.2. The key differences are >> >> 1) it uses FlightSize instead of the pipe variable >> 2) it takes care of the TSO deferral. The TSO deferral part is important >> because >> TCP may not always fill cwnd in order to build bigger packet. >> >> http://patchwork.ozlabs.org/patch/351512/ > > > Would you and/or Neal be able to write this algorithm down in a small dra= ft, > so that it is easier to compare the differences between your approach and > newcwv? > > Mirja > > > >> >> Note there is a preceeding bug-fix patch done by Eric Dumazet, where TSO >> and TCP >> small queue, could trick TCP not to slow start fast. This demonstrates t= he >> complexity to determine if TCP is cwnd limited or not, in modern >> networking stack. >> >> http://patchwork.ozlabs.org/patch/344293/ >> >> Linux does not implement newcwv. I guess it's not clear if the other par= ts >> are >> useful or not, other than not being so conservative in growing cwnd. >> Lastly, I >> would recommend newcwv draft to be more specific on the algorithm in Sec >> 4.2. >> >> HTH >> >> > From nobody Mon Oct 6 18:08:49 2014 Return-Path: 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 BB18E1A90F6 for ; Mon, 6 Oct 2014 18:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] 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 3MPQPHGTLX8B for ; Mon, 6 Oct 2014 18:08:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3D1A00DB for ; Mon, 6 Oct 2014 18:08:43 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A219BC94BD; Mon, 6 Oct 2014 21:08:39 -0400 (EDT) Date: Mon, 6 Oct 2014 21:08:39 -0400 From: John Leslie To: Joe Touch Message-ID: <20141007010839.GG72713@verdi> References: <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> <20141006013104.GC72713@verdi> <5432CC74.6020107@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5432CC74.6020107@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZOILeGtkzsjDh_9aJNVvxxcbkyw Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 01:08:48 -0000 Joe Touch wrote: > On 10/5/2014 6:31 PM, John Leslie wrote: >> >> It's hard to know at every connection start whether at some later >> point extra options will prove useful. > > TCP option capabilities are negotiated during the SYN exchange. The only > benefit to making them optional afterwards is to save option space - a > problem EDO doesn't face. The legacy limit on space for TCP options is not the only reason to use options sparingly -- least of all for options that haven't yet been specified. > We've discussed turning on options mid-connection before, and that's a > separate issue we're not considering here. I'm not trying to solve that issue (though it would be easy enough to do so) -- I'm trying to cater to options which will be useful for only part of the time a TCP connection is open. >> Joe Touch wrote: >>> On 10/4/2014 1:24 PM, John Leslie wrote: >> >>>> d) set the Data Offset field to zero when using EDO? >>>> >>> That just means that middleboxes won't see *any* of the options, >>> including whether a segment is using TCP-AO (and thus modifying the >>> segment would trash it). >> >> Middleboxes which don't understand EDO, indeed, won't see the extra >> options. But this really doesn't matter, because they'll either pass >> it correctly or drop it -- the same choices as if they _did_ understand >> EDO. > > Or ignore it but merge segments - or 'adjust' segment boundaries. Either > of these additional operations would affect the extended option contents > unless the middlebox knew about EDO. A middlebox would have to be _rather_ braindead to believe that a Data Offset of zero pointed to an actual start of data. Unless you can supply an existence-proof of such middleboxes, I think it quite safe to rule out such behavior. >>> It doesn't address the scenario Bob described. Extended options could >>> still be merged with user data if the segments are merged or rewritten >>> in without consideration for EDO. >> >> The Data-Offset-Zero case can't lead to merging, because clueless >> middleboxes won't be able to find _any_ options to merge. > > The ones we've been discussing merge *segments* which will corrupt the > options. That causes problems long before we start considering expanded option space. The problems which _now_ cause undiagnosed strangeness would become impossible to ignore if we use Data Offset Zero. But again, I have not seen evidence that middleboxes braindead in _this_ particular way exist. (I do think that Experimental status is appropriate to weed out _any_ unlikely flavors of braindead, though.) >> It might help for me to detail what I think Data-Offset-Zero means. Note that this is aimed at WG members who are not as familiar with the subject of this discussion as Joe and Bob... >> The original SYN includes a two-byte option announcing that the >> sender speaks EDO -- that is, it will understand if it receives an >> EDO packet and it knows how to send one. >> >> The SYN-ACK MAY include a four-byte option announcing the option >> space is larger than 40 bytes. Or it may include in the regular >> option space a two-byte option simply announcing that it speaks EDO >> but doesn't want to use it yet. >> >> If either of these doesn't happen, the connection is not EDO-capable. >> But recall that the original SYN-sender knows how to speak EDO; thus >> the SYN-ACK, upon sending an EDO option, MAY assume the connection to >> be EDO-capable. (This assumption may prove false if there is a middlebox >> which doesn't understand EDO. The ambiguity will be short-lived in that >> case because the SYN-ACK with the EDO option won't arrive.) > > FWIW, that's already how EDO works as per the draft. Exactly. (But not everyone can grok that from a brief reading.) >> If the connection _is_ EDO-capable, both endpoints will know that >> a Data Offset of zero indicates the presence of a four-byte EDO option >> stating the actual length of the option space. Thus they can start >> parsing the option space before learning its actual length. > > There are some options that might warrant handling first - e.g., TCP-AO. Indeed. (If we adopt Data-Offset-Zero, we should mention this. But nothing about Data-Offset-Zero requires that the EDO option come first, or even within the first 40 bytes.) >> Middleboxes which don't understand EDO will of necessity drop the >> packets instead of misinterpreting some of the actual options as >> application data. > > We can't assume that. These are already boxes that don't follow spec. If middleboxes as braindead as you stipulate are found to exist, we should mention ways to deal with this. But please understand that the situation can't arise without the endpoint receiving a EDO option with Data-Offset-Zero having announced that it understands EDO: thus we could easily make detection of a braindead middlebox part of the protocol. >> The packet drop will indicate the probable presence >> of such a middlebox. (I need not go into detail here about how to >> deal with that, but questions will be welcomed.) >> >> Middleboxes which aren't trying to violate layering will simply >> pass the IP packet without any damage (or drop it, if it violates >> some rule they're trying to enforce). >> >> If a meddlebox drops the SYN or SYN-ACK EDO option, the endpoints >> won't even try to speak EDO. If paths change and a different middlebox >> drops a packet, we simply detect the problem when it arises. > > How do we differentiate this from a packet drop due to congestion? And > what can we do when it happens anyway? A fair question. The simplest answer is that dropping will persist until a packet is sent without the EDO option (assuming, of course, that some options _don't_ have to be sent in every packet -- that's why I want to avoid any rule that an EDO option must be in every packet). We could, for example, specify that a retransmitted packet must not use the EDO option. >> One _can_ only "correct" middlebox corruption by detecting it and >> routing around it. Data-Offset-Zero will certainly detect it; and the >> endpoints can route around it by avoiding EDO. > > The endpoints will see packet loss only. Endpoints don't route around > anything per se, and they treat loss via backoff and retransmission. But of course, if the retransmission doesn't use EDO, that already amounts to routing around the problem. If we were dealing with an MPTCP connection-set, we would literally route-around a braindead middlebox. >> I prefer getting an Experimental document out fairly quickly for EDO. > > The track has nothing to do with the speed of WG handling. There are > no experiments we're waiting for in the case of EDO - it's the OOB > case that definitely needs experiments, and probably also the SYNOPSIS > case too. I don't get the impression that we have consensus to issue tcp-edo (as-is or with changes suggested so far) as Proposed Standard. YMMV. >> But eliminating bad behavior in-the-wild just doesn't happen. We >> _can_ raise the awareness of it; and that will help _reduce_ it. >> Just bad-mouthing it general won't even reach the folk who can help >> us reduce the bad behavior. :^( > > At some point we need to declare a system "broken" and get it fixed. We > don't make cars that fly just because bridges fail. (Of course, we _do_ make cars that fly; but that's not the question!) _Somebody_ with authority to demand the fix has to notice the problem first... -- John Leslie From nobody Tue Oct 7 03:31:28 2014 Return-Path: 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 A9E831ACCE2 for ; Tue, 7 Oct 2014 03:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 yo_wK4_w_Ghw for ; Tue, 7 Oct 2014 03:31:22 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63911A923A for ; Tue, 7 Oct 2014 03:31:21 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 7 Oct 2014 11:31:20 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 7 Oct 2014 11:31:19 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 7 Oct 2014 11:31:15 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.37.124]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s97AVCVB006565; Tue, 7 Oct 2014 11:31:13 +0100 Message-ID: <201410071031.s97AVCVB006565@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 7 Oct 2014 11:30:00 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20141006003801.GB72713@verdi> References: <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk> <20140926145037.GA82183@verdi> <201409261716.s8QHGC7I020142@bagheera.jungle.bt.co.uk> <20140926195338.GH83009@verdi> <201409301554.s8UFsjCl006183@bagheera.jungle.bt.co.uk> <20141006003801.GB72713@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7hwLQTrmTg6pvTvYgs-rkFxGhtc Cc: tcpm IETF list Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:31:27 -0000 John, At 01:38 06/10/2014, John Leslie wrote: [snip] > > But for the other pair of variants, I realised that the choice of > > variants can be left to the implementer, so I put it in the body > > (Section 6). > > (This really does complicate evaluation of the Experiment...) > > > I didn't come to these conclusions without a lot of thought (whereas > > up to draft-01 I hadn't fully thought this through)... > > > > The only difference in the section 6 variant is the SYN-L. It became > > clear to me that this is not a fundamental difference when I realised > > that a middlebox could reduce the SYN-L to a SYN and it would turn > > the protocol into the other variant. So the rest of the protocol is > > identical. > > > > The reason for allowing either at run-time is that the SYN-L variant > > is more likely to be preferred after most servers have been upgraded, > > but not at the start of deployment (explained in the Appendix > linked below). > > That sounds like looking too far ahead. During an Experimental period, >rather few servers will be updated. > > >>> The choice I've recommended removes any risk of extra latency > >>> on the upgraded connection. I've included a discussion of the > >>> tradeoff between them in Appendix B.1: > >>> > >> > > Interesting reading... But I'd prefer keeping the Experiment simple. OK, you've helped me realise that it isn't necessary for a client to /send/ a SYN-L for the experiment. But experimental servers have to implement code in case they /receive/ it, otherwise the transition from experiment to production will be messy. That requires a one-line addition to an experimental server. And in the spec it requires two normative sentences in the body, and an explanation for why they're there in an appendix. The second sentence is to give notice to middleboxes to expect to see a SYN-L in the future (e.g. intrusion detection systems). This shows that it's always worth looking 'too far' ahead. Traditionally, we've been bad at 'forward compatibility'. It's possible I will be able to get the promised rev of syn-op-sis out today, as long as I don't get pulled off onto something else. Bob ________________________________________________________________ Bob Briscoe, BT From nobody Tue Oct 7 03:37:42 2014 Return-Path: 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 3C8141A1B86 for ; Tue, 7 Oct 2014 03:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 8wQES2jdUT-2 for ; Tue, 7 Oct 2014 03:37:38 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826191A1B65 for ; Tue, 7 Oct 2014 03:37:38 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 7 Oct 2014 11:37:36 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 7 Oct 2014 11:37:35 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 7 Oct 2014 11:37:35 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.37.124]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s97AbXHR006583; Tue, 7 Oct 2014 11:37:33 +0100 Message-ID: <201410071037.s97AbXHR006583@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 7 Oct 2014 11:37:33 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <5432CC74.6020107@isi.edu> References: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> <20141006013104.GC72713@verdi> <5432CC74.6020107@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6SusLm703ypdmYCGLDafk5nUzj4 Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 10:37:40 -0000 Joe, At 18:08 06/10/2014, Joe Touch wrote: > > I prefer getting an Experimental document out fairly quickly for EDO. > >The track has nothing to do with the speed of WG handling. There are no >experiments we're waiting for in the case of EDO - it's the OOB case >that definitely needs experiments, and probably also the SYNOPSIS case too. I hope the examples I gave at the start of this thread show that EDO is not immune to middlebox problems, and therefore should be conditional on middlebox traversal experiments (as should OOB and SYNOPSIS). The chairs qualified the WG's intention to go straight for Proposed Standard status for EDO with (paraphrasing) "We can always decide to downgrade to Experimental, but it's best to start aiming high." Bob ________________________________________________________________ Bob Briscoe, BT From nobody Tue Oct 7 07:59:26 2014 Return-Path: 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 2D4021ACDE7 for ; Tue, 7 Oct 2014 07:59:19 -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 JItapZPNGcfc for ; Tue, 7 Oct 2014 07:59:17 -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 7FEB21ACE02 for ; Tue, 7 Oct 2014 07:59:17 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s97Ewt1W004201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Oct 2014 07:58:58 -0700 (PDT) Message-ID: <5433FFB0.5090205@isi.edu> Date: Tue, 07 Oct 2014 07:58:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> <20141006013104.GC72713@verdi> <5432CC74.6020107@isi.edu> <201410071037.s97AbXHR006583@bagheera.jungle.bt.co.uk> In-Reply-To: <201410071037.s97AbXHR006583@bagheera.jungle.bt.co.uk> 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/FKRFjAURuTUQGyIZpm2QhexdEig Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:59:19 -0000 On 10/7/2014 3:37 AM, Bob Briscoe wrote: > Joe, > > At 18:08 06/10/2014, Joe Touch wrote: >> > I prefer getting an Experimental document out fairly quickly for >> EDO. >> >> The track has nothing to do with the speed of WG handling. There are no >> experiments we're waiting for in the case of EDO - it's the OOB case >> that definitely needs experiments, and probably also the SYNOPSIS case >> too. > > I hope the examples I gave at the start of this thread show that EDO is > not immune to middlebox problems, and therefore should be conditional on > middlebox traversal experiments (as should OOB and SYNOPSIS). IMO, these experiments should be conditional on some evidence they're a real concern, i.e.: - deployed in public networks in more than rare exceptions - a device the WG agrees that protocols should traverse (vs. a device considered incorrectly implemented that should be fixed or replaced) It's easy to posit device properties that can interfere with a proposal, but I don't agree that we need to deal with every possible byzantine case. Hesmans,et al., "Are TCP Extensions Middlebox-proof?", Conext 2013 explores how options react to middlebox behaviors that include splitting and coalescing, but the only middlebox behavior seen is a failure of ALG translation of active FTP through NATs. Splitting and coalescing are described, but (unlike other behaviors) their description has no citations. The citations in that paper go back to this: Honda, et al., "Is it still possible to extend TCP?", IMC 2011. "Although middleboxes do split and coalesce segments, *NONE* [emphasis mine] did so while passing unknown options...". Can we please stop chasing phantoms? Joe From nobody Wed Oct 8 04:39:06 2014 Return-Path: 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 197931A02DA for ; Wed, 8 Oct 2014 04:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 TvIrXSSQBcBD for ; Wed, 8 Oct 2014 04:39:02 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id 551C21A02F0 for ; Wed, 8 Oct 2014 04:39:02 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 542527360114412D for tcpm@ietf.org; Wed, 8 Oct 2014 14:39:01 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 8 Oct 2014 14:38:58 +0300 To: tcpm IETF list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/oHpi6wmR12oBWZCI89jxHT1prh0 Subject: [tcpm] Presentation requests for IETF-91 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 11:39:04 -0000 Hi, It is time to start building TCPM agenda for the Honolulu meeting. We = have requested a 2.5 hour slot for the TCPM meeting. If you want to = present your draft in the meeting, please send tcpm-chairs the following = information: * Title * Time needed (presentation + discussion) * Name of speaker Please send your requests by Thursday, October 23. Thanks! - Pasi From nobody Wed Oct 8 09:18:29 2014 Return-Path: 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 E00EC1A88A9 for ; Wed, 8 Oct 2014 09:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 WJgEkxXLfmZT for ; Wed, 8 Oct 2014 09:18:24 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB91E1A885F for ; Wed, 8 Oct 2014 09:18:21 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id hn15so353241igb.1 for ; Wed, 08 Oct 2014 09:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hm6f96tcWI/04d5/JQ1pqOa40uDdpbmZJnTD7wP10Mo=; b=QRWOYKP293dS5LfzyrIISpdEgiQRCU2b42jXmJ7ugof4tpGqur8apElp4uV9YXyWh3 grxMf9lOPCvU+xs+85gw6gVHllhb+DbvhpA9T+XW+zaE8M3c2VP2wpMeECk0NhoJT1ka rW9P6xEUwjfbSXRja/PkgJZfJt0z+bXKq6j+T1DDP0TV0mitWzgiYfGvI4hFHDhU4Yke YMhvC4173MBgMoewKnAGRduUIFeUCNyAC5nNmxfOhx2CC7mUJSM6IFBNavW3y+l7xmAJ 7krvfhjKkgNw+7m1j4PlxXA/fkHC+Z42ANsPOnWRikZhUKCV+8QtVX/Y/5uf+1WPlSEQ obXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hm6f96tcWI/04d5/JQ1pqOa40uDdpbmZJnTD7wP10Mo=; b=HCSUv7z6HH3iODR4lPQXbD4nii3dls95jgtXvbRmhs5uuQoat2yW+1oIpGtJAS02TY XneX+rmG4Su6gvL7A0mo9fvSZd9rbfohQFdt81ib5ITDMJLmIUjyrKVJk+KCQfe7zvgB +6iabs0rJMhtqj80OSgp3FUXafJu/mkpiuBEXxbQqXaMZYD4t50rBCVMuHzE7ICnvbH9 VJ/B8ZdNHIIO4AibYVXFkyji+yM4yWPNU7U5BfTJZDSqH/U4js7bjNs3HydgvkVds7FE KfUF0+4ZiMAgj4g6OVNIIA8sl1o/WJ/5fwlPZawQoae6mG/15U84lViVjQlhHg5MGsBL 1TbQ== X-Gm-Message-State: ALoCoQl3znkR6NNrjPgWyM41n07TyQSXZyYCyAoaWVhYfGHyLOGq6pMIcxbdpFY2oDYuL+2nJfo0 X-Received: by 10.50.1.67 with SMTP id 3mr43678642igk.6.1412785100956; Wed, 08 Oct 2014 09:18:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.168 with HTTP; Wed, 8 Oct 2014 09:17:40 -0700 (PDT) In-Reply-To: <53B699B4.8000203@kau.se> References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> From: Yuchung Cheng Date: Wed, 8 Oct 2014 09:17:40 -0700 Message-ID: To: Per Hurtig Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/51J17jb2E_Eijy8hAAYpWypguk4 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 16:18:27 -0000 Hi I have been testing the RTO-restart in Linux (with my own implementation) and noticed an interesting issue. Section 4 says: (3) Restart the retransmission timer so that it will expire after "RTO - T_earliest" seconds (for the current value of RTO). What if RTO - T_earliest <= 0? this implies the retransmission is past due and we should timeout? But consider this case: T0: send 3 packets. RTO is 1s T1000: timeout, retransmit packet 1. cwnd=1, rto=2000 T3000: timeout again. retransmit packet 2. cwn=1, rto=4000 T3050: receive ACK1 At this moment, if the connection uses TS-opt, we'll take a new RTT sample and reset rto to 1s (for example). Since T_earliest = 3050, RTO - T_earliest = -2050. Without RTO-restart we'll slow start cwnd from 1 to 2 and retransmit packet 2 and packet 3. But with RTO-restart, if we timeout immediately, we'll reset cwnd to 1 and only retransmit packet 2 b/c cwnd is smaller. I think a better response is to consider the first unacked packet is lost, but not necessarily reset cwnd to 1. bc in this case the connection is making forward progress, and the lost of packet 2 is really caused by a much older event. We can tweak the example so that RTO - T_earliest is not negative but a very small value, and the same issue may occur (e.g., resetting cwnd while connection is making forward progress) On Fri, Jul 4, 2014 at 5:10 AM, Per Hurtig wrote: > Hi all, > > the newest version of the RTO restart (RTOR) draft address the issues > pointed out in Alexander's review. A summary of changes is shown below. > > We've also performed a series of experiments to assess RTOR's performance. > Results from these experiments can be found at: > > http://riteproject.eu/resources/rto-restart/#the-benefits > > o Updated the document to use "RTOR" instead of "RTO Restart" when > refering to the modified algorithm. > > o Moved document terminology to a section of its own. > > o Introduced the rrthresh variable in the terminology section. > > o Added a section to generalize the tracking of outstanding > segments. > > o Updated the algorithm to work when the number of outstanding > segments is less than four and one segment is ready for > transmission, by restarting the timer when new data has been sent. > > o Clarified the relationship between fast retransmit and RTOR. > > o Improved the wording throughout the document. > > > Cheers, > Per > > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt > Date: Fri, 04 Jul 2014 05:02:44 -0700 > From: internet-drafts@ietf.org > To: Andreas Petlund , "Andreas Petlund" > , "Michael Welzl" , Per Hurtig > , Michael Welzl , "Per Hurtig" > , Anna Brunstrom , "Anna > Brunstrom" > > > A new version of I-D, draft-ietf-tcpm-rtorestart-03.txt > has been successfully submitted by Per Hurtig and posted to the > IETF repository. > > Name: draft-ietf-tcpm-rtorestart > Revision: 03 > Title: TCP and SCTP RTO Restart > Document date: 2014-07-04 > Group: tcpm > Pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rtorestart-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ > Htmlized: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-03 > > Abstract: > This document describes a modified algorithm for managing the TCP and > SCTP retransmission timers that provides faster loss recovery when > there is a small amount of outstanding data for a connection. The > modification, RTO Restart (RTOR), allows the transport to restart its > retransmission timer more aggressively in situations where fast > retransmit cannot be used. This enables faster loss detection and > recovery for connections that are short-lived or application-limited. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Oct 8 13:04:13 2014 Return-Path: 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 BBC3E1A00B7 for ; Wed, 8 Oct 2014 13:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rnx_cvyH2a-P for ; Wed, 8 Oct 2014 13:04:10 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CC61A0095 for ; Wed, 8 Oct 2014 13:04:10 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so7696584qga.3 for ; Wed, 08 Oct 2014 13:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FSGIMu3Kmuf9YXyx8XoUD0Ap9mbKJMa62Mx293a7mb4=; b=cdP2tbJm0zsSm+k9T6X/Qa8ggVhN6n9s+8LqGdC2/7BN9sYiurwO3FwE4+alG+jNVx zBtVNnjiM1cZyI71b8cWzyeYJgPqeK3jaPbB1tu/lYiF3vu9zs7RNHvo+PlrlDLiueSy hSNVnXow+Y4NTCKpNlXaKKcpCpt0nUqUjB3u0Cg4/ryCxkPmxkQxCMUfodlpbA39kz2O w/7Zq2A7T6STnwOI88G05lKbspas4ITYFDViZk1cYSpP/IwTNNu0k4vmUnQP/aW9NjTH +e6ldFFjWroWQvmwTXXXLqfp9tBGwoPeTbHFBbOk0CiQbR8PJV8wBqDDPGTYGJ3IUjHe QocQ== MIME-Version: 1.0 X-Received: by 10.224.79.67 with SMTP id o3mr7346312qak.103.1412798649405; Wed, 08 Oct 2014 13:04:09 -0700 (PDT) Received: by 10.140.18.137 with HTTP; Wed, 8 Oct 2014 13:04:09 -0700 (PDT) In-Reply-To: <542B42B9.8070605@isi.edu> References: <542B42B9.8070605@isi.edu> Date: Wed, 8 Oct 2014 13:04:09 -0700 Message-ID: From: Gregory Lebovitz To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bdc9f78a317390504eed1cc Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XhNOj9147_ltAxeNmk9T_R4mFIw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP-AO crypto, SHA-2 MAC_Length (was: "Re: SHA-2 auth draft on TCP-AO") X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 20:04:12 -0000 --047d7bdc9f78a317390504eed1cc Content-Type: text/plain; charset=UTF-8 On Tue, Sep 30, 2014 at 4:54 PM, Joe Touch wrote: > > > On 9/30/2014 4:19 PM, Gregory Lebovitz wrote: > ... > > GML> we clearly didn't say "MUST be 96 bits, no more", but the last > > sentence was meant to guide people toward a truncation of the MAC down > > to 96-bits in order to fit nicely into the -AO option field. > > The -AO option supports any MAC length. The issue is conservation of TCP > header option space and its interaction with other TCP options. > +1, good clarification > > > There was > > security review and consensus that truncating a MAC output > 96 bits > > would be fine. > > "fine" was determined at the time by both Security and Transport, i.e., > Security felt it was large enough for the desired protection and > Transport felt it was small enough to "play nice" with other options. > +1 Gregory > > Joe > -- ---- IETF related email from Gregory M. Lebovitz --047d7bdc9f78a317390504eed1cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 30, 2014 at 4:54 PM, Joe Touch <touch@isi.edu> wrote= :


On 9/30/2014 4:19 PM, Gregory Lebovitz wrote:
...
> GML>=C2=A0 we clearly didn't say "MUST be= 96 bits, no more", but the last
> sentence was meant to guide people toward a truncation of the MAC down=
> to 96-bits in order to fit nicely into the -AO option field.

The -AO option supports any MAC length. The issue is conservation of= TCP
header option space and its interaction with other TCP options.

+1, good clarification
=C2=A0

> There was
> security review and consensus that truncating a MAC output > 96 bit= s
> would be fine.

"fine" was determined at the time by both Security and Tra= nsport, i.e.,
Security felt it was large enough for the desired protection and
Transport felt it was small enough to "play nice" with other opti= ons.

+1
Gregory
=C2= =A0

Joe



-- ----
IETF related email from
Gregory M. Lebovitz
--047d7bdc9f78a317390504eed1cc-- From nobody Thu Oct 9 02:34:27 2014 Return-Path: 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 981EA1ACD00 for ; Thu, 9 Oct 2014 02:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 LiszUX6OcNXF for ; Thu, 9 Oct 2014 02:34:22 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id 586BE1ACD10 for ; Thu, 9 Oct 2014 02:34:21 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.22) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 54168692021EF256; Thu, 9 Oct 2014 12:34:14 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> Date: Thu, 9 Oct 2014 12:34:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> To: Yuchung Cheng X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kj06cLT09LIrQE3iHQ9Nf4BGAZg Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 09:34:24 -0000 Hi, Thanks, Yuchung, for bringing this up. It reminds me of an old note I = sent to the list quite a long while ago: I think it would be good if the = algorithm was designed so that it cannot (even in theory) result in = negative RTO values. The most straightforward way to fix this would be = to include some kind of max(RTO - T_earliest, some_threshold) guard in = the algorithm. It might not protect against spurious timeouts, but at = least would keep the values in sensible range. - Pasi On 08 Oct 2014, at 19:17, Yuchung Cheng wrote: > Hi >=20 > I have been testing the RTO-restart in Linux (with my own > implementation) and noticed an interesting issue. >=20 > Section 4 says: >=20 > (3) Restart the retransmission timer so that it will expire = after > "RTO - T_earliest" seconds (for the current value of RTO). >=20 > What if RTO - T_earliest <=3D 0? this implies the retransmission is > past due and we should timeout? >=20 > But consider this case: > T0: send 3 packets. RTO is 1s > T1000: timeout, retransmit packet 1. cwnd=3D1, rto=3D2000 > T3000: timeout again. retransmit packet 2. cwn=3D1, rto=3D4000 > T3050: receive ACK1 >=20 > At this moment, if the connection uses TS-opt, we'll take a new RTT > sample and reset rto to 1s (for example). > Since T_earliest =3D 3050, RTO - T_earliest =3D -2050. >=20 > Without RTO-restart we'll slow start cwnd from 1 to 2 and retransmit > packet 2 and packet 3. > But with RTO-restart, if we timeout immediately, we'll reset cwnd to 1 > and only retransmit packet 2 b/c cwnd is smaller. >=20 > I think a better response is to consider the first unacked packet is > lost, but not necessarily reset cwnd to 1. bc in this > case the connection is making forward progress, and the lost of packet > 2 is really caused by a much older event. >=20 > We can tweak the example so that RTO - T_earliest is not negative but > a very small value, and the same issue may occur (e.g., resetting cwnd > while connection is making forward progress) >=20 >=20 > On Fri, Jul 4, 2014 at 5:10 AM, Per Hurtig wrote: >> Hi all, >>=20 >> the newest version of the RTO restart (RTOR) draft address the issues >> pointed out in Alexander's review. A summary of changes is shown = below. >>=20 >> We've also performed a series of experiments to assess RTOR's = performance. >> Results from these experiments can be found at: >>=20 >> http://riteproject.eu/resources/rto-restart/#the-benefits >>=20 >> o Updated the document to use "RTOR" instead of "RTO Restart" when >> refering to the modified algorithm. >>=20 >> o Moved document terminology to a section of its own. >>=20 >> o Introduced the rrthresh variable in the terminology section. >>=20 >> o Added a section to generalize the tracking of outstanding >> segments. >>=20 >> o Updated the algorithm to work when the number of outstanding >> segments is less than four and one segment is ready for >> transmission, by restarting the timer when new data has been sent. >>=20 >> o Clarified the relationship between fast retransmit and RTOR. >>=20 >> o Improved the wording throughout the document. >>=20 >>=20 >> Cheers, >> Per >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for = draft-ietf-tcpm-rtorestart-03.txt >> Date: Fri, 04 Jul 2014 05:02:44 -0700 >> From: internet-drafts@ietf.org >> To: Andreas Petlund , "Andreas Petlund" >> , "Michael Welzl" , Per = Hurtig >> , Michael Welzl , "Per Hurtig" >> , Anna Brunstrom , "Anna >> Brunstrom" >>=20 >>=20 >> A new version of I-D, draft-ietf-tcpm-rtorestart-03.txt >> has been successfully submitted by Per Hurtig and posted to the >> IETF repository. >>=20 >> Name: draft-ietf-tcpm-rtorestart >> Revision: 03 >> Title: TCP and SCTP RTO Restart >> Document date: 2014-07-04 >> Group: tcpm >> Pages: 13 >> URL: = http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rtorestart-03.txt >> Status: = https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ >> Htmlized: = http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-03 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rtorestart-03 >>=20 >> Abstract: >> This document describes a modified algorithm for managing the TCP = and >> SCTP retransmission timers that provides faster loss recovery when >> there is a small amount of outstanding data for a connection. The >> modification, RTO Restart (RTOR), allows the transport to restart = its >> retransmission timer more aggressively in situations where fast >> retransmit cannot be used. This enables faster loss detection and >> recovery for connections that are short-lived or = application-limited. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Oct 9 10:33:09 2014 Return-Path: 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 DF56A1AD3E8 for ; Thu, 9 Oct 2014 10:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 d1XFWnP8Yxbc for ; Thu, 9 Oct 2014 10:33:05 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3941AD3E7 for ; Thu, 9 Oct 2014 10:33:05 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id a13so8191165igq.1 for ; Thu, 09 Oct 2014 10:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ShQR6yQeSJUIxSLWQWmogQqkjktnkkttzxrrBuXPyQI=; b=PGjewO8BGpCkydsp/ncByVyrnXgl8YlcGqi3D7bERhuClOxHQ5KTslQ07b5ZxGwtln WvFm1aPTTVU2/Uuu3KQ7ApVcbWFGGJWpLlH2zZssxs/ZUR7P+2fekfOJtnZUekfocjq3 wY228kcIgxu0vHCn+AR+MDM9zSJR26zovJlpDDz31G1FjMB2aSpAemTbhhiRWLa8E59Y 3lc94cKL5cmIyLA/bnGiGOXISaTtsNLwqMB0CB95F+rFWUzg8t+EoK4gnyco2/f85s8N Rw0ObsqQmzsxy+7dnZCq332heD3Xh6GSA9ZhJtHl9tt77wxkG7HQWquz3UxEHvuKZT2v s4Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ShQR6yQeSJUIxSLWQWmogQqkjktnkkttzxrrBuXPyQI=; b=mm/TK+9YDtYAgltXJ1dp0oBELr7I3mePo5EcgztyeosM5LEeT+ySk+YBDr27VwIuPn 6iq8q5xm2RUc9/RWRrkoSg7X5O26NrdQEqtflW6SKKNSHCMd4Cn5mMa3cTK6Ti720tqR 89yQFZhPGeHfrv3IJM3rPGKJ9+ZGIFrQED1glakRj66Z6vQkol7dAS3StWoITMf+D2vO gK49cdjDo8hmL1p9aIW+vYPMC+wenZWp31uW6h5U/R8aOZG54boW9Ny91KG8RLKqffLY C5+9wbz9Y3oXCWG6N6gCvibjW77hFhjzVpvPksFu+Lfg+8EtLgnCRdMleqnAG99MMQZi ZH7Q== X-Gm-Message-State: ALoCoQl03iTkj57C6x3zvi/dpA2XBrAEBMq1e9MOTH4pj+kBhwbACOhJpp//cL4MdU7KaAk3rwzJ X-Received: by 10.50.66.36 with SMTP id c4mr58569915igt.48.1412875984814; Thu, 09 Oct 2014 10:33:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.168 with HTTP; Thu, 9 Oct 2014 10:32:24 -0700 (PDT) In-Reply-To: References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> From: Yuchung Cheng Date: Thu, 9 Oct 2014 10:32:24 -0700 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yOeUgvQQ9ZKK8KquQWjqGRhABQE Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 17:33:08 -0000 On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti wrot= e: > Hi, > > Thanks, Yuchung, for bringing this up. It reminds me of an old note I sen= t to the list quite a long while ago: I think it would be good if the algor= ithm was designed so that it cannot (even in theory) result in negative RTO= values. The most straightforward way to fix this would be to include some = kind of max(RTO - T_earliest, some_threshold) guard in the algorithm. It mi= ght not protect against spurious timeouts, but at least would keep the valu= es in sensible range. This would work but it might reduce the benefit (and adding yet another magic threshold). A negative value is a strong signal that the first unacked packet is lost. The problem in my case is the reaction is not appropriate (reset cwnd again) because we have just make some forward progress. IMO cwnd should be reset if nothing has been delivered (no (s)acks) for the whole RTO. It's similar philosophy like fast recovery and tail loss probe. > > - Pasi > > > On 08 Oct 2014, at 19:17, Yuchung Cheng wrote: > >> Hi >> >> I have been testing the RTO-restart in Linux (with my own >> implementation) and noticed an interesting issue. >> >> Section 4 says: >> >> (3) Restart the retransmission timer so that it will expire after >> "RTO - T_earliest" seconds (for the current value of RTO). >> >> What if RTO - T_earliest <=3D 0? this implies the retransmission is >> past due and we should timeout? >> >> But consider this case: >> T0: send 3 packets. RTO is 1s >> T1000: timeout, retransmit packet 1. cwnd=3D1, rto=3D2000 >> T3000: timeout again. retransmit packet 2. cwn=3D1, rto=3D4000 >> T3050: receive ACK1 >> >> At this moment, if the connection uses TS-opt, we'll take a new RTT >> sample and reset rto to 1s (for example). >> Since T_earliest =3D 3050, RTO - T_earliest =3D -2050. >> >> Without RTO-restart we'll slow start cwnd from 1 to 2 and retransmit >> packet 2 and packet 3. >> But with RTO-restart, if we timeout immediately, we'll reset cwnd to 1 >> and only retransmit packet 2 b/c cwnd is smaller. >> >> I think a better response is to consider the first unacked packet is >> lost, but not necessarily reset cwnd to 1. bc in this >> case the connection is making forward progress, and the lost of packet >> 2 is really caused by a much older event. >> >> We can tweak the example so that RTO - T_earliest is not negative but >> a very small value, and the same issue may occur (e.g., resetting cwnd >> while connection is making forward progress) >> >> >> On Fri, Jul 4, 2014 at 5:10 AM, Per Hurtig wrote: >>> Hi all, >>> >>> the newest version of the RTO restart (RTOR) draft address the issues >>> pointed out in Alexander's review. A summary of changes is shown below. >>> >>> We've also performed a series of experiments to assess RTOR's performan= ce. >>> Results from these experiments can be found at: >>> >>> http://riteproject.eu/resources/rto-restart/#the-benefits >>> >>> o Updated the document to use "RTOR" instead of "RTO Restart" when >>> refering to the modified algorithm. >>> >>> o Moved document terminology to a section of its own. >>> >>> o Introduced the rrthresh variable in the terminology section. >>> >>> o Added a section to generalize the tracking of outstanding >>> segments. >>> >>> o Updated the algorithm to work when the number of outstanding >>> segments is less than four and one segment is ready for >>> transmission, by restarting the timer when new data has been sent. >>> >>> o Clarified the relationship between fast retransmit and RTOR. >>> >>> o Improved the wording throughout the document. >>> >>> >>> Cheers, >>> Per >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt >>> Date: Fri, 04 Jul 2014 05:02:44 -0700 >>> From: internet-drafts@ietf.org >>> To: Andreas Petlund , "Andreas Petlund" >>> , "Michael Welzl" , Per Hurtig >>> , Michael Welzl , "Per Hurtig" >>> , Anna Brunstrom , "Anna >>> Brunstrom" >>> >>> >>> A new version of I-D, draft-ietf-tcpm-rtorestart-03.txt >>> has been successfully submitted by Per Hurtig and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-tcpm-rtorestart >>> Revision: 03 >>> Title: TCP and SCTP RTO Restart >>> Document date: 2014-07-04 >>> Group: tcpm >>> Pages: 13 >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rtorestart-03.= txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtores= tart/ >>> Htmlized: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-0= 3 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rtorestart-03 >>> >>> Abstract: >>> This document describes a modified algorithm for managing the TCP and >>> SCTP retransmission timers that provides faster loss recovery when >>> there is a small amount of outstanding data for a connection. The >>> modification, RTO Restart (RTOR), allows the transport to restart its >>> retransmission timer more aggressively in situations where fast >>> retransmit cannot be used. This enables faster loss detection and >>> recovery for connections that are short-lived or application-limited. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Oct 9 11:49:24 2014 Return-Path: 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 59D6D1A0350 for ; Thu, 9 Oct 2014 11:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 ujeg40EZ_dkN for ; Thu, 9 Oct 2014 11:49:21 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD5A1A0313 for ; Thu, 9 Oct 2014 11:49:21 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 54168692022BF106; Thu, 9 Oct 2014 21:49:14 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: Date: Thu, 9 Oct 2014 21:49:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <87CDBDF6-27E4-44DE-BE12-CAA2F4CC84F9@iki.fi> References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> To: Yuchung Cheng X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/IRqyPw7Vr69AJB0bRaxkPfiG3tY Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 18:49:23 -0000 On 09 Oct 2014, at 20:32, Yuchung Cheng wrote: > On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti = wrote: >> Hi, >>=20 >> Thanks, Yuchung, for bringing this up. It reminds me of an old note I = sent to the list quite a long while ago: I think it would be good if the = algorithm was designed so that it cannot (even in theory) result in = negative RTO values. The most straightforward way to fix this would be = to include some kind of max(RTO - T_earliest, some_threshold) guard in = the algorithm. It might not protect against spurious timeouts, but at = least would keep the values in sensible range. >=20 > This would work but it might reduce the benefit (and adding yet > another magic threshold). A negative value is a > strong signal that the first unacked packet is lost. The problem in my > case is the reaction is not appropriate (reset cwnd again) because we > have just make some forward progress. Right, magic numbers are not nice (but it could be 0, just to prevent = negatives). Or then the draft should otherwise discuss handling of = negative values, and make it clear if there might be such. Some = implementations might define RTO as unsigned, in which case a negative = value becomes very large value=85 - Pasi From nobody Thu Oct 9 14:03:44 2014 Return-Path: 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 94ED41A882B for ; Thu, 9 Oct 2014 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 3GLdUAVZh2QA for ; Thu, 9 Oct 2014 14:03:40 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id BBE5D1A8827 for ; Thu, 9 Oct 2014 14:03:39 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5419499101F6314F for tcpm@ietf.org; Fri, 10 Oct 2014 00:03:38 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 10 Oct 2014 00:03:37 +0300 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Dc7bLPepmDrgrvDqrcsiOuqp8N8 Subject: [tcpm] EDO implementation issues X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:03:43 -0000 Hi, To refresh my rusty kernel hacking skills, I took a shot at sketching a = Linux implementation of draft-ietf-tcpm-tcp-edo-00.txt . In case anyone = is interested, the current (work-in-progress) state is at = https://github.com/PasiSa/linux . Currently the only use is to extend = max nr. of SACK blocks to 8, and a test feature that adds NOP = options to the segment. EDO can be enabled with =91sysctl -w = net.ipv4.tcp_edo=3D1=92. Larger values turn on the test feature that = will add the given number of NOP options before possible timestamps and = SACKs. Be warned that the implementation is not fully working yet (and quite = quickly made), but I wanted to share some observations at this point = nevertheless. In my tests, for data offset values up to 72 or so things = are ok, but beyond that the receiver option handling starts facing = problems. I haven=92t fully analyzed this yet, but I believe the issue = is that incoming data is not always in contiguous memory area in = sk_buffs, but can be stored in multiple =91page buffers=92. Until now = TCP header processing has been easy, because the protocol headers have = easily fitted in the first part of the sk_buff. With extended option = space, the header processing becomes a fair bit more complicated, = because the option parsing implementation needs to follow through the = page buffers (that may be split in the middle of an option). But my = Linux kernel expertise is limited, so people more knowledgeable of the = kernel can correct me, if the above did not make sense. Anyways, I think = BSD mbufs might have a similar property. (I=92m happy to discuss and be educated about this more, and get = implementation feedback, but detailed implementation discussion should = be taken off-list, as this is not a Linux dev mailing list) A couple of other comments that came up while I was working on this: * I didn=92t want to pick random option numbers, so I decided to use = ExID. In case someone else is also interested in trying an EDO = implementation, would it make sense to specify common ExIDs in the = draft, with a note saying that the ExIDs are intended as temporary, and = actual codepoints will be assigned later? * "The EDO Header_length SHOULD be a multiple of 4 to simplify = processing." =97=20 how about then just using 32-bit units, similar to the original data = offset? Although one-byte precision might become useful somewhere, who = knows. * If incoming EDO option has invalid values, for example more than the = segment length, or less than the TCP header data offset, what should be = done in that case? Just ignoring the option might not be safe, because = the (buggy) sender might have assumed a changed data offset. So best = thing might be to drop the entire segment in that case, no? The draft = should say more about this (with normative language). * "The EDO length option is required in SYN/ACKs when confirming support for EDO. The SYN/ACK thus can take advantage of EDO, using it to extend its option space. If such extension is not required, then EDO would be equal to 4 * Data Offset (i.e., EDO would indicate in bytes the same length indicated by Data Offset in words).=94 =97 = but on the other hand, the text later says that EDO should be the last = option covered by TCP DO. So how about just making the TCP data offset = always point to the end of the EDO length option when such is present, = also in SYN/ACKs? - Pasi From nobody Thu Oct 9 14:33:15 2014 Return-Path: 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 CF7031A88AD for ; Thu, 9 Oct 2014 14:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 3eFDqrOl_rDp for ; Thu, 9 Oct 2014 14:33:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E34A1A88AE for ; Thu, 9 Oct 2014 14:33:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s99LWOSA028048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Oct 2014 14:32:25 -0700 (PDT) Message-ID: <5436FEE8.106@isi.edu> Date: Thu, 09 Oct 2014 14:32:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Pasi Sarolahti , "tcpm@ietf.org Extensions" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/Oc7SIzYMrQY5j1DsLWoaHETTgcA Cc: Harry Trieu Subject: Re: [tcpm] EDO implementation issues X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:33:14 -0000 Hi, all, FWIW, we have a parallel implementation experiment here at ISI as a student project (Harry Trieu - cc'd because he's not yet on the list, with Ted Faber co-advising), also in Linux. We'd be glad to do interoperability testing once we're further along. Comments below... Joe On 10/9/2014 2:03 PM, Pasi Sarolahti wrote: > Hi, > > To refresh my rusty kernel hacking skills, I took a shot at > sketching a Linux implementation of draft-ietf-tcpm-tcp-edo-00.txt . > In case anyone is interested, the current (work-in-progress) state is > at https://github.com/PasiSa/linux . Currently the only use is to > extend max nr. of SACK blocks to 8, and a test feature that adds > NOP options to the segment. EDO can be enabled with ‘sysctl -w > net.ipv4.tcp_edo=1’. Larger values turn on the test feature that > will add the given number of NOP options before possible timestamps > and SACKs. We created another JUNK option (for testing purposes only) that can be configured with any length, basically to fill the option space for similar reasons. Our version is already per-connection configurable, and is planned to have a similar system-wide default. > Be warned that the implementation is not fully working yet (and quite > quickly made), but I wanted to share some observations at this point > nevertheless. In my tests, for data offset values up to 72 or so > things are ok, but beyond that the receiver option handling starts > facing problems. I haven’t fully analyzed this yet, but I believe > the issue is that incoming data is not always in contiguous memory > area in sk_buffs, but can be stored in multiple ‘page buffers’. Until > now TCP header processing has been easy, because the protocol > headers have easily fitted in the first part of the sk_buff. With > extended option space, the header processing becomes a fair bit more > complicated, because the option parsing implementation needs to > follow through the page buffers (that may be split in the middle of > an option). But my Linux kernel expertise is limited, so people more > knowledgeable of the kernel can correct me, if the above did not make > sense. Anyways, I think BSD mbufs might have a similar property. Good to know; we haven't tripped over that issue yet. For now, we've been trying to just trip over the DO boundary by one word (i.e., TCP+options = 64 bytes), but the final implementation should allow the total size to grow to MSS-4 (if it is MSS, you might end up never having room for any data). > (I’m happy to discuss and be educated about this more, and get > implementation feedback, but detailed implementation discussion should > be taken off-list, as this is not a Linux dev mailing list) > > A couple of other comments that came up while I was working on this: > > * I didn’t want to pick random option numbers, so I decided to use > ExID. In case someone else is also interested in trying an EDO > implementation, would it make sense to specify common ExIDs in the > draft, with a note saying that the ExIDs are intended as temporary, and > actual codepoints will be assigned later? Yes. Let's use the 16-bit one that matches the name: 0x0ED0 I'll grab that in the ExID registry, and we can mark it as deprecated later presuming an option codepoint is assigned. > * "The EDO Header_length SHOULD be a multiple of 4 to simplify > processing." — how about then just using 32-bit units, similar to the > original data offset? Although one-byte precision might become useful > somewhere, who knows. Sure. > * If incoming EDO option has invalid values, for example more than > the segment length, or less than the TCP header data offset, what > should be done in that case? Just ignoring the option might not be > safe, because the (buggy) sender might have assumed a changed data > offset. So best thing might be to drop the entire segment in that > case, no? The draft should say more about this (with normative > language). Silently drop. Yes, we'll add the language. > * "The EDO length option is required in SYN/ACKs when confirming > support for EDO. The SYN/ACK thus can take advantage of EDO, using it > to extend its option space. That is pending some points raised by Bob Briscoe. We may want to allow that or might want to avoid it in the SYN-ACK but allow it in later packets (i.e., it may be important to have all segments where SYN is set to avoid using EDO). However, for now let's assume it's OK (it either will be or not, but the rest of the answer below won't change)... > If such extension is not required, then EDO would be equal to 4 * > Data Offset (i.e., EDO would indicate in bytes the same length > indicated by Data Offset in words).” — but on the other hand, the > text later says that EDO should be the last option covered by TCP DO. > So how about just making the TCP data offset always point to the end > of the EDO length option when such is present, also in SYN/ACKs? Yes - we're considering making EDO mandatory once enabled, and if that's true (in any segment), then EDO should point to the same place as DO -- and since we're making EDO count in words, the two would just have the same value. Joe From nobody Fri Oct 10 01:07:57 2014 Return-Path: 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 AEB021A1B78 for ; Fri, 10 Oct 2014 01:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, SPF_NEUTRAL=0.779] autolearn=no 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 RSUvNbSqQc95 for ; Fri, 10 Oct 2014 01:07:51 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 7F84D1A1B68 for ; Fri, 10 Oct 2014 01:07:51 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.22) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 542527360142E644; Fri, 10 Oct 2014 11:07:38 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <5436FEE8.106@isi.edu> Date: Fri, 10 Oct 2014 11:07:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436FEE8.106@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ArgrXSupxKYoGRiWT5FibWDosuA Cc: "tcpm@ietf.org Extensions" , Harry Trieu Subject: Re: [tcpm] EDO implementation issues X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 08:07:53 -0000 On 10 Oct 2014, at 00:32, Joe Touch wrote: > Hi, all, >=20 > FWIW, we have a parallel implementation experiment here at ISI as a > student project (Harry Trieu - cc'd because he's not yet on the list, > with Ted Faber co-advising), also in Linux. We'd be glad to do > interoperability testing once we're further along. Ah, nice to hear! My cycles are quite limited on this, but I=92d be = happy to collaborate, and hopefully it is possible for you to make your = code available, once you get to that point. >> Be warned that the implementation is not fully working yet (and quite >> quickly made), but I wanted to share some observations at this point >> nevertheless. In my tests, for data offset values up to 72 or so >> things are ok, but beyond that the receiver option handling starts=20 >> facing problems. I haven=92t fully analyzed this yet, but I believe >> the issue is that incoming data is not always in contiguous memory >> area in sk_buffs, but can be stored in multiple =91page buffers=92. = Until >> now TCP header processing has been easy, because the protocol >> headers have easily fitted in the first part of the sk_buff. With >> extended option space, the header processing becomes a fair bit more=20= >> complicated, because the option parsing implementation needs to=20 >> follow through the page buffers (that may be split in the middle of=20= >> an option). But my Linux kernel expertise is limited, so people more=20= >> knowledgeable of the kernel can correct me, if the above did not make >> sense. Anyways, I think BSD mbufs might have a similar property. >=20 > Good to know; we haven't tripped over that issue yet. For now, we've > been trying to just trip over the DO boundary by one word (i.e., > TCP+options =3D 64 bytes), but the final implementation should allow = the > total size to grow to MSS-4 (if it is MSS, you might end up never = having > room for any data). And I already got off-list response from Ilpo J=E4rvinen (thanks!), that = the skbuff operations have tools to tackle this issue (pskb_may_pull), = but it may get quite expensive (in worst case memory reallocation and = copying). >> (I=92m happy to discuss and be educated about this more, and get >> implementation feedback, but detailed implementation discussion = should >> be taken off-list, as this is not a Linux dev mailing list) >>=20 >> A couple of other comments that came up while I was working on this: >>=20 >> * I didn=92t want to pick random option numbers, so I decided to use >> ExID. In case someone else is also interested in trying an EDO >> implementation, would it make sense to specify common ExIDs in the >> draft, with a note saying that the ExIDs are intended as temporary, = and >> actual codepoints will be assigned later? >=20 > Yes. Let's use the 16-bit one that matches the name: 0x0ED0 >=20 > I'll grab that in the ExID registry, and we can mark it as deprecated > later presuming an option codepoint is assigned. Works for me, and will update my code accordingly. (and I only now = realized that it is in fact only one codepoint that is needed, because = length can be used to distinguish between the two) - Pasi From nobody Fri Oct 10 11:17:49 2014 Return-Path: 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 C75A71A924E for ; Fri, 10 Oct 2014 11:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TxPTanzvpHCG for ; Fri, 10 Oct 2014 11:17:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB311A9245 for ; Fri, 10 Oct 2014 11:17:46 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9AIH1an015442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Oct 2014 11:17:01 -0700 (PDT) Message-ID: <5438229D.1040105@isi.edu> Date: Fri, 10 Oct 2014 11:17:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Pasi Sarolahti References: <5436FEE8.106@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/8f96Kz-T39AReaDPifDc0D3De9g Cc: "tcpm@ietf.org Extensions" , Harry Trieu Subject: Re: [tcpm] EDO implementation issues X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 18:17:48 -0000 On 10/10/2014 1:07 AM, Pasi Sarolahti wrote: > > On 10 Oct 2014, at 00:32, Joe Touch wrote: ... >>> ...In my tests, for data offset values up to 72 or so >>> things are ok, but beyond that the receiver option handling starts >>> facing problems. I haven’t fully analyzed this yet, but I believe >>> the issue is that incoming data is not always in contiguous memory >>> area in sk_buffs, but can be stored in multiple ‘page buffers’... > > And I already got off-list response from Ilpo Järvinen (thanks!), > that the skbuff operations have tools to tackle this issue > (pskb_may_pull), but it may get quite expensive (in worst case memory > reallocation and copying). Good to know. I'll note that in an update to the doc. IMO, that leads to a broad recommendation to be conservative in using this extension space but I don't think it'd be appropriate to add artificial, implementation-dependent limits. Joe From nobody Sun Oct 12 10:47:53 2014 Return-Path: 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 36A4F1A6FA8 for ; Sun, 12 Oct 2014 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 8ps_DTwIeIMY for ; Sun, 12 Oct 2014 10:47:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1145C1A6F91 for ; Sun, 12 Oct 2014 10:47:50 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2255CA508F6AC for ; Sun, 12 Oct 2014 17:47:39 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9CHlg9c000589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 12 Oct 2014 19:47:42 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 12 Oct 2014 19:47:42 +0200 From: "Scharf, Michael (Michael)" To: tcpm IETF list Thread-Topic: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Thread-Index: AQHP5L7GGPmkk+wBHEeBn1bVxwAc85wsvzuQ Date: Sun, 12 Oct 2014 17:47:41 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1667361C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/f18lvfxw8gtM389Kzzi6p6XAve0 Subject: [tcpm] FW: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2014 17:47:52 -0000 W0ZvcndhcmRlZCBvbiBiZWhhbGYgb2YgdGhlIHdvcmtzaG9wIG9yZ2FuaXplcnNdDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCklBQiBXb3Jr c2hvcCBvbiBTdGFjayBFdm9sdXRpb24gaW4gYSBNaWRkbGVib3ggSW50ZXJuZXQgKFNFTUkpDQoy Ni0yNyBKYW51YXJ5IDIwMTUg4oCTIEVUSCBaw7xyaWNoLCBTd2l0emVybGFuZA0KDQpUaGUgSW50 ZXJuZXTigJlzIHRyYW5zcG9ydCBsYXllciBoYXMgb3NzaWZpZWQsIHNxdWVlemVkIGJldHdlZW4g bmFycm93DQppbnRlcmZhY2VzIChmcm9tIEJTRCBzb2NrZXRzIHRvIHBzZXVkby10cmFuc3BvcnQg b3ZlciBIVFRQUykgYW5kDQppbmNyZWFzaW5nIGluLW5ldHdvcmsgbW9kaWZpY2F0aW9uIG9mIHRy YWZmaWMgYnkgbWlkZGxlYm94ZXMgdGhhdCBtYWtlDQphc3N1bXB0aW9ucyBhYm91dCB0aGUgcHJv dG9jb2xzIHJ1bm5pbmcgdGhyb3VnaCB0aGVtLiBUaGlzIG9zc2lmaWNhdGlvbg0KbWFrZXMgaXQg ZGlmZmljdWx0IHRvIGlubm92YXRlIGluIHRoZSB0cmFuc3BvcnQgbGF5ZXIsIHRocm91Z2ggdGhl DQpkZXBsb3ltZW50IG9mIG5ldyBwcm90b2NvbHMgb3IgdGhlIGV4dGVuc2lvbiBvZiBleGlzdGlu ZyBvbmVzLiBBdCB0aGUNCnNhbWUgdGltZSwgZW1lcmdpbmcgYXBwbGljYXRpb25zIHJlcXVpcmUg ZnVuY3Rpb25hbGl0eSB0aGF0IGV4aXN0aW5nDQpwcm90b2NvbHMgY2FuIHByb3ZpZGUgb25seSBp bmVmZmljaWVudGx5LCBpZiBhdCBhbGwuDQoNClRvIGJlZ2luIHRvIGFkZHJlc3MgdGhpcyBwcm9i bGVtLCB0aGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkIChJQUIpLA0Kd2l0aGluIHRoZSBz Y29wZSBvZiBpdHMgSVAgU3RhY2sgRXZvbHV0aW9uIFByb2dyYW0sIGlzIG9yZ2FuaXppbmcgYQ0K d29ya3Nob3AgdG8gZGlzY3VzcyBhcHByb2FjaGVzIHRvIGRlLW9zc2lmeWluZyB0cmFuc3BvcnQs IGVzcGVjaWFsbHkNCndpdGggcmVzcGVjdCB0byBpbnRlcmFjdGlvbnMgd2l0aCBtaWRkbGVib3hl cyBhbmQgbmV3IG1ldGhvZHMgZm9yDQppbXBsZW1lbnRpbmcgdHJhbnNwb3J0IHByb3RvY29scy4g UmVjb2duaXppbmcgdGhhdCB0aGUgZW5kLXRvLWVuZA0KcHJpbmNpcGxlIGhhcyBsb25nIGJlZW4g Y29tcHJvbWlzZWQsIHdlIHN0YXJ0IHdpdGggdGhlIGZ1bmRhbWVudGFsDQpxdWVzdGlvbiBvZiBt YXRjaGluZyBwYXRocyB0aHJvdWdoIHRoZSBJbnRlcm5ldCB3aXRoIGNlcnRhaW4NCmNoYXJhY3Rl cmlzdGljcyB0byBhcHBsaWNhdGlvbiBhbmQgdHJhbnNwb3J0IHJlcXVpcmVtZW50cy4gV2hpY2gg cGF0aHMNCnRocm91Z2ggdGhlIEludGVybmV0IGFyZSBhY3R1YWxseSBhdmFpbGFibGUgdG8gYXBw bGljYXRpb25zPyBXaGljaA0KdHJhbnNwb3J0cyBjYW4gYmUgdXNlZCBvdmVyIHRoZXNlIHBhdGhz PyBIb3cgY2FuIGFwcGxpY2F0aW9ucyBjb29wZXJhdGUNCndpdGggbmV0d29yayBlbGVtZW50cyB0 byBpbXByb3ZlIHBhdGggZXN0YWJsaXNobWVudCBhbmQgZGlzY292ZXJ5PyBDYW4NCmNvbW1vbiB0 cmFuc3BvcnQgZnVuY3Rpb25hbGl0eSBhbmQgc3RhbmRhcmRpemF0aW9uIGhlbHAgYXBwbGljYXRp b24NCmRldmVsb3BlcnMgdG8gaW1wbGVtZW50IGFuZCBkZXBsb3kgc3VjaCBhcHByb2FjaGVzIGlu IHRvZGF54oCZcyBJbnRlcm5ldD8NCkNvdWxkIGNvb3BlcmF0aXZlIGFwcHJvYWNoZXMgZ2l2ZSB1 cyBhIHdheSB0byByZWJhbGFuY2UgdGhlIEludGVybmV0DQpiYWNrIHRvd2FyZCBpdHMgZW5kLXRv LWVuZCByb290cz8NCg0KVG9waWNzDQoNCkZvciB0aGlzIHdvcmtzaG9wIHdlIHdvdWxkIGxpa2Ug dG8gY29uc2lkZXIgdG9waWNzIHRoYXQgc3BlYWsgdG8gdGhlc2UNCnF1ZXN0aW9ucywgaW5jbHVk aW5nIHRoZSBmb2xsb3dpbmc6DQoNCi0gRGV2ZWxvcG1lbnQgYW5kIGRlcGxveW1lbnQgb2YgdHJh bnNwb3J0LWxpa2UgZmVhdHVyZXMgaW4gYXBwbGljYXRpb24tDQogICAgbGF5ZXIgcHJvdG9jb2xz DQotIE1ldGhvZHMgZm9yIGRpc2NvdmVyeSBvZiBwYXRoIGNoYXJhY3RlcmlzdGljcyBhbmQgcHJv dG9jb2wNCiAgICBhdmFpbGFiaWxpdHkgYWxvbmcgYSBwYXRoDQotIE1ldGhvZHMgZm9yIG1pZGRs ZWJveCBkZXRlY3Rpb24gYW5kIGNoYXJhY3Rlcml6YXRpb24gb2YgbWlkZGxlYm94DQogICAgYmVo YXZpb3IgYW5kIGZ1bmN0aW9uYWxpdHkNCi0gTWV0aG9kcyBmb3IgTkFUIGFuZCBtaWRkbGVib3gg dHJhdmVyc2FsIGluIHRoZSBlc3RhYmxpc2htZW50IG9mIGVuZC0NCiAgICB0by1lbmQgcGF0aHMN Ci0gTWVjaGFuaXNtcyBmb3IgY29vcGVyYXRpdmUgcGF0aC1lbmRwb2ludCBzaWduYWxpbmcsIGFu ZCBsZXNzb25zDQogICAgbGVhcm5lZCBmcm9tIGV4aXN0aW5nIGFwcHJvYWNoZXMNCi0gRWNvbm9t aWMgY29uc2lkZXJhdGlvbnMgYW5kIGluY2VudGl2ZXMgZm9yIGNvb3BlcmF0aW9uIGluIG1pZGRs ZWJveA0KICAgIGRlcGxveW1lbnQNCg0KV2Ugd2lsbCBleHBsaWNpdGx5IGZvY3VzIG9uIGFwcHJv YWNoZXMgdGhhdCBhcmUgaW5jcmVtZW50YWxseSBkZXBsb3lhYmxlDQp3aXRoaW4gdGhlIHByZXNl bnQgSW50ZXJuZXQuDQoNClRoZSBvdXRjb21lIG9mIHRoZSB3b3Jrc2hvcCB3aWxsIGJlIGFyY2hp dGVjdHVyYWwgYW5kIGVuZ2luZWVyaW5nDQpndWlkYW5jZSBvbiBmdXR1cmUgd29yayBpbiB0aGUg YXJlYSwgcHVibGlzaGVkIGFzIGFuIElBQiB3b3Jrc2hvcA0KcmVwb3J0LCBiYXNlZCBvbiBkaXNj dXNzaW9uIG9mIHByb3Bvc2VkIGFwcHJvYWNoZXM7IGZ1dHVyZSB3b3JrIHdpbGwgYmUNCnB1cnN1 ZWQgd2l0aGluIHRoZSBJQUIgU3RhY2sgRXZvbHV0aW9uIFByb2dyYW0uIFdlIHdpbGwgYWxzbyBl eHBsb3JlDQpwb3NzaWJsZSBhcmVhcyBmb3Igc3RhbmRhcmRpemF0aW9uLCBlLmcuIG5ldyBwcm90 b2NvbHMgdGhhdCBzZXBhcmF0ZQ0Kc2lnbmFsaW5nIHRvIGFuZCBmcm9tIG9uLXBhdGggZGV2aWNl cyBhbmQgY29tbW9uIHRyYW5zcG9ydCBzZW1hbnRpY3MNCmZyb20gdGhlIHJlc3Qgb2YgdGhlIHRy YW5zcG9ydCBwcm90b2NvbDsgYW5kIGZvciBnZW5lcmFsIGd1aWRhbmNlLCBlLmcuDQpob3cgdHJh bnNwb3J0cyBhcyB3ZWxsIGFzIG1pZGRsZWJveGVzIGNhbiBiZSBkZXNpZ25lZCBhbmQgZGVwbG95 ZWQgdG8NCmFjaGlldmUgdGhlc2UgZ29hbHMuDQoNClN1Ym1pc3Npb24gSW5zdHJ1Y3Rpb25zDQoN CkF0dGVuZGFuY2UgYXQgdGhlIHdvcmtzaG9wIGlzIGJ5IGludml0YXRpb24uIFByb3NwZWN0aXZl IHBhcnRpY2lwYW50cw0KYXJlIGludml0ZWQgdG8gc3VibWl0IHNob3J0IHBvc2l0aW9uIHBhcGVy cyBvdXRsaW5pbmcgdGhlaXIgdmlld3Mgb24gb25lDQpvciBtb3JlIHRvcGljcyByZWxhdGVkIHRv IHRoZSBzY29wZSBvZiB0aGUgd29ya3Nob3AuIFBvc2l0aW9uIHBhcGVycw0Kd2lsbCBiZSBwdWJs aXNoZWQgb24gdGhlIElBQiB3ZWJzaXRlIGF0Og0KaHR0cDovL3d3dy5pYWIub3JnL2FjdGl2aXRp ZXMvd29ya3Nob3BzL3NlbWkvLg0KDQpTdWJtaXNzaW9ucyBhY2NlcHRlZCBhdDoNCmh0dHBzOi8v d3d3LmVhc3ljaGFpci5vcmcvY29uZmVyZW5jZXMvP2NvbmY9c2VtaTIwMTUNCg0KU3VibWlzc2lv biBEZWFkbGluZTogMzEgT2N0b2JlciAyMDE0DQoNCk5vdGlmaWNhdGlvbiBEZWFkbGluZTogMTcg Tm92ZW1iZXIgMjAxNA0KDQpXb3Jrc2hvcCBEYXRlczogMjYtMjcgSmFudWFyeSAyMDE1DQoNClNw b25zb3JlZCBieSB0aGUgSW50ZXJuZXQgQXJjaGl0ZWN0dXJlIEJvYXJkLCB0aGUgSW50ZXJuZXQg U29jaWV0eSwgYW5kDQpFVEggWsO8cmljaC4gTWlyamEgS8O8aGxld2luZCBhbmQgQnJpYW4gVHJh bW1lbGwsIEdlbmVyYWwgQ2hhaXJzLg0K From nobody Mon Oct 13 01:48:24 2014 Return-Path: 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 C61A01A88E4 for ; Mon, 13 Oct 2014 01:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 RgzeKgsK8JPw for ; Mon, 13 Oct 2014 01:48:21 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D81D1A88E3 for ; Mon, 13 Oct 2014 01:48:20 -0700 (PDT) X-Spam-Processed: mail.kau.se, Mon, 13 Oct 2014 10:48:10 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 130.243.25.206 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Date: Mon, 13 Oct 2014 10:48:02 +0200 From: Per Hurtig To: Pasi Sarolahti Message-ID: <20141013084802.GA5944@kau.se> References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> <87CDBDF6-27E4-44DE-BE12-CAA2F4CC84F9@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87CDBDF6-27E4-44DE-BE12-CAA2F4CC84F9@iki.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/viXyopjEN2F1z5r2giDAmmJ7gWw Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 08:48:22 -0000 On Thu, Oct 09, 2014 at 09:49:13PM +0300, Pasi Sarolahti wrote: >On 09 Oct 2014, at 20:32, Yuchung Cheng wrote: > >> On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti wrote: >>> Hi, >>> >>> Thanks, Yuchung, for bringing this up. It reminds me of an old note I sent to the list quite a long while ago: I think it would be good if the algorithm was designed so that it cannot (even in theory) result in negative RTO values. The most straightforward way to fix this would be to include some kind of max(RTO - T_earliest, some_threshold) guard in the algorithm. It might not protect against spurious timeouts, but at least would keep the values in sensible range. >> >> This would work but it might reduce the benefit (and adding yet >> another magic threshold). A negative value is a >> strong signal that the first unacked packet is lost. The problem in my >> case is the reaction is not appropriate (reset cwnd again) because we >> have just make some forward progress. > >Right, magic numbers are not nice (but it could be 0, just to prevent negatives). Or then the draft should otherwise discuss handling of negative values, and make it clear if there might be such. Some implementations might define RTO as unsigned, in which case a negative value becomes very large value… > >- Pasi > Hi all, I agree that we should formalize what to do if the timeout becomes negative due to RTOR. In our current implementation we don't invoke RTOR at all if the resulting value (RTO - T_earliest) is <= 0. That is, it has to be a positive number. I think this is a fair trade-off, and could be included in the coming internet-draft. Do you think it's too conservative? Cheers, Per From nobody Mon Oct 13 09:20:59 2014 Return-Path: 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 73F9D1A1AD0 for ; Mon, 13 Oct 2014 09:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 Zzff9j8JxSSQ for ; Mon, 13 Oct 2014 09:20:54 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7CB1A1AD3 for ; Mon, 13 Oct 2014 09:20:45 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id uq10so11091736igb.7 for ; Mon, 13 Oct 2014 09:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=epn9JvWpt9q39QZWk1O+JyGwpzCJ0/wkxzkJ0FtcYvU=; b=WO435mH9pmj/R5ESAxuMFi1MShcmpbDMwxRf4LLd5l7ArY2aRRRzfnaL/bvmC1vMcy UD5kUMU2w+FsKPbuM9kamn9WpDYMtV4XZREp4hC8lJYytNy4oWVN41IcAqnU2BJ7oMsA EZVU4SUp+6WT+anTuSXlrtlkAMSQLYb1nyJ5wncbEnx8sKa2MXvJvfl0MND9emeMUWSJ ZhyhjU5vHiYfrvN48QzjT8jeZyL8BSCifylQcNMzjRlHKRz+lxV4V/nh/M6v6fddnYLy tOpAQun7V2ldaylLbgI9CA8s5K94yxPtq+HGm5zOmnwUOcJVnliKlpjN8o8TNvNNzI+v w9SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=epn9JvWpt9q39QZWk1O+JyGwpzCJ0/wkxzkJ0FtcYvU=; b=DuRWp5/MK1us/zArBWoqZeXRs0UYXSRE5nREslNryMy46SbyEQNJgqWnFz0wj2hfzG 0yUg9FODd1tUUe4S9wuq+97XbbvG63Tuy5yNfNXzZoaZZXB9rZa3rCg9me6IJiE2WVKx tKu7vkyj2ZtIgxWXmiOmFxGF5PTpj5AIqrcCMGOFYep+RX3Ilb7ieeOoh9p4KDKBRFAa egOMPQ55HQ00d2jT6JVzNdNRfc3lHPposQubgrwkOJD2d2+PyzzXzgZnfkt45HKre6t4 oMfRVKTFKw5VohDDw2FRqDla2lPdo8MP7+mIjStXB4zCpCU2OsB7+QTIsTSmgp7+tu6H oYfQ== X-Gm-Message-State: ALoCoQlqfBz1r1misPk1yYyDpkZfbdGYgteeCCf0yziYbuARiZsrY1Zqn1up5tLPOvYjgigyuT2W X-Received: by 10.42.107.9 with SMTP id b9mr2704543icp.84.1413217244993; Mon, 13 Oct 2014 09:20:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.168 with HTTP; Mon, 13 Oct 2014 09:20:04 -0700 (PDT) In-Reply-To: <20141013084802.GA5944@kau.se> References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> <87CDBDF6-27E4-44DE-BE12-CAA2F4CC84F9@iki.fi> <20141013084802.GA5944@kau.se> From: Yuchung Cheng Date: Mon, 13 Oct 2014 09:20:04 -0700 Message-ID: To: Per Hurtig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/At5kqK9FHCAJiTs2g5FBmN9y13c Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:20:56 -0000 On Mon, Oct 13, 2014 at 1:48 AM, Per Hurtig wrote: > On Thu, Oct 09, 2014 at 09:49:13PM +0300, Pasi Sarolahti wrote: >> >> On 09 Oct 2014, at 20:32, Yuchung Cheng wrote: >> >>> On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti >>> wrote: >>>> >>>> Hi, >>>> >>>> Thanks, Yuchung, for bringing this up. It reminds me of an old note I >>>> sent to the list quite a long while ago: I think it would be good if t= he >>>> algorithm was designed so that it cannot (even in theory) result in ne= gative >>>> RTO values. The most straightforward way to fix this would be to inclu= de >>>> some kind of max(RTO - T_earliest, some_threshold) guard in the algori= thm. >>>> It might not protect against spurious timeouts, but at least would kee= p the >>>> values in sensible range. >>> >>> >>> This would work but it might reduce the benefit (and adding yet >>> another magic threshold). A negative value is a >>> strong signal that the first unacked packet is lost. The problem in my >>> case is the reaction is not appropriate (reset cwnd again) because we >>> have just make some forward progress. >> >> >> Right, magic numbers are not nice (but it could be 0, just to prevent >> negatives). Or then the draft should otherwise discuss handling of negat= ive >> values, and make it clear if there might be such. Some implementations m= ight >> define RTO as unsigned, in which case a negative value becomes very larg= e >> value=E2=80=A6 >> >> - Pasi >> > > Hi all, > > I agree that we should formalize what to do if the timeout becomes > negative due to RTOR. In our current implementation we don't invoke RTOR > at all if the resulting value (RTO - T_earliest) is <=3D 0. That is, it > has to be a positive number. > > I think this is a fair trade-off, and could be included in the coming > internet-draft. Do you think it's too conservative? It's not conservative. It's just awkward. If RTO - T_earliest is 1 ms, we retransmit almost right away. If it's past due (<=3D 0), we wait another RTO. The fix would work, it just sound like a hack. Sorry I try to be polite but I couldn't find a better word... > > > Cheers, > Per > From nobody Mon Oct 13 09:21:43 2014 Return-Path: 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 E2DA11A030B for ; Mon, 13 Oct 2014 09:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 QpjPhz-oIpL4 for ; Mon, 13 Oct 2014 09:21:39 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06E21A0346 for ; Mon, 13 Oct 2014 09:21:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5E142D9307; Mon, 13 Oct 2014 18:21:37 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5klE-lRPq76v; Mon, 13 Oct 2014 18:21:37 +0200 (MEST) Received: from [192.168.178.32] (stgt-5f71871a.pool.mediaWays.net [95.113.135.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E765ED9302; Mon, 13 Oct 2014 18:21:36 +0200 (MEST) Message-ID: <543BFC10.7050209@tik.ee.ethz.ch> Date: Mon, 13 Oct 2014 18:21:36 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Bob Briscoe , touch@isi.edu Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Rmzo2aklxhFx8lQGufB0o6jn4a0 Cc: "tcpm@ietf.org" Subject: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:21:42 -0000 Hi Joe, hi Bob, I've just read both of your drafts and have a couple of thoughts that I would like to write down before I forget them... I hope that's helpful otherwise just ignore them :-) 1) I think I would prefer a 'clean' approach using a new option. If such a new option would cause a middlebox to drop the packet, the kind of happy eyeball approach of Bob would maybe be helpful; but i guess that's a general question for all new options. 2) What's about putting the EDO length option as the first (or last) option in the payload more or less as proposed in Bob's approach (if we require it to be present in each segment anyway as discussed in the previous mail thread). This way it could not be removed by a middlebox... 3) If we require the option on each segment we could add one more field in the EDO request option indicating if the endpoint would actually like to use the extended option space at some point or not. That means the initiator basically can say I support the option but don't need it and the other host can then complete the negotiation or not (or the initiator says I support the option and would like to use it and the other host negotiates it and also indicated if it needs the space or not). One quick question for Bob: Is there a specific reason that you've put the syn-op-sis option at the end (and not at the beginning) of the payload? Mirja From nobody Mon Oct 13 10:17:00 2014 Return-Path: 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 C37941A1B8A for ; Mon, 13 Oct 2014 10:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 JCsIUG7C4eOb for ; Mon, 13 Oct 2014 10:16:35 -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 BC1941A1B8C for ; Mon, 13 Oct 2014 10:16:24 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9DHGAXI025581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 10:16:11 -0700 (PDT) Message-ID: <543C08DA.206@isi.edu> Date: Mon, 13 Oct 2014 10:16:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , Bob Briscoe References: <543BFC10.7050209@tik.ee.ethz.ch> In-Reply-To: <543BFC10.7050209@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/YM2IAkPlC8iXDRkRX-Id2MkQWMk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 17:16:48 -0000 Hi, Mirja, On 10/13/2014 9:21 AM, Mirja KĂ¼hlewind wrote: > Hi Joe, hi Bob, > > I've just read both of your drafts and have a couple of thoughts that I > would like to write down before I forget them... I hope that's helpful > otherwise just ignore them :-) > > 1) I think I would prefer a 'clean' approach using a new option. If such > a new option would cause a middlebox to drop the packet, the kind of > happy eyeball approach of Bob would maybe be helpful; but i guess that's > a general question for all new options. We certainly need to consider middlebox behavior, but we do also need to temper that based on what's been deployed, not merely what we think might ever be deployed. > 2) What's about putting the EDO length option as the first (or last) > option in the payload more or less as proposed in Bob's approach (if we > require it to be present in each segment anyway as discussed in the > previous mail thread). This way it could not be removed by a middlebox... All options are in the "payload" area, i.e., in the area after the base TCP header. The header is what indicates what portion of that payload is an extension to that base header. For the purposes of backwards-compatibility with legacy endpoints, it doesn't matter whether extension space comes from the front or rear of that space. > 3) If we require the option on each segment we could add one more field > in the EDO request option indicating if the endpoint would actually like > to use the extended option space at some point or not. Options often consume space in both directions, sometimes asymmetrically (e.g., SACK). Just as with SACK, sometimes endpoints turn on options that don't get used actively. > That means the > initiator basically can say I support the option but don't need it and > the other host can then complete the negotiation or not (or the > initiator says I support the option and would like to use it and the > other host negotiates it and also indicated if it needs the space or not). You'd need to extend the TWHS to make this happen. I.e., during one exchange you're saying what you CAN do, then in the next exchange you say what you WILL do. TCP doesn't have that capability now; to do so would require adding states to the TCP handshake, which is much more than a "minor" (as in "tcp*m*") extension. > One quick question for Bob: Is there a specific reason that you've put > the syn-op-sis option at the end (and not at the beginning) of the payload? I'll let Bob answer that in detail if desired; AFAICT, it's largely to allow middleboxes that don't understand the extension to be able to parse and process the data field. I think this is a mistake, because at some point in that field the data is corrupted, and it is just making a bet that such boxes should be supported until they silently fail. I'd prefer they just fail from the start. Joe From nobody Mon Oct 13 10:23:39 2014 Return-Path: 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 401E91A1B9B; Mon, 13 Oct 2014 10:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gYUZSe929fWD; Mon, 13 Oct 2014 10:23:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 903921A1B8E; Mon, 13 Oct 2014 10:23:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013172333.7207.76001.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 10:23:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/O4QULtiC2OogzoYO1VgGf5zPkho Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 17:23:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-01.txt Pages : 19 Date : 2014-10-13 Abstract: TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options such as SACK with either TCP Multipath or TCP AO. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 13 10:36:14 2014 Return-Path: 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 4CDF11A1B87; Mon, 13 Oct 2014 10:36:12 -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 YjaWA1vJ1zMD; Mon, 13 Oct 2014 10:36:10 -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 C1EDD1A1B6D; Mon, 13 Oct 2014 10:36:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9DHZgVF029531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 10:35:42 -0700 (PDT) Message-ID: <543C0D6D.60302@isi.edu> Date: Mon, 13 Oct 2014 10:35:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20141013172333.7207.76001.idtracker@ietfa.amsl.com> In-Reply-To: <20141013172333.7207.76001.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 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/JIZqVJW5OniqUSOnMjtnq0xlq0w Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 17:36:12 -0000 Hi, all, We just posted an update to the EDO doc: Primary changes: - added Implementation details section (8) based on Pasi and my student - change the option to indicate length in 4-byte words (simpler to unify with DO use, as suggested by Pasi) - include experimental option ExID (0x0ED0) which has already been confirmed with IANA and, to address asymmetric middleboxes that silently remove EDO: - prohibit EDO length option from SYN/ACK - require EDO in all segments once negotiated - discuss these issues in Section 6.2 I continue to believe we need to limit the extent to which we deal with increasing egregious middlebox behavior inside widely-deployed TCP, because, IMO, TCP should not be confused with a network diagnostic tool. Joe On 10/13/2014 10:23 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP Extended Data Offset Option > Authors : Joe Touch > Wesley M. Eddy > Filename : draft-ietf-tcpm-tcp-edo-01.txt > Pages : 19 > Date : 2014-10-13 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options, but the size of the field can limit the space available for > complex options that have evolved. This document updates RFC 793 > with an optional TCP extension to that space to support the use of > multiple large options such as SACK with either TCP Multipath or TCP > AO. It also explains why the initial SYN of a connection cannot be > extending a single segment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Oct 14 05:42:05 2014 Return-Path: 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 B68DB1A87A8 for ; Tue, 14 Oct 2014 05:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KVTyWoXncA40 for ; Tue, 14 Oct 2014 05:42:00 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EF1A87A0 for ; Tue, 14 Oct 2014 05:41:59 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0806DC94BE; Tue, 14 Oct 2014 08:41:55 -0400 (EDT) Date: Tue, 14 Oct 2014 08:41:54 -0400 From: John Leslie To: Joe Touch Message-ID: <20141014124154.GP83009@verdi> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543C08DA.206@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0Or4V5wKiRg87LHYPHIu-aLElmI Cc: tcpm@ietf.org Subject: [tcpm] tcp-edo middlebox issues X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:42:03 -0000 Joe Touch wrote: > On 10/13/2014 9:21 AM, Mirja K??hlewind wrote: >> >> 1) I think I would prefer a 'clean' approach using a new option. If such >> a new option would cause a middlebox to drop the packet, the kind of >> happy eyeball approach of Bob would maybe be helpful; but i guess that's >> a general question for all new options. > > We certainly need to consider middlebox behavior, but we do also need to > temper that based on what's been deployed, not merely what we think > might ever be deployed. It's exactly the "what's been deployed" question which should prompt us to write an Experimental RFC to gather sufficient data on what actual issues we're facing. Mirja suggests getting a dedicated option for experimental use -- I believe that is entirely justified. It should be easy for any middlebox to know whether it's dealing with endpoints which expand the TCP Option space. If middleboxes drop packets which use EDO, we've got a simple path: do without expanded option space until the middleboxes are fixed. If a middlebox ignores our EDO option, we know there will be trouble if it also tries to act on other TCP Options (because it won't know where to look for them). And if a middlebox ignores our EDO option, there will also be trouble if it tries to change anything in the payload. (It's perfectly OK for it to change the TCP headers _before_ the payload; but when it sets out to do _anything_ to the payload itself, serious damage is likely.) (Arguably, of course, even changing TCP ports is a layer violation; but there's no chance of stopping middleboxes from doing it. Fortunately TCP ports are in the TCP header, not the payload.) We have been having discussions where folks have considered _parts_ of the problem: generally responses have been "That won't happen here!" That response doesn't inspire confidence. :^( I'd like to suggest that we look into _detecting_ middlebox damage which makes changes to the _payload_. We've narrowed our vision too much, IMHO, when we assume that any middlebox behavior will become apparent during the three-way handshake. We _should_ know that different middleboxes can be in the path during the life of a TCP connection: thus different problems may show up later in the life of a connection. Or, even within the same connection, a middlebox might change what algorithms it uses. (Can you spell "software update"?) ==== In order to have _a_ proposal (I'm not really particular which way we go about this), I'll suggest a checksum over the payload for the receiving endpoint to verify before passing anything to the application. -- John Leslie From nobody Tue Oct 14 06:38:47 2014 Return-Path: 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 416F71A8867 for ; Tue, 14 Oct 2014 06:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TdYXa6IjPq_A for ; Tue, 14 Oct 2014 06:38:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74B1A885E for ; Tue, 14 Oct 2014 06:38:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 042E2C94C2; Tue, 14 Oct 2014 09:38:39 -0400 (EDT) Date: Tue, 14 Oct 2014 09:38:39 -0400 From: John Leslie To: Joe Touch Message-ID: <20141014133839.GQ83009@verdi> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543C08DA.206@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TfhxAfu9oD-deqqipBexj_RCtL8 Cc: tcpm@ietf.org Subject: [tcpm] option "negotiation" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 13:38:46 -0000 Joe Touch wrote: > On 10/13/2014 9:21 AM, Mirja K??hlewind wrote: > >> 3) If we require the option on each segment we could add one more field >> in the EDO request option indicating if the endpoint would actually like >> to use the extended option space at some point or not. (I actively dislike requiring an EDO option in each segment; and I don't believe it fully solves the problem it sets out to solve: but that's not the issue here.) > Options often consume space in both directions, sometimes asymmetrically > (e.g., SACK). Just as with SACK, sometimes endpoints turn on options > that don't get used actively. _Some_ options do these things. >> That means the initiator basically can say I support the option >> but don't need it That should pretty much _always_ be the case -- the exception being when the initiator will abort the connection if the other endpoint doesn't support this option. >> and the other host can then complete the negotiation or not Options do not necessarily need to be "negotiated". >> (or the initiator says I support the option and would like to >> use it and the other host negotiates it and also indicated if it >> needs the space or not). This is a confusing statement. There indeed can be cases where either endpoint _supports_ an option but has no expectation of invoking it, and other cases where the endpoint intends to use the option if the other end supports it. But this really isn't a "negotiation" issue. No "money" changes hands. Over time, one naturally expects a protocol like TCP to define options which will be used in "special" cases: and whether such cases will be seen in any particular connection tends to be unknown at handshake time. In a different world, we would have said nothing about such options until they are "needed" and hoped the other endpoint would accept them. But in _this_ world, we mostly announce our support on the initial SYN and leave the option unused. Thus, IMHO, the "negotiation" paradigm doesn't fit well, since at the time the option is passed, there is insufficient information about the need to use it. Instead, I like a paradigm of "capabilities". Each endpoint announces what options it "supports" -- meaning that it knows how to interpret it if the other end uses it. (Presumably it also knows how to use it if the other end supports it.) > You'd need to extend the TWHS to make this happen. I.e., during one > exchange you're saying what you CAN do, then in the next exchange you > say what you WILL do. Joe is correct that a three-way handshake would be required. > TCP doesn't have that capability now; to do so would require adding > states to the TCP handshake, which is much more than a "minor" (as in > "tcp*m*") extension. ;^) (Actually, we could design a separate three-way-handshake for options where that distinction is important; but I'm hard-pressed to think of a case where it would be worth the trouble.) -- John Leslie From nobody Tue Oct 14 09:19:37 2014 Return-Path: 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 9FA351A8901 for ; Tue, 14 Oct 2014 09:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2kznc3PvV-Ug for ; Tue, 14 Oct 2014 09:19:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55061A88DC for ; Tue, 14 Oct 2014 09:19:32 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9EGJ2SR004840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 09:19:08 -0700 (PDT) Message-ID: <543D4CF5.7040309@isi.edu> Date: Tue, 14 Oct 2014 09:19:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John Leslie References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <20141014124154.GP83009@verdi> In-Reply-To: <20141014124154.GP83009@verdi> Content-Type: text/plain; charset=windows-1252 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/2nf2lyVlGxFBx--A8gL2_wP7TNE Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-edo middlebox issues X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:19:34 -0000 On 10/14/2014 5:41 AM, John Leslie wrote: > Joe Touch wrote: >> On 10/13/2014 9:21 AM, Mirja K??hlewind wrote: >>> >>> 1) I think I would prefer a 'clean' approach using a new option. If such >>> a new option would cause a middlebox to drop the packet, the kind of >>> happy eyeball approach of Bob would maybe be helpful; but i guess that's >>> a general question for all new options. >> >> We certainly need to consider middlebox behavior, but we do also need to >> temper that based on what's been deployed, not merely what we think >> might ever be deployed. > > It's exactly the "what's been deployed" question which should prompt > us to write an Experimental RFC to gather sufficient data on what actual > issues we're facing. > > Mirja suggests getting a dedicated option for experimental use -- I > believe that is entirely justified. It should be easy for any middlebox > to know whether it's dealing with endpoints which expand the TCP Option > space. MPTCP already has experience with an "unknown option", and there was an extensive study I cited from 2011. ... > We have been having discussions where folks have considered _parts_ > of the problem: generally responses have been "That won't happen here!" I've cited a study that indicated what happens and where. ,,, > I'd like to suggest that we look into _detecting_ middlebox damage > which makes changes to the _payload_. TCP isn't a diagnostic tool. If we want an option to do that - and we've had a few before that we deprecated (checksums, in particular) - that's OK for that option. But I don't support the idea of building that sort of diagnostic into each option we develop. > We've narrowed our vision too much, IMHO, when we assume that any > middlebox behavior will become apparent during the three-way handshake. You complained about others raising issues based on speculation. The study I cited doesn't say that options are passed during the TWHS but later changed. Middlebox paths can change after a connection starts, but in many cases this affects the entire connection (e.g., NAT will just fail). Do you have evidence of middleboxes that drop after the TWHS or that can be inserted after a connection is established? > We _should_ know that different middleboxes can be in the path during > the life of a TCP connection: Based on what? I have not seen anyone do more than speculate about such boxes. > thus different problems may show up > later in the life of a connection. Or, even within the same connection, > a middlebox might change what algorithms it uses. (Can you spell > "software update"?) Based on what? Are you aware of a middlebox that continues to process established connections after a reboot? > ==== > > In order to have _a_ proposal (I'm not really particular which way > we go about this), I'll suggest a checksum over the payload for the > receiving endpoint to verify before passing anything to the application. That might be a useful *independent* option, but I see no justification for including that as part of EDO. Joe From nobody Tue Oct 14 09:35:10 2014 Return-Path: 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 B60DB1A8A7A for ; Tue, 14 Oct 2014 09:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ggZjs5hQvs8o for ; Tue, 14 Oct 2014 09:35:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4611B1A701A for ; Tue, 14 Oct 2014 09:35:08 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9EGYXuQ009928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 09:34:33 -0700 (PDT) Message-ID: <543D5098.6010405@isi.edu> Date: Tue, 14 Oct 2014 09:34:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John Leslie References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <20141014133839.GQ83009@verdi> In-Reply-To: <20141014133839.GQ83009@verdi> Content-Type: text/plain; charset=windows-1252 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/HXdT8VHDwB3lpfCoxPRx7mVbPY0 Cc: tcpm@ietf.org Subject: Re: [tcpm] option "negotiation" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:35:09 -0000 On 10/14/2014 6:38 AM, John Leslie wrote: > Joe Touch wrote: >> On 10/13/2014 9:21 AM, Mirja K??hlewind wrote: >> >>> 3) If we require the option on each segment we could add one more field >>> in the EDO request option indicating if the endpoint would actually like >>> to use the extended option space at some point or not. > > (I actively dislike requiring an EDO option in each segment; and I > don't believe it fully solves the problem it sets out to solve: but > that's not the issue here.) The only reason for using EDO in every segment is to handle the *conjectured* case of: - a middlebox that gets inserted after the TWHS - that ALSO allows the connection to continue - that ALSO silently drops EDO We have no evidence of this spectre. I would be glad to allow EDO to be optional, and to have a *separate* payload and/or option checksum for *diagnostics*. >> Options often consume space in both directions, sometimes asymmetrically >> (e.g., SACK). Just as with SACK, sometimes endpoints turn on options >> that don't get used actively. > > _Some_ options do these things. > >>> That means the initiator basically can say I support the option >>> but don't need it > > That should pretty much _always_ be the case -- the exception being > when the initiator will abort the connection if the other endpoint > doesn't support this option. I don't agree that this should be the case. However, we're talking about how TCP currently works. Can you provide an example of a current option with this property? >>> and the other host can then complete the negotiation or not > > Options do not necessarily need to be "negotiated". Except for those mandated by RFC793, can you give an example? IMO, they necessarily need to be negotiated to deal with legacy endpoints. TCP ignores options it doesn't understand (RFC1122 Sec. 4.2.2.5). It is safe to proceed with a connection only when SYN options negotiate support for that option; otherwise, an unknown option can have unknown impact on the connection later. Joe From nobody Tue Oct 14 11:25:15 2014 Return-Path: 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 10D8D1ACD5C for ; Tue, 14 Oct 2014 11:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.087 X-Spam-Level: X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 Ag-iBIF8w5xg for ; Tue, 14 Oct 2014 11:25:10 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9504F1ACCFC for ; Tue, 14 Oct 2014 11:25:09 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 14 Oct 2014 19:25:06 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 14 Oct 2014 19:25:11 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 14 Oct 2014 19:25:05 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9EIP3rT017080; Tue, 14 Oct 2014 19:25:03 +0100 Message-ID: <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2014 19:25:01 +0100 To: Joe Touch , Mirja =?iso-8859-1?Q?K=C3=BChlewind?= From: Bob Briscoe In-Reply-To: <543C08DA.206@isi.edu> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/MHP4hP7voDmd4SrQf8i16huMeI8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 18:25:13 -0000 MIrja, Joe, At 18:16 13/10/2014, Joe Touch wrote: >Hi, Mirja, > >On 10/13/2014 9:21 AM, Mirja K=C3=BChlewind wrote: > > Hi Joe, hi Bob, > > > > I've just read both of your drafts and have a couple of thoughts that I > > would like to write down before I forget them... I hope that's helpful > > otherwise just ignore them :-) > > > > 1) I think I would prefer a 'clean' approach using a new option. If such > > a new option would cause a middlebox to drop the packet, the kind of > > happy eyeball approach of Bob would maybe be helpful; but i guess that's > > a general question for all new options. > >We certainly need to consider middlebox behavior, but we do also need to >temper that based on what's been deployed, not merely what we think >might ever be deployed. I take a different view. I am trying to design a=20 way for middleboxes to work properly in the=20 future, that can also be deployed through the middleboxes we already have. > > 2) What's about putting the EDO length option as the first (or last) > > option in the payload more or less as proposed in Bob's approach (if we > > require it to be present in each segment anyway as discussed in the > > previous mail thread). This way it could not be removed by a= middlebox... > >All options are in the "payload" area, i.e., in the area after the base >TCP header. The header is what indicates what portion of that payload is >an extension to that base header. I think Mirja is suggesting that a TCP Option=20 before the Data Offset ('outer') that points to=20 extended option space beyond the Data Offset=20 ('inner') is fragile. If the outer option is=20 stripped, then the inner options turn into=20 potentially corrupt user-data. I.e. the outer and=20 inner do not share the same fate. In the syn-op-sis approach, the extra space and=20 the option that creates the extra space are both=20 beyond the Data Offset (both inner). So they share fate. >For the purposes of >backwards-compatibility with legacy endpoints, it doesn't matter whether >extension space comes from the front or rear of that space. > > > 3) If we require the option on each segment we could add one more field > > in the EDO request option indicating if the endpoint would actually like > > to use the extended option space at some point or not. > >Options often consume space in both directions, sometimes asymmetrically >(e.g., SACK). Just as with SACK, sometimes endpoints turn on options >that don't get used actively. > > > That means the > > initiator basically can say I support the option but don't need it and > > the other host can then complete the negotiation or not (or the > > initiator says I support the option and would like to use it and the > > other host negotiates it and also indicated if it needs the space or= not). > >You'd need to extend the TWHS to make this happen. I.e., during one >exchange you're saying what you CAN do, then in the next exchange you >say what you WILL do. TCP doesn't have that capability now; to do so >would require adding states to the TCP handshake, Surely you can negotiate the ability, then signal=20 whether you use the capability on a segment by=20 segment basis? I'm warey that this conversation=20 has got a bit abstract, so I might be misunderstanding you. >which is much more >than a "minor" (as in "tcp*m*") extension. I am conscious that all this option-space=20 extension activity stretches the definition of the word "minor" (see below). > > One quick question for Bob: Is there a specific reason that you've put > > the syn-op-sis option at the end (and not at the beginning) of the= payload? > >I'll let Bob answer that in detail if desired; AFAICT, it's largely to >allow middleboxes that don't understand the extension to be able to >parse and process the data field. I think this is a mistake, because at >some point in that field the data is corrupted, and it is just making a >bet that such boxes should be supported until they silently fail. I'd >prefer they just fail from the start. I suspect that what Joe says might happen with=20 some middleboxes, ie. the start of the payload=20 looks like they would expect, but they suddently=20 find some unexpected bytes so they drop the packet. However, I'd like to experiment, because I=20 suspect many of these app-layer boxes will parse=20 up to whatever point they need to, then stop. So=20 they won't ever notice the unexpected bytes at=20 the end. For instance, my employer's Web filter=20 (that I'm sitting behind right now) looks for the=20 URL that is the argument to the HTTP GET command=20 in order to decide whether to block the page. It=20 doesn't parse all the HTML, and it may not even=20 parse all the HTTP after the GET. These filters=20 are widely used to protect children from porn=20 etc, and they are widely used for less noble (usually commercial) purposes. On 7 out of the 142 paths tested in Michio Honda=20 et al "Is it Still Possible to Extend TCP?" there=20 was a box that silently dropped packets to port=20 80 that contained unexpected data instead of=20 valid HTTP. The unexpected data was commands that=20 the experimenters' had written into the payload=20 to control their echo-responder. They hadn't=20 expected that these commands would disrupt the=20 experiment. I don't know of any experiments that=20 have included expected data followed by unexpected data. Whatever, in draft-03 of syn-op-sis (that I'm=20 still working on), I've put the extension options=20 at the front by default, and made the trailer=20 mode optional (so experiments can be conducted to find if it is needed). _______________ Here's a taster of draft-...-syn-op-sis-03: It=20 provides extra options space on every segment,=20 not just the SYN, as promised. However, it's=20 actually gone in a significantly different=20 direction. It's no longer 'just' extending=20 options space. I've realised there is a need for=20 two different types of options: * segment transmission control options (e.g. MSS, SACK); * stream transmission control options (e.g. TCPcrypt, TCP-AO). If you have a proxy at L4 or above in the middle=20 of a path, you might have different segmentation=20 on the two sections of the path, so each section=20 needs its own segment control options. However,=20 the ordered byte-stream is the same e2e, so you=20 want the stream control options to work e2e,=20 which can be achieved by encapsulating them in the TCP Data. Then you gain unlimited space in the TCP Data for=20 the stream control options, which relieves the=20 pressure on the traditional option space for=20 segment control options. Also, for all the=20 options at the start of the connection it doesn't=20 matter whether they are segment or stream=20 control; they can be placed either inside or=20 outside the TCP Data, which gives a lot of flexibility over space usage. That's a taster... Rather than write more here,=20 I'll concentrate on writing it into the draft and get it posted. All this seems to go beyond a "minor" extension.=20 However, one can look at it as articulating a=20 division within TCP that has crept into the=20 protocol over the years, and turning that division into an explicit feature. I've completely rewritten draft-03 about 4 times=20 now, because I kept thinking of ways to overhaul=20 it to make it simpler. I expect to post it soon -=20 I'm happy with the protocol itself, which is now=20 completely written up - but I'm taking care to=20 write a full "Design Rationale" section, which takes a lot longer. Bob >Joe ________________________________________________________________ Bob Briscoe, BT=20 From nobody Tue Oct 14 11:42:58 2014 Return-Path: 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 C177B1A90F3 for ; Tue, 14 Oct 2014 11:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 J5lMqSts6zPN for ; Tue, 14 Oct 2014 11:42:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AA71A802F for ; Tue, 14 Oct 2014 11:42:54 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9EIfsFE018425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 11:41:54 -0700 (PDT) Message-ID: <543D6E72.6050509@isi.edu> Date: Tue, 14 Oct 2014 11:41:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Bob Briscoe , =?windows-1252?Q?Mirja_K=FChlewin?= =?windows-1252?Q?d?= References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> In-Reply-To: <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/i2qZplrulMaaGvayIHc0SdTtkVs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 18:42:56 -0000 On 10/14/2014 11:25 AM, Bob Briscoe wrote: > MIrja, Joe, ... >> > 2) What's about putting the EDO length option as the first (or last) >> > option in the payload more or less as proposed in Bob's approach (if we >> > require it to be present in each segment anyway as discussed in the >> > previous mail thread). This way it could not be removed by a >> middlebox... >> >> All options are in the "payload" area, i.e., in the area after the base >> TCP header. The header is what indicates what portion of that payload is >> an extension to that base header. > > I think Mirja is suggesting that a TCP Option before the Data Offset > ('outer') that points to extended option space beyond the Data Offset > ('inner') is fragile. If the outer option is stripped, then the inner > options turn into potentially corrupt user-data. I.e. the outer and > inner do not share the same fate. I don't understand this. DO extends the TCP header into the front of the payload. Any TCP option that extends that space in any way needs to be in that area. DO can't be stripped. The options it makes space for can. Regardless of how a TCP option extends the DO space, if that happens mid-connection (again, a hypothetical only), the extension space will be interpreted as user data. It doesn't matter whether the additional space is at the front or end of the post-DO payload. > In the syn-op-sis approach, the extra space and the option that creates > the extra space are both beyond the Data Offset (both inner). So they > share fate. Even if that were true, it would mean that user data would be corrupted by both the option and the extension. A middlebox that goes around removing options it doesn't understand won't parse space beyond DO. >> For the purposes of >> backwards-compatibility with legacy endpoints, it doesn't matter whether >> extension space comes from the front or rear of that space. >> >> > 3) If we require the option on each segment we could add one more field >> > in the EDO request option indicating if the endpoint would actually >> like >> > to use the extended option space at some point or not. >> >> Options often consume space in both directions, sometimes asymmetrically >> (e.g., SACK). Just as with SACK, sometimes endpoints turn on options >> that don't get used actively. >> >> > That means the >> > initiator basically can say I support the option but don't need it and >> > the other host can then complete the negotiation or not (or the >> > initiator says I support the option and would like to use it and the >> > other host negotiates it and also indicated if it needs the space or >> not). >> >> You'd need to extend the TWHS to make this happen. I.e., during one >> exchange you're saying what you CAN do, then in the next exchange you >> say what you WILL do. TCP doesn't have that capability now; to do so >> would require adding states to the TCP handshake, > > Surely you can negotiate the ability, then signal whether you use the > capability on a segment by segment basis? I'm warey that this > conversation has got a bit abstract, so I might be misunderstanding you. Option capability MUST be negotiated during the TWHS. Whether individual options are used on a segment depends on a lot of things - whether that makes sense, whether having segments without the option compromises the capability (e.g., not using TS compromises PAWS), etc. I think we generally all agree on this. However, the above appeared to propose a different semantics for options in the SYN, i.e., the TWHS doesn't concurrently negotiate capability AND whether the capability is needed in the future. ... >> > One quick question for Bob: Is there a specific reason that you've put >> > the syn-op-sis option at the end (and not at the beginning) of the >> payload? >> >> I'll let Bob answer that in detail if desired; AFAICT, it's largely to >> allow middleboxes that don't understand the extension to be able to >> parse and process the data field. I think this is a mistake, because at >> some point in that field the data is corrupted, and it is just making a >> bet that such boxes should be supported until they silently fail. I'd >> prefer they just fail from the start. > > I suspect that what Joe says might happen with some middleboxes, ie. the > start of the payload looks like they would expect, but they suddently > find some unexpected bytes so they drop the packet. > > However, I'd like to experiment, because I suspect many of these > app-layer boxes will parse up to whatever point they need to, then stop. > So they won't ever notice the unexpected bytes at the end. For instance, > my employer's Web filter (that I'm sitting behind right now) looks for > the URL that is the argument to the HTTP GET command in order to decide > whether to block the page. It doesn't parse all the HTML, and it may not > even parse all the HTTP after the GET. These filters are widely used to > protect children from porn etc, and they are widely used for less noble > (usually commercial) purposes. Sure, and they might even parse HTTPS to the point of finding the SNI. > On 7 out of the 142 paths tested in Michio Honda et al "Is it Still > Possible to Extend TCP?" there was a box that silently dropped packets > to port 80 that contained unexpected data instead of valid HTTP. The > unexpected data was commands that the experimenters' had written into > the payload to control their echo-responder. They hadn't expected that > these commands would disrupt the experiment. I don't know of any > experiments that have included expected data followed by unexpected data. > > Whatever, in draft-03 of syn-op-sis (that I'm still working on), I've > put the extension options at the front by default, and made the trailer > mode optional (so experiments can be conducted to find if it is needed). If we do think that this case is common, then we can easily have all the extensions (SYN and otherwise) use space at the end of the segment. It can be something most variants can easily support in a flag, FWIW - I doubt we actually need the entire extension space indicated so far. Joe From nobody Tue Oct 14 13:17:14 2014 Return-Path: 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 06AE91ACEB9 for ; Tue, 14 Oct 2014 13:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.686 X-Spam-Level: X-Spam-Status: No, score=-4.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 kIQJueE9re2T for ; Tue, 14 Oct 2014 13:17:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE271ACEB0 for ; Tue, 14 Oct 2014 13:17:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9EKGiOk019810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 13:16:44 -0700 (PDT) Message-ID: <543D84AC.6090508@isi.edu> Date: Tue, 14 Oct 2014 13:16:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Bob Briscoe , =?windows-1252?Q?Mirja_K=FChlewin?= =?windows-1252?Q?d?= References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> In-Reply-To: <543D6E72.6050509@isi.edu> Content-Type: text/plain; charset=windows-1252 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/GPqMlK3Tid_3q1LyrNplTV3Ko1I Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:17:12 -0000 On 10/14/2014 11:41 AM, Joe Touch wrote: .... >> However, I'd like to experiment, because I suspect many of these >> app-layer boxes will parse up to whatever point they need to, then stop. >> So they won't ever notice the unexpected bytes at the end. For instance, >> my employer's Web filter (that I'm sitting behind right now) looks for >> the URL that is the argument to the HTTP GET command in order to decide >> whether to block the page. It doesn't parse all the HTML, and it may not >> even parse all the HTTP after the GET. These filters are widely used to >> protect children from porn etc, and they are widely used for less noble >> (usually commercial) purposes. > > Sure, and they might even parse HTTPS to the point of finding the SNI. ... > If we do think that this case is common, then we can easily have all the > extensions (SYN and otherwise) use space at the end of the segment. It > can be something most variants can easily support in a flag, FWIW - I > doubt we actually need the entire extension space indicated so far. PS - if this is true, it is also likely true for not only SYN packets but the first data packet too. The first data packet need not be the SYN (and often isn't AFAICT). Joe From nobody Tue Oct 14 14:36:30 2014 Return-Path: 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 05BA81ACD42 for ; Tue, 14 Oct 2014 14:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 AjAYcJmgXQeb for ; Tue, 14 Oct 2014 14:36:25 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131E41ACD19 for ; Tue, 14 Oct 2014 14:36:24 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 14 Oct 2014 22:36:21 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 14 Oct 2014 22:36:20 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Tue, 14 Oct 2014 22:36:19 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9ELaIO6017868; Tue, 14 Oct 2014 22:36:18 +0100 Message-ID: <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Oct 2014 22:36:17 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <543D6E72.6050509@isi.edu> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/FWsEefmaITyrKsrI_LPrwPJrd_4 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:36:29 -0000 Joe, At 19:41 14/10/2014, Joe Touch wrote: >On 10/14/2014 11:25 AM, Bob Briscoe wrote: > > MIrja, Joe, >... > >> > 2) What's about putting the EDO length option as the first (or last) > >> > option in the payload more or less as proposed in Bob's approach (if we > >> > require it to be present in each segment anyway as discussed in the > >> > previous mail thread). This way it could not be removed by a > >> middlebox... > >> > >> All options are in the "payload" area, i.e., in the area after the base > >> TCP header. The header is what indicates what portion of that payload is > >> an extension to that base header. > > > > I think Mirja is suggesting that a TCP Option before the Data Offset > > ('outer') that points to extended option space beyond the Data Offset > > ('inner') is fragile. If the outer option is stripped, then the inner > > options turn into potentially corrupt user-data. I.e. the outer and > > inner do not share the same fate. > >I don't understand this. > >DO extends the TCP header into the front of the payload. > >Any TCP option that extends that space in any way needs to be in that area. > >DO can't be stripped. The options it makes space for can. Regardless of >how a TCP option extends the DO space, if that happens mid-connection >(again, a hypothetical only), the extension space will be interpreted as >user data. It doesn't matter whether the additional space is at the >front or end of the post-DO payload. I am not saying DO might be stripped. Syn-op-sis does not involve any additional TCP options in the TCP option space, ie the space between the end of the 20B base TCP header and the max 60B Data Offset. This makes each syn-op-sis segment /inherently/ robust against option stripping. All the additional options of syn-op-sis are beyond the Data Offset, including the option that creates the additional space for the other options. So they all share the same fate. Whereas, in EDO the option that creates the space beyond DO is not itself beyond DO. So the option that creates the space is at risk of being stripped without stripping the space it created. The two do not /inherently/ share the same fate. Yes, checks can be added to EDO to check for option stripping (e.g. deferring use of extra space until after the SYN/ACK). But this has to assume that stripping behaviour remains consistent through the flow. Whereas, with syn-op-sis, each individual segment is robust against option stripping, all by itself. I think this is what Mirja was referring to. > > In the syn-op-sis approach, the extra space and the option that creates > > the extra space are both beyond the Data Offset (both inner). So they > > share fate. > >Even if that were true, it would mean that user data would be corrupted >by both the option and the extension. * The syn-op-sis client ensures that it aborts the connection to a legacy server before it passes this corrupt TCP Data to the app. * And a syn-op-sis server catches this corrupt TCP data and removes the options before passing the remaining payload to the app. This only relies on the endpoints, which are stateful, to maintain consistent behaviour throughout the connection. Half-way through a connection, a server isn't suddenly going to forget that it supports syn-op-sis and start passing corrupt data to the app. Whereas it is not so certain that the experienced middlebox behaviour will remain consistent throughout a connection. It might not be the same middlebox in both directions, and the path might change to pass through a different middlebox part-way through a connection. >A middlebox that goes around >removing options it doesn't understand won't parse space beyond DO. That's exactly the behaviour that syn-op-sis exploits. > >> For the purposes of > >> backwards-compatibility with legacy endpoints, it doesn't matter whether > >> extension space comes from the front or rear of that space. > >> > >> > 3) If we require the option on each segment we could add one more field > >> > in the EDO request option indicating if the endpoint would actually > >> like > >> > to use the extended option space at some point or not. > >> > >> Options often consume space in both directions, sometimes asymmetrically > >> (e.g., SACK). Just as with SACK, sometimes endpoints turn on options > >> that don't get used actively. > >> > >> > That means the > >> > initiator basically can say I support the option but don't need it and > >> > the other host can then complete the negotiation or not (or the > >> > initiator says I support the option and would like to use it and the > >> > other host negotiates it and also indicated if it needs the space or > >> not). > >> > >> You'd need to extend the TWHS to make this happen. I.e., during one > >> exchange you're saying what you CAN do, then in the next exchange you > >> say what you WILL do. TCP doesn't have that capability now; to do so > >> would require adding states to the TCP handshake, > > > > Surely you can negotiate the ability, then signal whether you use the > > capability on a segment by segment basis? I'm warey that this > > conversation has got a bit abstract, so I might be misunderstanding you. > >Option capability MUST be negotiated during the TWHS. > >Whether individual options are used on a segment depends on a lot of >things - whether that makes sense, whether having segments without the >option compromises the capability (e.g., not using TS compromises PAWS), >etc. > >I think we generally all agree on this. However, the above appeared to >propose a different semantics for options in the SYN, i.e., the TWHS >doesn't concurrently negotiate capability AND whether the capability is >needed in the future. I didn't read Mirja's suggestion like that. I think you & I are agreeing anyway. >... > >> > One quick question for Bob: Is there a specific reason that you've put > >> > the syn-op-sis option at the end (and not at the beginning) of the > >> payload? > >> > >> I'll let Bob answer that in detail if desired; AFAICT, it's largely to > >> allow middleboxes that don't understand the extension to be able to > >> parse and process the data field. I think this is a mistake, because at > >> some point in that field the data is corrupted, and it is just making a > >> bet that such boxes should be supported until they silently fail. I'd > >> prefer they just fail from the start. > > > > I suspect that what Joe says might happen with some middleboxes, ie. the > > start of the payload looks like they would expect, but they suddently > > find some unexpected bytes so they drop the packet. > > > > However, I'd like to experiment, because I suspect many of these > > app-layer boxes will parse up to whatever point they need to, then stop. > > So they won't ever notice the unexpected bytes at the end. For instance, > > my employer's Web filter (that I'm sitting behind right now) looks for > > the URL that is the argument to the HTTP GET command in order to decide > > whether to block the page. It doesn't parse all the HTML, and it may not > > even parse all the HTTP after the GET. These filters are widely used to > > protect children from porn etc, and they are widely used for less noble > > (usually commercial) purposes. > >Sure, and they might even parse HTTPS to the point of finding the SNI. > > > On 7 out of the 142 paths tested in Michio Honda et al "Is it Still > > Possible to Extend TCP?" there was a box that silently dropped packets > > to port 80 that contained unexpected data instead of valid HTTP. The > > unexpected data was commands that the experimenters' had written into > > the payload to control their echo-responder. They hadn't expected that > > these commands would disrupt the experiment. I don't know of any > > experiments that have included expected data followed by unexpected data. > > > > Whatever, in draft-03 of syn-op-sis (that I'm still working on), I've > > put the extension options at the front by default, and made the trailer > > mode optional (so experiments can be conducted to find if it is needed). > >If we do think that this case is common, then we can easily have all the >extensions (SYN and otherwise) use space at the end of the segment. It >can be something most variants can easily support in a flag, Yup. It's do-able,... ...but it's not completely straightforward. For instance, when I tried to design against resegmentation, I suggested a "sent payload size" field in an email to you. The idea was that the receiver could reconstruct where the segment boundaries had been originally - in order to find where the options had been put originally. However, the sender has to place the 'sent payload size' field at the start of the segment it refers to. If it places it at the end of each segment, the receiver has to wait until the very end of the stream before it can work backwards to find where all the segments were - not a lot of use. >FWIW - I >doubt we actually need the entire extension space indicated so far. TCP is 33 years old. There's no point upgrading it now unless we ensure enough space for another 30-50 years at least. When you start using options to transfer keys (e.g. TCPcrypt) they get pretty big (and uncompressable of course). I know it's hard to predict what key sizes will be needed (let alone what algorithms will have been broken) over such timescales. However, I would be embarrassed if we couldn't carry a 4096-bit (512B) key in newly enlarged option space. TCPcrypt currently has to do its main key exchange in the payload, which is messy. We should be ensuring that TCP supports whatever might need to be done in the option space without each new option having to hack a solution when the space is too small. I take the view that we might as well allow the set of options to be as large as the largest possible segment. That turns out not to be hard or wasteful anyway. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Tue Oct 14 14:44:25 2014 Return-Path: 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 9EFD91A00AB for ; Tue, 14 Oct 2014 14:44:24 -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 Uvy54L6mEnB9 for ; Tue, 14 Oct 2014 14:44:23 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4511A00E0 for ; Tue, 14 Oct 2014 14:44:23 -0700 (PDT) Received: from [IPv6:::1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9ELiLnS025737 for ; Tue, 14 Oct 2014 16:44:21 -0500 (CDT) From: David Borman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 14 Oct 2014 16:44:21 -0500 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eBh4YuqhLZRVLDPPJQe-RuXVQfw Subject: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:44:24 -0000 Hi, I=92ve just posted draft-borman-tcp4way-00.txt, which describes a 4-Way = TCP handshake that is intended to allow the TCP EDO option to be used = during the initial SYN exchange. This was mentioned during the TCPM WG = at the last IETF meeting. Please see the draft for more details. -David Borman=20= From nobody Tue Oct 14 15:14:33 2014 Return-Path: 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 83D5E1A1AF0 for ; Tue, 14 Oct 2014 15:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1nvRt3-X0lhH for ; Tue, 14 Oct 2014 15:14:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085D41A02ED for ; Tue, 14 Oct 2014 15:14:28 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9EME9fn017610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 15:14:09 -0700 (PDT) Message-ID: <543DA031.6090705@isi.edu> Date: Tue, 14 Oct 2014 15:14:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Bob Briscoe References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> In-Reply-To: <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/toxoOG6kMcuQoufb7q48vNWiZu8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 22:14:30 -0000 On 10/14/2014 2:36 PM, Bob Briscoe wrote: > Joe, > > At 19:41 14/10/2014, Joe Touch wrote: > > >> On 10/14/2014 11:25 AM, Bob Briscoe wrote: >> > MIrja, Joe, >> ... >> >> > 2) What's about putting the EDO length option as the first (or last) >> >> > option in the payload more or less as proposed in Bob's approach >> (if we >> >> > require it to be present in each segment anyway as discussed in the >> >> > previous mail thread). This way it could not be removed by a >> >> middlebox... >> >> >> >> All options are in the "payload" area, i.e., in the area after the >> base >> >> TCP header. The header is what indicates what portion of that >> payload is >> >> an extension to that base header. >> > >> > I think Mirja is suggesting that a TCP Option before the Data Offset >> > ('outer') that points to extended option space beyond the Data Offset >> > ('inner') is fragile. If the outer option is stripped, then the inner >> > options turn into potentially corrupt user-data. I.e. the outer and >> > inner do not share the same fate. >> >> I don't understand this. >> >> DO extends the TCP header into the front of the payload. >> >> Any TCP option that extends that space in any way needs to be in that >> area. >> >> DO can't be stripped. The options it makes space for can. Regardless of >> how a TCP option extends the DO space, if that happens mid-connection >> (again, a hypothetical only), the extension space will be interpreted as >> user data. It doesn't matter whether the additional space is at the >> front or end of the post-DO payload. > > I am not saying DO might be stripped. > > Syn-op-sis does not involve any additional TCP options in the TCP option > space, ie the space between the end of the 20B base TCP header and the > max 60B Data Offset. This makes each syn-op-sis segment /inherently/ > robust against option stripping. Oh, right - you've encoded the option opaquely in the data. That's not a TCP option anymore. TCP options are fields defined by the option structure defined in RFC793. You're defining a new way to signal the presence of options using a magic number. That's a lot of obfuscation in the absence of re-encoding the user data to avoid collision AND in the absence of a checksum. > All the additional options of syn-op-sis are beyond the Data Offset, > including the option that creates the additional space for the other > options. So they all share the same fate. Agreed. > Whereas, in EDO the option that creates the space beyond DO is not > itself beyond DO. Right, because it's a TCP option. > So the option that creates the space is at risk of > being stripped without stripping the space it created. The two do not > /inherently/ share the same fate. Correct. > Yes, checks can be added to EDO to check for option stripping (e.g. > deferring use of extra space until after the SYN/ACK). But this has to > assume that stripping behaviour remains consistent through the flow. Yes. Again, TCP is not a diagnostic tool. > Whereas, with syn-op-sis, each individual segment is robust against > option stripping, all by itself. > > I think this is what Mirja was referring to. > > >> > In the syn-op-sis approach, the extra space and the option that creates >> > the extra space are both beyond the Data Offset (both inner). So they >> > share fate. >> >> Even if that were true, it would mean that user data would be corrupted >> by both the option and the extension. > > * The syn-op-sis client ensures that it aborts the connection to a > legacy server before it passes this corrupt TCP Data to the app. You have to prohibit use of TFO (and maybe some others, e.g., TCPCT) with syn-op-sys in that case. > * And a syn-op-sis server catches this corrupt TCP data and removes the > options before passing the remaining payload to the app. > > This only relies on the endpoints, which are stateful, to maintain > consistent behaviour throughout the connection. Half-way through a > connection, a server isn't suddenly going to forget that it supports > syn-op-sis and start passing corrupt data to the app. > > Whereas it is not so certain that the experienced middlebox behaviour > will remain consistent throughout a connection. It might not be the same > middlebox in both directions, and the path might change to pass through > a different middlebox part-way through a connection. We have no evidence of middleboxes that suddenly appear on a path asymmetrically AND allow a connection to continue. However, if we did, we'd also have to consider devices that split segments without understanding options but which don't copy options (one of the cases described in the study). That breaks syn-op-sis in two ways: - user data is corrupted with the extended options - user data is interpreted as extended options incorrectly Note that a middlebox that splits segments but uses the options only on the first segment is likely to pass EDO uncorrupted and unaffected (presuming the extension is within the first segment). >> ... >> >> > One quick question for Bob: Is there a specific reason that >> you've put >> >> > the syn-op-sis option at the end (and not at the beginning) of the >> >> payload? >> >> >> >> I'll let Bob answer that in detail if desired; AFAICT, it's largely to >> >> allow middleboxes that don't understand the extension to be able to >> >> parse and process the data field. I think this is a mistake, >> because at >> >> some point in that field the data is corrupted, and it is just >> making a >> >> bet that such boxes should be supported until they silently fail. I'd >> >> prefer they just fail from the start. >> > >> > I suspect that what Joe says might happen with some middleboxes, ie. >> the >> > start of the payload looks like they would expect, but they suddently >> > find some unexpected bytes so they drop the packet. >> > >> > However, I'd like to experiment, because I suspect many of these >> > app-layer boxes will parse up to whatever point they need to, then >> stop. >> > So they won't ever notice the unexpected bytes at the end. For >> instance, >> > my employer's Web filter (that I'm sitting behind right now) looks for >> > the URL that is the argument to the HTTP GET command in order to decide >> > whether to block the page. It doesn't parse all the HTML, and it may >> not >> > even parse all the HTTP after the GET. These filters are widely used to >> > protect children from porn etc, and they are widely used for less noble >> > (usually commercial) purposes. >> >> Sure, and they might even parse HTTPS to the point of finding the SNI. >> >> > On 7 out of the 142 paths tested in Michio Honda et al "Is it Still >> > Possible to Extend TCP?" there was a box that silently dropped packets >> > to port 80 that contained unexpected data instead of valid HTTP. The >> > unexpected data was commands that the experimenters' had written into >> > the payload to control their echo-responder. They hadn't expected that >> > these commands would disrupt the experiment. I don't know of any >> > experiments that have included expected data followed by unexpected >> data. >> > >> > Whatever, in draft-03 of syn-op-sis (that I'm still working on), I've >> > put the extension options at the front by default, and made the trailer >> > mode optional (so experiments can be conducted to find if it is >> needed). >> >> If we do think that this case is common, then we can easily have all the >> extensions (SYN and otherwise) use space at the end of the segment. It >> can be something most variants can easily support in a flag, > > Yup. It's do-able,... > > ...but it's not completely straightforward. For instance, when I tried > to design against resegmentation, I suggested a "sent payload size" > field in an email to you. The idea was that the receiver could > reconstruct where the segment boundaries had been originally - in order > to find where the options had been put originally. > > However, the sender has to place the 'sent payload size' field at the > start of the segment it refers to. If it places it at the end of each > segment, the receiver has to wait until the very end of the stream > before it can work backwards to find where all the segments were - not a > lot of use. Right - the EDO still stays in the DO space, but the extension is at the tail. If we add the "original segment length" within EDO, then the receiver might be able to reconstitute the segment if split. However, because EDO would still be inside the DO space, the typical split would copy it into the first segment only. -- Note that I still think this is inappropriate for EDO. If we want TCP integrity restoration, we ought to design an option to achieve this. However, it presents a problem of how to process options that span segments when the ACK and header flags may differ. This turns TCP into a two-layer protocol - one layer for resegmentation and a different one for the control info. That seems silly - if we want that level of robustness, we ought to design a tunnel protocol specifically for that purpose. I repeat: TCP is not a diagnostic tool. >> FWIW - I >> doubt we actually need the entire extension space indicated so far. > > TCP is 33 years old. There's no point upgrading it now unless we ensure > enough space for another 30-50 years at least. > > When you start using options to transfer keys (e.g. TCPcrypt) they get > pretty big (and uncompressable of course). I know it's hard to predict > what key sizes will be needed (let alone what algorithms will have been > broken) over such timescales. However, I would be embarrassed if we > couldn't carry a 4096-bit (512B) key in newly enlarged option space. Well, you can barely do so now. EOO and EPOO are both one byte, so you can jump over roughly 1K of user payload (EOO). We already send packets larger than 1K, and if the key + user data is larger than 1K then EPOO is too small. They need to be roughly 14 bits (unless we consider jumbograms, at which point they need to be 30 bits). > TCPcrypt currently has to do its main key exchange in the payload, which > is messy. IMO, TCPcrypt is messy. TCP isn't out there to support EVERYTHING. Just like IP doesn't. > We should be ensuring that TCP supports whatever might need to > be done in the option space without each new option having to hack a > solution when the space is too small. Sometimes the answer to "I want to do that in TCP" can - and should - be "NO". > I take the view that we might as well allow the set of options to be as > large as the largest possible segment. That turns out not to be hard or > wasteful anyway. You'd burn 14 bytes total if you did that (EOO and EPOO need to be 30 bits each). Joe From nobody Tue Oct 14 20:52:09 2014 Return-Path: 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 E2E6A1A01E7 for ; Tue, 14 Oct 2014 20:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Vx27hR3TsE9T for ; Tue, 14 Oct 2014 20:52:04 -0700 (PDT) Received: from BAY004-OMC2S25.hotmail.com (bay004-omc2s25.hotmail.com [65.54.190.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129A41A011D for ; Tue, 14 Oct 2014 20:52:03 -0700 (PDT) Received: from BAY172-W7 ([65.54.190.125]) by BAY004-OMC2S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 14 Oct 2014 20:49:22 -0700 X-TMN: [tNxiRX8hErz3Rqrf8ssf+40AxExTUmkq] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_0c599978-4e7c-4df6-b833-ad0d26239d7f_" From: Anthony Sabatini To: tcpm , tcpm lars , tcpm Pasi Sarolahti , tcpm Yoshifumi Nishida Date: Tue, 14 Oct 2014 23:49:21 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Oct 2014 03:49:22.0106 (UTC) FILETIME=[015BB9A0:01CFE82B] Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/VDUgBSGkMkzoFs4SgioHux-m0XU Subject: [tcpm] RFC 793-bis comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 03:52:06 -0000 --_0c599978-4e7c-4df6-b833-ad0d26239d7f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [All - Please forgive my lack of comments=2C I have had surgery on both eye= s over the last six months - Tony] The purpose of revising a standard is to clarify and update it=2C but as im= portantly=2C to correct flaws which hinder future elaboration and standardi= zation.=20 There exists currently in TCP two such areas of concern=2C the offset field= and the use of multiple command bits such as SYN and FIN in the same packe= t.=20 Another area of concern is that the original RFC 793 document does not reco= gnize the existence of devices that will relay messages and the standards f= or forwarding and discarding of messages in that class of device=2C as oppo= sed to the behavior required of an end point device. The rules that require= the discarding of a message by an end point device are not applicable to a= transited device which must propagate all messages which it does not under= stand. It is crucial that the standard identify what conditions will be dis= carded by both devices and which shall be discarded by end point devices bu= t forwarded by transited devices. =20 One such condition is the setting of SYN and FIN in the same packet on an e= nd point device where this combination is undefined the packet should be di= scarded=2C but on a transited device the packet must be forwarded since fut= ure standardization may=2C for example=2C define this combination as indica= ting a new TCP service such as a maintenance or traffic control message.=20 The single biggest obstacle to improving TCP is the fact that the data offs= et field is both poorly defined and greatly limited. As currently defined h= alf the possible values are invalid and the options area which it defines i= s too small to provide the necessary space to allow options to fulfill thei= r full promise. Also being an offset it hard wires the size of a TCP header= preventing the addition of header fields in a future standard.=20 In the current standard the data offset field should be redefined as the le= ngth of the options field and values 0 - 7 should be defined as follows: "i= n normal use on an end point device a value of 0-7 should be discarded but = on a transited device should be forwarded. Values 0 -7 if present represen= t a TCP options area length of 32 - 60 bytes (8 - 15 32 bit words). Values= 0 - 7 in current use can only be used by negotiation via the options field= and thus cannot appear on a packet where a SYN is set" (subject to future = standardization current end point devices should discard a packet with SYN = and a value of 0 -7 transited devices should forward the packet).=20 Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 = --_0c599978-4e7c-4df6-b833-ad0d26239d7f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[All - Please forgive my lack of= comments=2C I have had surgery on both eyes over the last six months - Ton= y]

The purpose of revising a standard is to clarify and update it=2C= but as importantly=2C to correct flaws which hinder future elaboration and= standardization.

There exists currently in TCP two such areas of c= oncern=2C the offset field and the use of multiple command bits such as SYN= and FIN in the same packet.

Another area of concern is that the or= iginal RFC 793 document does not recognize the existence of devices that wi= ll relay messages and the standards for forwarding and discarding of messag= es in that class of device=2C as opposed to the behavior required of an end= point device. The rules that require the discarding of a message by an end= point device are not applicable to a transited device which must propagate= all messages which it does not understand. It is crucial that the standard= identify what conditions will be discarded by both devices and which shall= be discarded by end point devices but forwarded by transited devices. = =3B

One such condition is the setting of SYN and FIN in the same pa= cket on an end point device where this combination is undefined the packet = should be discarded=2C but on a transited device the packet must be forward= ed since future standardization may=2C for example=2C define this combinati= on as indicating a new TCP service such as a maintenance or traffic control= message.

The single biggest obstacle to improving TCP is the fact = that the data offset field is both poorly defined and greatly limited. As c= urrently defined half the possible values are invalid and the options area = which it defines is too small to provide the necessary space to allow optio= ns to fulfill their full promise. Also being an offset it hard wires the si= ze of a TCP header preventing the addition of header fields in a future sta= ndard.

In the current standard the data offset field should be rede= fined as the length of the options field and values 0 - 7 should be defined= as follows: "in normal use on an end point device a value of 0-7 should be= discarded but on a transited device should be forwarded. =3B Values 0 = -7 if present represent a TCP options area length of 32 - 60 bytes (8 - 15&= nbsp=3B 32 bit words). Values 0 - 7 in current use can only be used by nego= tiation via the options field and thus cannot appear on a packet where a SY= N is set" (subject to future standardization current end point devices shou= ld discard a packet with SYN and a value of 0 -7 transited devices should f= orward the packet).








Anthony Sabatini200 =3BWest 20th Street
Apt. 1216
New York=2C NY 10011

Ph= one: (212) 867-7179
Mobile: (917) 224-8388

 =3B
=
= --_0c599978-4e7c-4df6-b833-ad0d26239d7f_-- From nobody Wed Oct 15 07:09:55 2014 Return-Path: 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 D09C31A7009 for ; Wed, 15 Oct 2014 07:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 aaKP0KcnBL_s for ; Wed, 15 Oct 2014 07:09:47 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E13F1A7020 for ; Wed, 15 Oct 2014 07:09:47 -0700 (PDT) Received: from [IPv6:::1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9FE9e05002727; Wed, 15 Oct 2014 09:09:40 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Borman In-Reply-To: Date: Wed, 15 Oct 2014 09:09:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <52E5A6AC-6DFE-4599-996D-752BFE5667A3@weston.borman.com> References: To: Anthony Sabatini X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/C54azliR5sR-AvAA4bj2XZexwe0 Cc: tcpm Subject: Re: [tcpm] RFC 793-bis comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:09:50 -0000 On Oct 14, 2014, at 10:49 PM, Anthony Sabatini = wrote: ... > Another area of concern is that the original RFC 793 document does not = recognize the existence of devices that will relay messages and the = standards for forwarding and discarding of messages in that class of = device, as opposed to the behavior required of an end point device. The = rules that require the discarding of a message by an end point device = are not applicable to a transited device which must propagate all = messages which it does not understand. It is crucial that the standard = identify what conditions will be discarded by both devices and which = shall be discarded by end point devices but forwarded by transited = devices. =20 >=20 > One such condition is the setting of SYN and FIN in the same packet on = an end point device where this combination is undefined the packet = should be discarded, but on a transited device the packet must be = forwarded since future standardization may, for example, define this = combination as indicating a new TCP service such as a maintenance or = traffic control message. If only it were true that "transited device which must propagate all = messages which it does not understand=94, but that=92s not the reality. Though TCP is an end-to-end protocol, middle boxes delve into the TCP = header and make decisions on whether or not a packet is acceptable, = breaking the end-to-end nature of TCP. It is sad that this has become = the reality, and every proposed enhancement to TCP now has to consider = how it will survive through middle boxes. > The single biggest obstacle to improving TCP is the fact that the data = offset field is both poorly defined and greatly limited. As currently = defined half the possible values are invalid and the options area which = it defines is too small to provide the necessary space to allow options = to fulfill their full promise. Also being an offset it hard wires the = size of a TCP header preventing the addition of header fields in a = future standard.=20 >=20 > In the current standard the data offset field should be redefined as = the length of the options field and values 0 - 7 should be defined as = follows: "in normal use on an end point device a value of 0-7 should be = discarded but on a transited device should be forwarded. Values 0 -7 if = present represent a TCP options area length of 32 - 60 bytes (8 - 15 32 = bit words). Values 0 - 7 in current use can only be used by negotiation = via the options field and thus cannot appear on a packet where a SYN is = set" (subject to future standardization current end point devices should = discard a packet with SYN and a value of 0 -7 transited devices should = forward the packet). Redefining the meaning of Data Offset values 0-4 (5-7 are valid) is not = a new idea, see http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00. = As with any proposal for expanding the TCP option space, the biggest = challenge is trying to make use of it in the initial SYN and still = maintain backwards compatibility. -David Borman From nobody Wed Oct 15 07:50:56 2014 Return-Path: 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 851931A8735 for ; Wed, 15 Oct 2014 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 2aD_Nu0C46rj for ; Wed, 15 Oct 2014 07:50:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB161A8732 for ; Wed, 15 Oct 2014 07:50:52 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-50.lsanca.dsl-w.verizon.net [71.103.148.50]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9FEo6V5028612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Oct 2014 07:50:15 -0700 (PDT) Message-ID: <543E89A0.7040607@isi.edu> Date: Wed, 15 Oct 2014 07:50:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Anthony Sabatini , tcpm , tcpm lars , tcpm Pasi Sarolahti , tcpm Yoshifumi Nishida References: In-Reply-To: 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/OHV5nxu1bnwQ4RSpr_A1pr_kXKM Subject: Re: [tcpm] RFC 793-bis comments X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:50:54 -0000 On 10/14/2014 8:49 PM, Anthony Sabatini wrote: > [All - Please forgive my lack of comments, I have had surgery on both > eyes over the last six months - Tony] > > The purpose of revising a standard is to clarify and update it, but as > importantly, to correct flaws which hinder future elaboration and > standardization. I disagree. AFAICT, changes to TCP need to be proposed and vetted separately from the process of integrating those changes into RFC793-bis. > There exists currently in TCP two such areas of concern, the offset > field and the use of multiple command bits such as SYN and FIN in the > same packet. Behavior in that case is clearly defined in RFC793: eighth, check the FIN bit, Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT since the SEG.SEQ cannot be validated; drop the segment and return. > Another area of concern is that the original RFC 793 document does not > recognize the existence of devices that will relay messages and the > standards for forwarding and discarding of messages in that class of > device, as opposed to the behavior required of an end point device. That's because TCP is a protocol between endpoints. Any intermediate device that interprets or modifies TCP is acting (correctly or incorrectly) on behalf of those endpoints. We need to make sure that such middleboxes act correctly in that regard. I disagree that we need to make TCP robust to any intermediate participation. A protocol has rules and defined behavior. Take that away and it's no longer a protocol. Sometimes the answer has to be "NO, that's not permitted". > The > rules that require the discarding of a message by an end point device > are not applicable to a transited device which must propagate all > messages which it does not understand. It is crucial that the standard > identify what conditions will be discarded by both devices and which > shall be discarded by end point devices but forwarded by transited > devices. > > One such condition is the setting of SYN and FIN in the same packet on > an end point device where this combination is undefined the packet > should be discarded, but on a transited device the packet must be > forwarded since future standardization may, for example, define this > combination as indicating a new TCP service such as a maintenance or > traffic control message. That depends on whether the intermediate device is acting as a router (in which case it shouldn't even be looking at the transport header) or acting on behalf of an endpoint. Whenever it acts on behalf of an endpoint, it limits that endpoint as well -- the overall protocol behavior is the intersection of all devices that participate in the protocol. > The single biggest obstacle to improving TCP is the fact that the data > offset field is both poorly defined and greatly limited. It is very clearly defined. I agree that it is limited. > As currently > defined half the possible values are invalid and the options area which > it defines is too small to provide the necessary space to allow options > to fulfill their full promise. Also being an offset it hard wires the > size of a TCP header preventing the addition of header fields in a > future standard. > > In the current standard the data offset field should be redefined as the > length of the options field and values 0 - 7 should be defined as > follows: We've discussed this many times before; it is not possible to redefine that (or most other) TCP fields in ways that don't affect legacy implementations. If you have a proposal for doing this, it would be useful to review those past discussions as well as to explain how you intend to support legacy endpoints. That would be a separate document that would need to be accepted as a standards-track change to TCP before being considered for a revision to RFC793. Because the current revision of RFC793 is underway, IMO all such new proposals are not part of the current revision. Joe From nobody Wed Oct 15 12:08:58 2014 Return-Path: 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 EA73C1A9126 for ; Wed, 15 Oct 2014 12:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 tuOv45ql2w9A for ; Wed, 15 Oct 2014 12:08:54 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 595E51A1B19 for ; Wed, 15 Oct 2014 12:08:50 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 04FC4C94CB; Wed, 15 Oct 2014 15:08:41 -0400 (EDT) Date: Wed, 15 Oct 2014 15:08:40 -0400 From: John Leslie To: David Borman Message-ID: <20141015190840.GW83009@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/tWi-sBnzIAungd9gATcja9FpTpM Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:08:56 -0000 David Borman wrote: > > I?ve just posted draft-borman-tcp4way-00.txt, which describes a > 4-Way TCP handshake that is intended to allow the TCP EDO option > to be used during the initial SYN exchange. This was mentioned > during the TCPM WG at the last IETF meeting. Please see the draft > for more details. Thanks for this draft! I wanted to read it twice before responding -- and I'm still not ready to discuss it at length... I have (so far) one comment and one question for David. The comment: The draft proposed allocating one of the three remaining Reserved bits in the TCP header; but Appendix B says this is not necessary to the proposal. Intuitively, I feel that to allocate one of the Reserved bits would need to be justified by something more than expanding option space. Are there any other uses of the four-way-handshake envisioned? The question: David notes the simultaneous-open case in his introduction; but I don't follow how simultaneous-open would resolve in this proposal. Clearly, simultaneous-open, however rare, could still happen... -- John Leslie From nobody Wed Oct 15 12:14:46 2014 Return-Path: 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 6B3B11A9149 for ; Wed, 15 Oct 2014 12:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 seqj0lKtcqf1 for ; Wed, 15 Oct 2014 12:14:39 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B4C271A9143 for ; Wed, 15 Oct 2014 12:14:39 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 31213C94CB; Wed, 15 Oct 2014 15:14:37 -0400 (EDT) Date: Wed, 15 Oct 2014 15:14:37 -0400 From: John Leslie To: Joe Touch Message-ID: <20141015191437.GX83009@verdi> References: <20141013172333.7207.76001.idtracker@ietfa.amsl.com> <543C0D6D.60302@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543C0D6D.60302@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/eoKoVjhvcrL5zFK3MYooVs0GO30 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:14:44 -0000 Joe Touch wrote: > > We just posted an update to the EDO doc: > > Primary changes: > - added Implementation details section (8) based on Pasi and my student > - change the option to indicate length in 4-byte words > (simpler to unify with DO use, as suggested by Pasi) > - include experimental option ExID (0x0ED0) > which has already been confirmed with IANA >... I take this to be a "WG snapshot" appropriate for implementors to implement from for experimental purposes. As such I endorse it. Actual implementations and experiments will be very helpful. But the actual changes, in some cases, seem premature to call WG consensus. I trust that we will consider them more carefully before the WGCs call consensus on them. -- John Leslie From nobody Wed Oct 15 12:44:18 2014 Return-Path: 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 1C5901A6FCF for ; Wed, 15 Oct 2014 12:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0pFeqYyQqiuU for ; Wed, 15 Oct 2014 12:44:11 -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 9B4301A894A for ; Wed, 15 Oct 2014 12:44:11 -0700 (PDT) Received: from [10.123.107.145] (usc-secure-wireless-207-145.usc.edu [68.181.207.145]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9FJhhuA021678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Oct 2014 12:43:46 -0700 (PDT) References: <20141013172333.7207.76001.idtracker@ietfa.amsl.com> <543C0D6D.60302@isi.edu> <20141015191437.GX83009@verdi> In-Reply-To: <20141015191437.GX83009@verdi> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <030690BE-1C10-4AD9-8E20-5D9E83F09AAC@isi.edu> X-Mailer: iPhone Mail (12A405) From: Joe Touch Date: Wed, 15 Oct 2014 12:43:43 -0700 To: John Leslie 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/qO3xC7t7MR9yOYpzJb2ea7THdKA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:44:15 -0000 > On Oct 15, 2014, at 12:14 PM, John Leslie wrote: > > Joe Touch wrote: >> >> We just posted an update to the EDO doc: >> >> Primary changes: >> - added Implementation details section (8) based on Pasi and my student >> - change the option to indicate length in 4-byte words >> (simpler to unify with DO use, as suggested by Pasi) >> - include experimental option ExID (0x0ED0) >> which has already been confirmed with IANA >> ... > > I take this to be a "WG snapshot" appropriate for implementors to > implement from for experimental purposes. As such I endorse it. > Actual implementations and experiments will be very helpful. > > But the actual changes, in some cases, seem premature to call WG > consensus. I trust that we will consider them more carefully before > the WGCs call consensus on them. Yes that was the intent. Joe > > -- > John Leslie From nobody Wed Oct 15 12:52:01 2014 Return-Path: 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 A0EE61A894A for ; Wed, 15 Oct 2014 12:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 tmC5EfjPTTq7 for ; Wed, 15 Oct 2014 12:51:51 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0270C1A90AE for ; Wed, 15 Oct 2014 12:51:48 -0700 (PDT) Received: from [IPv6:::1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9FJpivs009047; Wed, 15 Oct 2014 14:51:45 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Borman In-Reply-To: <20141015190840.GW83009@verdi> Date: Wed, 15 Oct 2014 14:51:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <136DF0AE-9D8C-491A-BB0C-59CA6BD911C2@weston.borman.com> References: <20141015190840.GW83009@verdi> To: John Leslie X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/M5fwR2Ttxq0FsQRm83uHf1SVV9k Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:51:53 -0000 On Oct 15, 2014, at 2:08 PM, John Leslie wrote: > David Borman wrote: >>=20 >> I?ve just posted draft-borman-tcp4way-00.txt, which describes a >> 4-Way TCP handshake that is intended to allow the TCP EDO option >> to be used during the initial SYN exchange. This was mentioned >> during the TCPM WG at the last IETF meeting. Please see the draft >> for more details. >=20 > Thanks for this draft! >=20 > I wanted to read it twice before responding -- and I'm still not > ready to discuss it at length... >=20 > I have (so far) one comment and one question for David. >=20 > The comment: > The draft proposed allocating one of the three remaining Reserved bits > in the TCP header; but Appendix B says this is not necessary to the > proposal. What I meant was using a reserved bit wasn=92t the only way to indicate support for the four-way handshake. It can also be achieved via a new explicit 4WAY TCP option, or implied support by the presence of some other TCP option, such as EDO. Any of the methods would work. I chose to pick one method for the main body of the document, and present the alternatives in Appendix B. >=20 > Intuitively, I feel that to allocate one of the Reserved bits would > need to be justified by something more than expanding option space. > Are there any other uses of the four-way-handshake envisioned? It provides a general mechanism to allow the connection initiator a second chance during the SYN exchange, based on responses from the server. The EDO case is a concrete example, where the initiator couldn=92t put in all the options they wanted to include in the initial exchange due to the limited size of the option space. It=92s interesting to note that EDO is actually a new version of the TCP header, and it=92s not the first; the Window Scale option also created a new version of the TCP header. Most of the attempts at expanding the option space are working very hard at hiding this fact, in the name of backwards compatibility and getting through middle boxes. While the four-way handshake would be used for EDO support in the SYN exchange, it is not limited to just EDO. It can be used for any TCP modification where you would have done something different in the initial SYN had you known that the other side understood the modification. But the ironic part is that once you have EDO, you have the ability to put just about anything into the initial SYN by putting it into an option. It=92d be trivial to switch to an entirely new TCP header layout by including the new layout in a TCP option, something you just can=92t do today because of the limited initial option space. I chose to start with recommending using a reserved bit because then it isn=92t using up even more option space, which matters most when talking to legacy TCP implementations, and it doesn=92t explicitly tie it to the EDO option. > The question: > David notes the simultaneous-open case in his introduction; but I > don't follow how simultaneous-open would resolve in this proposal. > Clearly, simultaneous-open, however rare, could still happen=85 Ah, the simultaneous open was my inspiration for the 4-way handshake. It also has a 4 packet exchange, crossing SYNs and then crossing SYN/ACKs. In the simultaneous-open case, the state transitions when viewed by one side are: CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED. With the 4-way handshake, the initiator makes the same transitions: CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED. That=92s why I originally envisioned the first response being a bare SYN, which would make it look on the wire even more like a simultaneous open. But however elegant that might seem, I think it is a non-starter because of middle boxes that would probably block the returning bare SYN. -David >=20 > -- > John Leslie From nobody Thu Oct 16 05:21:44 2014 Return-Path: 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 3C86F1A1ACD for ; Thu, 16 Oct 2014 05:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 tys8-o1-9g6u for ; Thu, 16 Oct 2014 05:21:41 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF721A0022 for ; Thu, 16 Oct 2014 05:21:41 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so4530597wiv.15 for ; Thu, 16 Oct 2014 05:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; bh=u/jqYidkbUL5eG04CTMXXq8YB5UoGfN/sLUBndoYKuM=; b=Dw1ngR2VvbXxRMoFKpqdT1klLLg5N6NG1tNbp/sKltfhC/uJBVAI7Mhi//iPzeydJZ IGiYIWHmsZkeJb21VCIpkL8j8Jk9pbKF1KIG7DYQ0RgewLZD919oisH/xHw6EQFPJ1Hu sEElt2Aq5Jt05kNjjclT4uqD1Lx1lXW0dtPV9fHnMZDRwyQJRiW/TVHplUwm5Uiv87kW d4D4816QJIktHoH/XyEqq7N6e3KlF9aQNT5apI2oLFzmaV/EO7C3TfYiAcALYexE9ENL otIaehKmokALYTjLpPsHQqETMQ73bP0C5pNAc/wG8g+BcFt14Gyt1XsvLwy4OhVeRPNx Hbdw== X-Received: by 10.180.149.169 with SMTP id ub9mr5554737wib.73.1413462099943; Thu, 16 Oct 2014 05:21:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.12.65 with HTTP; Thu, 16 Oct 2014 05:21:19 -0700 (PDT) From: Raffaello Secchi Date: Thu, 16 Oct 2014 13:21:19 +0100 Message-ID: To: Neal Cardwell , "Zimmermann, Alexander" , Yuchung Cheng , "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4QjA0jcpTAIV3etz4syBX6D1EJ4 Subject: Re: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: r.secchi@gmail.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 12:21:43 -0000 Dear Yuchung, Mirja, Alex et al, So we've now had time to revisit the changes to Linux and the differences between the ID and the Linux code. A patch was submitted and followed the ID. This was available up to Linux 3.15. In Linux, there was an update submitted that conflicted with the new-cwv patch, so new-cwv is not now supported - we think this is what was recently discussed on the list. From what we understand, the conflicting update centred around fixed needs to support TSO. This was explained in the email from Yuchung on 22/09/2014 describes this work from Neal Cardwell. To us, it seems this does not implement a window validation procedure, so this isn't the same as new-cwv. We'll highlight what we see are the key differences below, and others may comment - especially if we get this wrong. --- new-cwv as described in the ID proposes is a list of things that are needed to validate the path capacity and manage the cwnd. + FS v. pipeACK An important part of the draft (section 4.2) requires a path to be validated before using the path capacity information - in contrast, traditional TCP used the flight size as an estimate of capacity, assuming that in the last RTT the sender sent at least FS and this must have been ACK'ed. new-cwv in contrast, does not make this assumption (this would be "bold" for a varying rate app - which may have sent little of nothing in the last RTT or so). This lead us to introduce pipeACK. This adds some complexity but is robust - specifically it does not base decisions on data sent in the last RTT (FS), but builds a history of the peak capacity available in recent history. The recent Linux patches preserve cwnd (similar to new-cwv 4.3) but uses the (non-validated) FS instead of pipeACK. This has three side effects: 1) It doesn't validate the capacity so a sender that resumes sending, uses FS for calculation, and resumes sending faster. The new-cwv ID recommends cwnd is increased in data-limited conditions only if segment transmissions can be validated. This prevents for example the cwnd from increasing for at least one RTT when resuming after an idle period and limits the damage to cwnd in case of congestion. 2) A bursty app can now result in a cwnd that is far less than the recent capacity, and is very very conservative for a busty sender. If a loss is met during a data-limited period of low-rate transmission, cwnd goes back to RW. We propose to use pipeack instead which consider the transmission history in the last second. 3) FS can be more variable than pipeack. In the Linux code, the variable max_packets_out is set to the maximum of FS for the previous RTT. Considering that the FS can be very variable for a bursty sender, we think that taking the maximum is the right thing to obtain a stable reference. We recommended extending the period over which the maximum is calculated to at least one second. + By default Linux does not keep the cwnd open for long idle-periods. It uses CWV to decay cwnd exponentially instead. Closing cwnd exponentially degrades performance of some bursty apps and creates a dependency between TCP performance and RTT. Linux currently offers the 'tcp_slow_start_after_idle' switch to disable this behaviour. If tcp_slow_start_after_idle is disabled, TCP keeps cwnd indefinitely. new-CWV recommends keeping cwnd for at most for five minutes, after which cwnd is reduced to align the congestion state to the new data-limited regime. Not closing the cwnd may be dangerous if the connection produces larger-than-usual bursts and anyway is incompatible with the idea that the cwnd has been (recently) validated. + Current Linux does not take into account the number of retransmissions in resetting cwnd after a loss episode - this can be a significant issue when the previous cwnd proves invalid (e.g. due to a path change). For this reason, new-CWV section 4.4.1. encourages a (D-R)/2 reduction after the FR. In this case, the number of retransmissions 'R' may be significant compared to the FS 'D'. We expect (D-R)/2 to converge the cwnd faster to the new sustainable rate. There could be a chance that R is over conservative - however this is not likely to often be significant, since the clause only applies when the sender was non-validated. A patch was also submitted to FreeBSD which is compliant with the new-cwv ID. We hope this helps explain where we have arrived, and if there is interest from the community, we would be glad to resubmit an updated patch to implement new-cwv. Raffaello & Gorry From nobody Thu Oct 16 11:42:21 2014 Return-Path: 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 C356C1A01D6 for ; Thu, 16 Oct 2014 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 yZLffqLTzRLq for ; Thu, 16 Oct 2014 11:42:16 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1D49F1A0199 for ; Thu, 16 Oct 2014 11:42:16 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 54194991028D4B6D for tcpm@ietf.org; Thu, 16 Oct 2014 21:42:15 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 16 Oct 2014 21:42:14 +0300 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LJbYqcYEbyb8VH7cStK7SZ_Qdy8 Subject: [tcpm] draft-ietf-tcpm-edo-01 status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:42:18 -0000 Hi, There has been pretty much discussion related to draft-ietf-tcpm-edo = recently, so here is an attempt to summarize it. Hopefully we'd also get = input from a wider set of TCPM people, who haven=92t yet stated their = opinion. Shout if I misrepresented something, or forgot something = important. So the main issue has been the possible interactions with middleboxes = that may drop options, or blindly copy them while re-segmenting the = data. Here are the main discussion points (or recent changes in -01), on = which additional opinions would be useful: 1: Can the EDO extension be allowed in SYN/ACK? =93Yes" would be nice, = but an option-removing middlebox on return path would cause corruption = of data (currently not allowed in -01). 2: MUST the EDO option be included in all subsequent segments after = being negotiated? If this is required, lack of EDO option would cause = the segment to be dropped (currently required in -01). 3: To detect segment coalescing, should there be a mechanism to detect = that the segment modified? (not in -01). I recall two ways that have = been suggested for this: a) indicating payload size b) checksum An additional question to the above is, whether such mechanism should be = part of EDO option, or a separate option in a separate document (in = which case it might have also some use outside of EDO)? Following this Email, I will start three Email threads for each of the = above topics, hoping to organize the follow-up discussion a bit. An overall consideration is, how cautiously should we consider different = possible middlebox behaviors in our protocol design? EDO is a sensitive = case, because in the worst case failures could cause corruption of data, = but this is also a broader question we are every once in a while facing = with different TCP extensions. The question of intended document status has also come up, but I=92d = suggest that we focus on the technical content first, and return to the = status later. Based on the current discussion, it seems obvious that at = some point before the WGLC we=92d need to re-check this. (This is not = the first time we seem to struggle with the PS vs. Exp determination. = Typically we have been quite =97 or maybe too? =97 conservative in = taking the standards track.) - Pasi From nobody Thu Oct 16 12:08:52 2014 Return-Path: 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 46C0C1A87C5 for ; Thu, 16 Oct 2014 12:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 JaFnVwsKr4Ry for ; Thu, 16 Oct 2014 12:08:49 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id D5B191A87C4 for ; Thu, 16 Oct 2014 12:08:48 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 543C16C90046AE25; Thu, 16 Oct 2014 22:08:48 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> Date: Thu, 16 Oct 2014 22:08:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ma27la0XeNHKVZib7BMsjgGjHb0 Cc: draft-ietf-tcpm-tcp-edo@tools.ietf.org Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:08:50 -0000 In case you wonder about the mail format, I just thought to test the = tools=92 issue tracker=85 But let these be the three email threads I = mentioned in previous mail. - Pasi On 16 Oct 2014, at 21:53, tcpm issue tracker = wrote: > #17: Can the EDO extension be allowed in SYN/ACK? >=20 > =93Yes" would be nice, but an option-removing middlebox on return path = would > cause corruption of data >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-tcpm-tcp- > pasi.sarolahti@iki.fi | edo@tools.ietf.org > Type: task | Status: new > Priority: major | Milestone: > Component: tcp-edo | Version: > Severity: - | Keywords: > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > tcpm >=20 From nobody Thu Oct 16 12:22:05 2014 Return-Path: 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 2F9111A883A for ; Thu, 16 Oct 2014 12:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qsQshU0ZPtaE for ; Thu, 16 Oct 2014 12:22:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B4C1A8837 for ; Thu, 16 Oct 2014 12:22:02 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9GJLGOf008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 12:21:16 -0700 (PDT) Message-ID: <54401AAC.1050607@isi.edu> Date: Thu, 16 Oct 2014 12:21:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Pasi Sarolahti , "tcpm@ietf.org Extensions" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/94o1ZcAVaoXnMe0sN3rfjFf1zMk Subject: Re: [tcpm] draft-ietf-tcpm-edo-01 status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:22:04 -0000 On 10/16/2014 11:42 AM, Pasi Sarolahti wrote: > Hi, > > There has been pretty much discussion related to draft-ietf-tcpm-edo > recently, so here is an attempt to summarize it. Hopefully we'd also get > input from a wider set of TCPM people, who haven’t yet stated their > opinion. Shout if I misrepresented something, or forgot something important. > > So the main issue has been the possible interactions with > middleboxes that may drop options, or blindly copy them while > re-segmenting the data. Here are the main discussion points (or > recent changes in -01), on which additional opinions would be useful: It would be very useful to consider the summary in the current document (01) that explains which middlebox behaviors have been seen to date. I'll respond within each thread to the proposals, although I think this is all one integrated concern. Joe From nobody Thu Oct 16 12:22:21 2014 Return-Path: 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 951511A8844 for ; Thu, 16 Oct 2014 12:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Vowwc_LGik22 for ; Thu, 16 Oct 2014 12:22:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9361A8842 for ; Thu, 16 Oct 2014 12:22:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9GJLKMh008084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 12:21:20 -0700 (PDT) Message-ID: <54401AB0.6030503@isi.edu> Date: Thu, 16 Oct 2014 12:21:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tcpm issue tracker , draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> In-Reply-To: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/dzbcdYAQxcJUE8dL-ek9YTC4PVo Cc: tcpm@ietf.org Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:22:19 -0000 On 10/16/2014 11:53 AM, tcpm issue tracker wrote: > #17: Can the EDO extension be allowed in SYN/ACK? > > “Yes" would be nice, but an option-removing middlebox on return path would > cause corruption of data I am skeptical of asymmetric paths through middleboxes that ALSO allow TCP connections to pass. I.e., asymmetric paths involving NATs would fail. I would prefer if we considered detecting this condition (Bob suggested adding some sort of length indicator in the EDO option itself) rather than prohibiting it. Joe From nobody Thu Oct 16 12:22:33 2014 Return-Path: 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 452C61A01D6 for ; Thu, 16 Oct 2014 12:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 4oKasO-dboKL for ; Thu, 16 Oct 2014 12:22:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E1D1A8837 for ; Thu, 16 Oct 2014 12:22:27 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9GJLM6r008094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 12:21:22 -0700 (PDT) Message-ID: <54401AB2.5070200@isi.edu> Date: Thu, 16 Oct 2014 12:21:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tcpm issue tracker , draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> In-Reply-To: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> Content-Type: text/plain; charset=utf-8 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/6IHWT_LaapIUSH5HjCl5u_WeZcQ Cc: tcpm@ietf.org Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:22:32 -0000 On 10/16/2014 12:01 PM, tcpm issue tracker wrote: > #18: MUST the EDO option be included in all subsequent segments after being > negotiated? > > If this is required, lack of EDO option would cause the segment to be > dropped I think the same answer to #1 applies here. The only way this would be of concern is if such an "asymmetric middlebox that also passes TCP" appeared on-path mid-connection. Again, such a middlebox is hypothetical AFAICT, but given the impact, I can see adding the length validation inside EDO to detect this condition. Joe From nobody Thu Oct 16 12:22:47 2014 Return-Path: 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 0D0241A8837 for ; Thu, 16 Oct 2014 12:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 DsazBdBBcLqS for ; Thu, 16 Oct 2014 12:22:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C451A884B for ; Thu, 16 Oct 2014 12:22:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9GJLOOD008099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 12:21:24 -0700 (PDT) Message-ID: <54401AB4.3000609@isi.edu> Date: Thu, 16 Oct 2014 12:21:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tcpm issue tracker , draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi References: <060.f99902df883b40f9ffc6e90ae7377494@trac.tools.ietf.org> In-Reply-To: <060.f99902df883b40f9ffc6e90ae7377494@trac.tools.ietf.org> Content-Type: text/plain; charset=utf-8 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/E6NME1G2WzxbwRDM2Oau-rINkUo Cc: tcpm@ietf.org Subject: Re: [tcpm] #19 (tcp-edo): Should there be a mechanism to detect that the segment modified? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:22:44 -0000 On 10/16/2014 12:04 PM, tcpm issue tracker wrote: > #19: Should there be a mechanism to detect that the segment modified? > > I recall two ways that have been suggested for this: > > a) indicating payload size > b) checksum > > An additional question to the above is, whether such mechanism should be > part of EDO option, or a separate option in a separate document (in which > case it might have also some use outside of EDO)? As with both Issues #17 and #18, I think we can include something to detect when this would corrupt a segment. IMO, we don't need anything as computationally complex as a checksum, so I prefer something based on length. Your original post included the following: > An additional question to the above is, whether such mechanism > should be part of EDO option, or a separate option in a separate > document (in which case it might have also some use outside of EDO)? If it's integrated we could save two bytes in the base header, but I don't think that's necessary. I continue to believe that TCP is not itself a diagnostic. I don't like the idea of building diagnostics into every capability we add; I prefer an orthogonal approach. Joe From nobody Thu Oct 16 15:34:40 2014 Return-Path: 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 B176B1A8ABE for ; Thu, 16 Oct 2014 15:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 KflY44i-BQrR for ; Thu, 16 Oct 2014 15:34:33 -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 F14891A8ABB for ; Thu, 16 Oct 2014 15:34:32 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9GMYBdU003365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 15:34:12 -0700 (PDT) Message-ID: <544047E3.8080900@isi.edu> Date: Thu, 16 Oct 2014 15:34:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman , "tcpm@ietf.org (tcpm@ietf.org)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/4FFZTkeVNiFwM-iP7eO6XZuFkGw Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:34:37 -0000 On 10/14/2014 2:44 PM, David Borman wrote: > I’ve just posted draft-borman-tcp4way-00.txt Some comments below. Joe > The TCP packet format has 54 bytes for adding TCP options TCP currently has only 40 bytes of option space, not 54 the DO can be 0..15 in 4-byte words that's 0 to 60 bytes of header, including the default 20 which leaves 40 for options (reserved bits or other redefined header fields are not options; IMO, options are the fields with a given structure as defined in RFC793) > If both sides send and receive a given option in a > packet with the SYN bit set, then both sides know that the option is > supported. In current TCP, new options are indicated in the bare SYN and confirmed in the SYN-ACK. The above isn't explicit in how this exchange happens. ----- We've already discussed the latency impact for the initial client->server request, i.e., one additional RTT. I'm not sure I agree with the claims here about option directionality; it overlooks the fact that current TCP allows the client to decide what options to use on a given connection, subsetted by what the server accepts. For that to happen here, you need a lot more text in how option processing is radically different during 4WHS: - this still needs extended space in the server->client SYN, and since you haven't tested EDO in both directions you can't assume it will pass without silent asymmetric removal (see below); if you don't have that space, you're back where you started from because you'd need a 5WHS at least. - the options offered by the server need to be ALL POSSIBLE options the client may want to activate, which could be large even without variation - the client still needs to be able to be the one to decide which options are used IMO, which means you still have a problem with going to ESTABLISHED before you do a TWHS on the options *actually used* e.g., what if: the client wants A, B, C the server offers A,B,C,D,E,F,G but can't do A,B,C together the client picks A,B,C for the SYN/ACK but the server would have to terminate the connection and the client may have accepted data on an invalid connection As noted in the discussion of EDO during SYN/ACK, *if* we believe there are middleboxes that might silently drop EDO asymmetrically BUT ALSO allow TCP to pass asymmetrically, then we can't rely on EDO to extend space in the SYN/ACK. ---- From nobody Thu Oct 16 23:52:53 2014 Return-Path: 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 C054C1A90EB for ; Thu, 16 Oct 2014 23:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 99ymRx3IREXw for ; Thu, 16 Oct 2014 23:52:49 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02FC1A90EA for ; Thu, 16 Oct 2014 23:52:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,737,1406617200"; d="asc'?scan'208";a="203983579" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx12-out.netapp.com with ESMTP; 16 Oct 2014 23:52:46 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 16 Oct 2014 23:52:29 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Thu, 16 Oct 2014 23:52:28 -0700 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? Thread-Index: AQHP6XZdCTtCBD62nkiKtilDQ6Pcopw0UFKA Date: Fri, 17 Oct 2014 06:52:28 +0000 Message-ID: <13B3A7D2-81EA-43EB-AF02-ADFF195277C4@netapp.com> References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> <54401AB0.6030503@isi.edu> In-Reply-To: <54401AB0.6030503@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_33D67BFC-BDEB-44B0-8040-F44B0AB09766"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HkrnTHft59TXho2NfJPdbHYVbCA Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-tcp-edo@tools.ietf.org" , tcpm issue tracker Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 06:52:52 -0000 --Apple-Mail=_33D67BFC-BDEB-44B0-8040-F44B0AB09766 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Am 16.10.2014 um 21:21 schrieb Joe Touch : >=20 >=20 > On 10/16/2014 11:53 AM, tcpm issue tracker wrote: >> #17: Can the EDO extension be allowed in SYN/ACK? >>=20 >> =93Yes" would be nice, but an option-removing middlebox on return = path would >> cause corruption of data >=20 > I am skeptical of asymmetric paths through middleboxes that ALSO allow > TCP connections to pass. >=20 > I.e., asymmetric paths involving NATs would fail. I fully agree w/ Joe on this point. >=20 > I would prefer if we considered detecting this condition (Bob = suggested > adding some sort of length indicator in the EDO option itself) rather > than prohibiting it. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_33D67BFC-BDEB-44B0-8040-F44B0AB09766 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRAvLsACgkQdyiq39b9uS6F4ACfe5RyPR4DWSKxXhy1m/cy4gZP nzIAnR1pfEuRO1AeF0gdCj3yjovbUQKn =I6Y+ -----END PGP SIGNATURE----- --Apple-Mail=_33D67BFC-BDEB-44B0-8040-F44B0AB09766-- From nobody Thu Oct 16 23:53:50 2014 Return-Path: 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 251AD1A90EA for ; Thu, 16 Oct 2014 23:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 V5JBNmXxJZIx for ; Thu, 16 Oct 2014 23:53:45 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AE71A90E8 for ; Thu, 16 Oct 2014 23:53:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,737,1406617200"; d="asc'?scan'208";a="161446763" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx11-out.netapp.com with ESMTP; 16 Oct 2014 23:53:44 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 16 Oct 2014 23:53:28 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Thu, 16 Oct 2014 23:53:28 -0700 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: [tcpm] #19 (tcp-edo): Should there be a mechanism to detect that the segment modified? Thread-Index: AQHP6XaLzdN0zHvwAEmIaSkvtDhnypw0UJSA Date: Fri, 17 Oct 2014 06:53:27 +0000 Message-ID: <969ED532-1389-43D6-A1C4-CC97D4EA2F2C@netapp.com> References: <060.f99902df883b40f9ffc6e90ae7377494@trac.tools.ietf.org> <54401AB4.3000609@isi.edu> In-Reply-To: <54401AB4.3000609@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.120.60.35] Content-Type: multipart/signed; boundary="Apple-Mail=_4B28981C-12FF-4D33-8349-EC0D1DDDAEE3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZRwGlECSvrJy8CTZBmbrgkbAo30 Cc: "tcpm@ietf.org" , "draft-ietf-tcpm-tcp-edo@tools.ietf.org" , tcpm issue tracker Subject: Re: [tcpm] #19 (tcp-edo): Should there be a mechanism to detect that the segment modified? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 06:53:48 -0000 --Apple-Mail=_4B28981C-12FF-4D33-8349-EC0D1DDDAEE3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Am 16.10.2014 um 21:21 schrieb Joe Touch : > > > On 10/16/2014 12:04 PM, tcpm issue tracker wrote: >> #19: Should there be a mechanism to detect that the segment modified? >> >> I recall two ways that have been suggested for this: >> >> a) indicating payload size >> b) checksum >> >> An additional question to the above is, whether such mechanism should be >> part of EDO option, or a separate option in a separate document (in which >> case it might have also some use outside of EDO)? > > > As with both Issues #17 and #18, I think we can include something to > detect when this would corrupt a segment. IMO, we don't need anything as > computationally complex as a checksum, so I prefer something based on > length. > > Your original post included the following: > >> An additional question to the above is, whether such mechanism >> should be part of EDO option, or a separate option in a separate >> document (in which case it might have also some use outside of EDO)? > > If it's integrated we could save two bytes in the base header, but I > don't think that's necessary. > > I continue to believe that TCP is not itself a diagnostic. I don't like > the idea of building diagnostics into every capability we add; I prefer > an orthogonal approach. +1 > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_4B28981C-12FF-4D33-8349-EC0D1DDDAEE3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRAvPMACgkQdyiq39b9uS7HpQCg/cadbsbXptUzzuP1wMqG/SCK mV8AnRn7OG6G1LZY0DZ9kVkFRUuXlEJM =7M2g -----END PGP SIGNATURE----- --Apple-Mail=_4B28981C-12FF-4D33-8349-EC0D1DDDAEE3-- From nobody Fri Oct 17 08:03:20 2014 Return-Path: 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 0C40B1A8710 for ; Thu, 16 Oct 2014 11:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 eCGsw-Euk_0d for ; Thu, 16 Oct 2014 11:53:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0441A702B for ; Thu, 16 Oct 2014 11:53:56 -0700 (PDT) Received: from localhost ([::1]:39768 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XeqBK-00006I-VE; Thu, 16 Oct 2014 11:53:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "tcpm issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi X-Trac-Project: tcpm Date: Thu, 16 Oct 2014 18:53:50 -0000 X-URL: http://tools.ietf.org/tcpm/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/tcpm/trac/ticket/17 Message-ID: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi, tcpm@ietf.org X-SA-Exim-Mail-From: trac+tcpm@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: touch@isi.edu, wes@mti-systems.com Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/luowI318CpI4S8-w9swb6I3SvY8 X-Mailman-Approved-At: Fri, 17 Oct 2014 08:03:19 -0700 Cc: tcpm@ietf.org Subject: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:53:58 -0000 #17: Can the EDO extension be allowed in SYN/ACK? “Yes" would be nice, but an option-removing middlebox on return path would cause corruption of data -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-tcpm-tcp- pasi.sarolahti@iki.fi | edo@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: tcp-edo | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: tcpm From nobody Fri Oct 17 08:03:37 2014 Return-Path: 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 DD22D1A884C for ; Thu, 16 Oct 2014 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 BveJx1K9pIap for ; Thu, 16 Oct 2014 12:01:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AADF1A88A1 for ; Thu, 16 Oct 2014 12:01:26 -0700 (PDT) Received: from localhost ([::1]:40246 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XeqIZ-0002WE-Ua; Thu, 16 Oct 2014 12:01:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "tcpm issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi X-Trac-Project: tcpm Date: Thu, 16 Oct 2014 19:01:19 -0000 X-URL: http://tools.ietf.org/tcpm/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/tcpm/trac/ticket/18 Message-ID: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi, tcpm@ietf.org X-SA-Exim-Mail-From: trac+tcpm@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: touch@isi.edu, wes@mti-systems.com Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jTgtHheLI8EReUkFXXaJ-gwLQFk X-Mailman-Approved-At: Fri, 17 Oct 2014 08:03:34 -0700 Cc: tcpm@ietf.org Subject: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:01:40 -0000 #18: MUST the EDO option be included in all subsequent segments after being negotiated? If this is required, lack of EDO option would cause the segment to be dropped -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-tcpm-tcp- pasi.sarolahti@iki.fi | edo@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: tcp-edo | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: tcpm From nobody Fri Oct 17 08:04:35 2014 Return-Path: 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 1B2151A01D6 for ; Thu, 16 Oct 2014 12:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 36XfVB_3DzvT for ; Thu, 16 Oct 2014 12:04:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377871A8725 for ; Thu, 16 Oct 2014 12:04:27 -0700 (PDT) Received: from localhost ([::1]:40436 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XeqLU-0003ax-N6; Thu, 16 Oct 2014 12:04:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "tcpm issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi X-Trac-Project: tcpm Date: Thu, 16 Oct 2014 19:04:20 -0000 X-URL: http://tools.ietf.org/tcpm/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/tcpm/trac/ticket/19 Message-ID: <060.f99902df883b40f9ffc6e90ae7377494@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-tcpm-tcp-edo@tools.ietf.org, pasi.sarolahti@iki.fi, tcpm@ietf.org X-SA-Exim-Mail-From: trac+tcpm@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: touch@isi.edu, wes@mti-systems.com Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NN98yFDIYth84caz4dApvEkLqVY X-Mailman-Approved-At: Fri, 17 Oct 2014 08:04:33 -0700 Cc: tcpm@ietf.org Subject: [tcpm] #19 (tcp-edo): Should there be a mechanism to detect that the segment modified? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:04:29 -0000 #19: Should there be a mechanism to detect that the segment modified? I recall two ways that have been suggested for this: a) indicating payload size b) checksum An additional question to the above is, whether such mechanism should be part of EDO option, or a separate option in a separate document (in which case it might have also some use outside of EDO)? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-tcpm-tcp- pasi.sarolahti@iki.fi | edo@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: tcp-edo | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: tcpm From nobody Fri Oct 17 08:44:34 2014 Return-Path: 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 275161A1B70 for ; Fri, 17 Oct 2014 08:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 BTKbkHHgDcBz for ; Fri, 17 Oct 2014 08:44:30 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 698D61A1AB0 for ; Fri, 17 Oct 2014 08:44:30 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 710D3C94A8; Fri, 17 Oct 2014 11:44:20 -0400 (EDT) Date: Fri, 17 Oct 2014 11:44:20 -0400 From: John Leslie To: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-tcp-edo@tools.ietf.org Message-ID: <20141017154420.GE83009@verdi> References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uZSalDDt5btACJ0m_lubF7g8UtE Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:44:32 -0000 Pasi Sarolahti wrote: > On 16 Oct 2014, at 21:53, tcpm issue tracker wrote: > >> #17: Can the EDO extension be allowed in SYN/ACK? >> >> ?Yes" would be nice, but an option-removing middlebox on return path would >> cause corruption of data This is one of the things I intended for Data-Offset-zero to solve. But first, let's make sure we're talking about the same thing. I understand the issue to be that EDO in the initial SYN indicates that the originating endpoint speaks EDO; that EDO is received by the "server", which then sends a SYN-ACK with EDO including a length, but some middlebox strips out the EDO on the SYN-ACK without dropping the packet; thus the originating endpoint receives junk. I would stipulate that the middlebox in question is seriously broken. But I don't agree that such a mess is too unlikely to consider. With Data-Offset-zero, any packet (including a SYN-ACK) which uses the option-length field would also set Data-Offset to zero. Any endpoint which receives a Data-Offset of zero without an EDO option specifying the actual length knows it has received junk, and must discard the offending packet. It's likely, of course, that a middlebox would discard the packet before it ever reached the endpoint -- but if it reaches the endpoint, the endpoint immediately knows it's fighting middlebox damage, and can act accordingly (rather than waiting for a timeout). Thus, it's "safe" to use EDO length on the SYN-ACK: the damage will be detectable. Or are we talking some other scenario? -- John Leslie From nobody Fri Oct 17 08:51:20 2014 Return-Path: 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 1B8A51A1B8D for ; Fri, 17 Oct 2014 08:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Xl4Uk_7dV11e for ; Fri, 17 Oct 2014 08:51:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 672C81A1B86 for ; Fri, 17 Oct 2014 08:51:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2F10BC94C0; Fri, 17 Oct 2014 11:51:10 -0400 (EDT) Date: Fri, 17 Oct 2014 11:51:10 -0400 From: John Leslie To: Joe Touch Message-ID: <20141017155110.GF83009@verdi> References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> <54401AB2.5070200@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54401AB2.5070200@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ktm0QU8YMqj9hPwQXgVJsQv6Eb0 Cc: tcpm@ietf.org, draft-ietf-tcpm-tcp-edo@tools.ietf.org, tcpm issue tracker Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:51:19 -0000 Joe Touch wrote: > On 10/16/2014 12:01 PM, tcpm issue tracker wrote: >> #18: MUST the EDO option be included in all subsequent segments after being >> negotiated? >> >> If this is required, lack of EDO option would cause the segment to be >> dropped > > I think the same answer to #1 applies here. Likewise, I think my answer to #1 applies... > The only way this would be of concern is if such an "asymmetric > middlebox that also passes TCP" appeared on-path mid-connection... I'm not sure it has to be "asymmetric" if it appears mid-connection. And I really think it unwise to assume that no middlebox "appears" mid-connection. TCP is used for some very-long connections, during which routing may change and/or software updates may be applied. -- John Leslie From nobody Fri Oct 17 09:01:59 2014 Return-Path: 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 A02291A1B1A for ; Fri, 17 Oct 2014 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Qa4z7VySysQO for ; Fri, 17 Oct 2014 09:01:54 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18DB1A0047 for ; Fri, 17 Oct 2014 09:01:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 70F5C86BC50E; Fri, 17 Oct 2014 16:01:49 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9HG1kHU017502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 18:01:50 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 18:01:41 +0200 From: "Scharf, Michael (Michael)" To: "r.secchi@gmail.com" , Neal Cardwell , "Zimmermann, Alexander" , Yuchung Cheng , "tcpm@ietf.org" Thread-Topic: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt Thread-Index: AQHP6TvI/EvQEorzrUa5QOydknp8xZw0bTkQ Date: Fri, 17 Oct 2014 16:01:40 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1667D6DE@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/u5S3ps28DhVzYZZlVxHANYBRJS4 Subject: Re: [tcpm] New Version - draft-ietf-tcpm-newcwv-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:01:55 -0000 > So we've now had time to revisit the changes to Linux and the > differences between the ID and the Linux code. >=20 > A patch was submitted and followed the ID. This was available up to > Linux 3.15. >=20 > In Linux, there was an update submitted that conflicted with the > new-cwv patch, so new-cwv is not now supported - we think this is what > was recently discussed on the list. From what we understand, the > conflicting update centred around fixed needs to support TSO. This was > explained in the email from Yuchung on 22/09/2014 describes this work > from Neal Cardwell. >=20 > To us, it seems this does not implement a window validation procedure, > so this isn't the same as new-cwv. We'll highlight what we see are the > key differences below, and others may comment - especially if we get > this wrong. Thanks! This analysis is very useful. Here is a random thought: I wonder if one could describe new-cwv as a set o= f modular components/algorithms, instead of the current "all-in-one" algori= thm. Each of these components could perhaps be implemented in more than one= way, obviously resulting in different trade-offs. Actually, I doubt that there has every been an agreement among TCP stacks h= ow to exactly perform congestion window validation, and I don't know if eve= n inside TCPM we will ever have such a common understanding. Thus, as a remedy to the current situation, would it be possible to put bot= h new-cwv and the Linux approach (and possible other algorithms) under a co= mmon umbrella? Such a new-cwv I-D could first describe the basic functions = that have to be solved (i.e., a framework), plus some example algorithms (i= .e., the well-known variants we are aware of). Any thoughts? Michael (as individual contributor) From nobody Fri Oct 17 09:29:45 2014 Return-Path: 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 C07011A1BE0 for ; Fri, 17 Oct 2014 09:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 e5YxdByDJ7Qg for ; Fri, 17 Oct 2014 09:29:38 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A644A1A1BD2 for ; Fri, 17 Oct 2014 09:29:38 -0700 (PDT) Received: from [IPv6:::1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9HGTaNG019444; Fri, 17 Oct 2014 11:29:37 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Borman In-Reply-To: <544047E3.8080900@isi.edu> Date: Fri, 17 Oct 2014 11:29:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> References: <544047E3.8080900@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pv26ruHc0Nai8niMZ2ZkHpd2gn0 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:29:41 -0000 On Oct 16, 2014, at 5:34 PM, Joe Touch wrote: > On 10/14/2014 2:44 PM, David Borman wrote: >> I=92ve just posted draft-borman-tcp4way-00.txt >=20 > Some comments below. >=20 > Joe >=20 >> The TCP packet format has 54 bytes for adding TCP options >=20 > TCP currently has only 40 bytes of option space, not 54 ... Yep, pilot error, of course there are only 40 bytes for TCP options. >=20 >> If both sides send and receive a given option in a >> packet with the SYN bit set, then both sides know that the option is >> supported. >=20 > In current TCP, new options are indicated in the bare SYN and = confirmed > in the SYN-ACK. The above isn't explicit in how this exchange happens. To enable use of a TCP option, both sides have to agree to use it. The convention has been that this is done by sending and receiving the option during the 3-way handshake in packets with the SYN bit set. An optimization of that is that there is no point in putting the option into the SYN-ACK if it wasn=92t received in the SYN. But the underlying rule is that you have to both send and receive the option in a packet with the SYN bit set to enable the option, irrespective of the ACK bit. In the case of a simultaneous open, the presence of the option in both SYNs is sufficient to indicate support on both sides, even before the SYN-ACKs are exchanged. With the 4-way handshake and EDO, the client has a second chance to enable TCP options via its SYN-ACK, so there is then value in the first SYN-ACK from the server to include additional TCP options that were not included in the initial SYN from the client. >=20 > ----- >=20 > We've already discussed the latency impact for the initial > client->server request, i.e., one additional RTT. Actually, only 1/2 RTT overall, and for delivery of data to the application, either 0 or 1 RTT depending on which side of the connection you are on and whether or not you put data into the SYN or SYN/ACK packets. That=92s why I put all the examples in the document. >=20 > I'm not sure I agree with the claims here about option directionality; > it overlooks the fact that current TCP allows the client to decide = what > options to use on a given connection, subsetted by what the server See my comments above, these are all conventions with each individual TCP option defining how they are enabled an used. There is no reason that every TCP option has to continue to follow that model. Its biggest advantage is that packets with SYN are reliably transmitted at a fixed point in the sequence space, so you don=92t have to create a whole new option negotiation mechanism. And I=92ll argue that it=92s the intersection of the options offered by both the client and the server in their SYN packets; not including options in the SYN-ACK that weren=92t present in the SYN is just an optimization. > accepts. For that to happen here, you need a lot more text in how = option > processing is radically different during 4WHS: >=20 > - this still needs extended space in the server->client SYN, > and since you haven't tested EDO in both directions you can't > assume it will pass without silent asymmetric removal (see > below); if you don't have that space, you're back where you > started from because you'd need a 5WHS at least. >=20 > - the options offered by the server need to be ALL POSSIBLE > options the client may want to activate, which could be > large even without variation >=20 > - the client still needs to be able to be the one to decide > which options are used IMO, which means you still have a > problem with going to ESTABLISHED before you do a TWHS on > the options *actually used* >=20 > e.g., what if: >=20 > the client wants A, B, C >=20 > the server offers A,B,C,D,E,F,G > but can't do A,B,C together >=20 > the client picks A,B,C for the SYN/ACK > but the server would have to terminate > the connection and the client may have > accepted data on an invalid connection This is a rat-hole not worth going down. Don=92t forget about the existing simultaneous open case, which is not the 3way handshake. I know that it=92s a rare case, but it is still part of TCP and has to be considered. Each TCP option has to be defined for how it operates, including enablement, so talking about how fictional options might be ill-defined isn=92t very useful. > As noted in the discussion of EDO during SYN/ACK, *if* we believe = there > are middleboxes that might silently drop EDO asymmetrically BUT ALSO > allow TCP to pass asymmetrically, then we can't rely on EDO to extend > space in the SYN/ACK. That really feels like the tail wagging the dog. Unfortunately middle boxes are a reality, but we have to be reasonable about how far we are willing to go to accommodate their whims, and this asymmetrical argument is going too far in my mind. -David >=20 > ---- >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Oct 17 10:00:17 2014 Return-Path: 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 6E5FC1A1BF9 for ; Fri, 17 Oct 2014 10:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 ixDqswEAhTRL for ; Fri, 17 Oct 2014 10:00:12 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975761A1B68 for ; Fri, 17 Oct 2014 10:00:11 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 17 Oct 2014 19:00:00 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.45 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Message-ID: <54414B10.6010608@kau.se> Date: Fri, 17 Oct 2014 19:00:00 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20140704120244.14835.6363.idtracker@ietfa.amsl.com> <53B699B4.8000203@kau.se> <3678_1412785121_543563E1_3678_72_1_CAK6E8=d9JgqNkCoyrnMZ9W-V-hRWtE=YWqwsfzufq-JPAvShPA@mail.gmail.com> <87CDBDF6-27E4-44DE-BE12-CAA2F4CC84F9@iki.fi> <20141013084802.GA5944@kau.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hFHeLShaxkNy-a4ATFUVtpPtPpg Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rtorestart-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:00:14 -0000 On 2014-10-13 18:20, Yuchung Cheng wrote: > On Mon, Oct 13, 2014 at 1:48 AM, Per Hurtig wrote: >> On Thu, Oct 09, 2014 at 09:49:13PM +0300, Pasi Sarolahti wrote: >>> On 09 Oct 2014, at 20:32, Yuchung Cheng wrote: >>> >>>> On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti >>>> wrote: >>>>> Hi, >>>>> >>>>> Thanks, Yuchung, for bringing this up. It reminds me of an old note I >>>>> sent to the list quite a long while ago: I think it would be good if the >>>>> algorithm was designed so that it cannot (even in theory) result in negative >>>>> RTO values. The most straightforward way to fix this would be to include >>>>> some kind of max(RTO - T_earliest, some_threshold) guard in the algorithm. >>>>> It might not protect against spurious timeouts, but at least would keep the >>>>> values in sensible range. >>>> >>>> This would work but it might reduce the benefit (and adding yet >>>> another magic threshold). A negative value is a >>>> strong signal that the first unacked packet is lost. The problem in my >>>> case is the reaction is not appropriate (reset cwnd again) because we >>>> have just make some forward progress. >>> >>> Right, magic numbers are not nice (but it could be 0, just to prevent >>> negatives). Or then the draft should otherwise discuss handling of negative >>> values, and make it clear if there might be such. Some implementations might >>> define RTO as unsigned, in which case a negative value becomes very large >>> value… >>> >>> - Pasi >>> >> Hi all, >> >> I agree that we should formalize what to do if the timeout becomes >> negative due to RTOR. In our current implementation we don't invoke RTOR >> at all if the resulting value (RTO - T_earliest) is <= 0. That is, it >> has to be a positive number. >> >> I think this is a fair trade-off, and could be included in the coming >> internet-draft. Do you think it's too conservative? > It's not conservative. It's just awkward. > > If RTO - T_earliest is 1 ms, we retransmit almost right away. If it's > past due (<= 0), we wait another RTO. The fix would work, it just > sound like a hack. Sorry I try to be polite but I couldn't find a > better word... I agree it is not conservative, but I do not think it is so awkward. When you have a retransmission the ACK will arrive after RTO+RTT. And if you sent multiple packets to start with, then the calculated value of (RTO - T_earliest) will (most likely) be negative. This was the example that started this discussion and as pointed out, you do not want to use RTOR in this case as the segment will be immediately retransmitted anyway. Not invoking RTOR for negative values captures this case. From an algorithmic standpoint I cannot think of another scenario without retransmission where the value would be negative. (If we can come up with one, or one exists that we cannot think of, it may still be safe to not use RTOR.) If you tweak the send pattern in the example with the retransmission you can also get a small value. In theory this should not matter as the RTO will be reset anyway when the segment is retransmitted in response to the ACK. You can however also get small values during normal transmission, where you want to use RTOR, and this is the reason to use RTOR for positive values. So from an algorithmic standpoint I think not invoking RTOR when (RTO - T_earliest) is <= 0 captures the behavior we want. Maybe in practice there is some possibility to rearm and have the RTO fire before the retransmission in response to the ACK will happen though? If so, this retransmission would better be avoided. A perhaps better alternative could be to state that RTOR is not used for ACKs that acknowledge retransmitted (and previously unacknowledged) segments. That is what we want to avoid anyway. Cheers, Anna > >> >> Cheers, >> Per >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Oct 17 10:09:08 2014 Return-Path: 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 650351A1B68 for ; Fri, 17 Oct 2014 10:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qTpd2VHqEObQ for ; Fri, 17 Oct 2014 10:08:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321441A1AEA for ; Fri, 17 Oct 2014 10:08:47 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9HH6smH019349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 10:06:56 -0700 (PDT) Message-ID: <54414CAE.1060503@isi.edu> Date: Fri, 17 Oct 2014 10:06:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Leslie , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-tcp-edo@tools.ietf.org References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> <20141017154420.GE83009@verdi> In-Reply-To: <20141017154420.GE83009@verdi> Content-Type: text/plain; charset=windows-1252 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/8HS2tbJukF5iHe2ObHgqpscQvNo Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:09:02 -0000 On 10/17/2014 8:44 AM, John Leslie wrote: > Pasi Sarolahti wrote: >> On 16 Oct 2014, at 21:53, tcpm issue tracker wrote: >> >>> #17: Can the EDO extension be allowed in SYN/ACK? >>> >>> ?Yes" would be nice, but an option-removing middlebox on return path would >>> cause corruption of data > > This is one of the things I intended for Data-Offset-zero to solve. > > But first, let's make sure we're talking about the same thing. > > I understand the issue to be that EDO in the initial SYN indicates > that the originating endpoint speaks EDO; that EDO is received by the > "server", which then sends a SYN-ACK with EDO including a length, but > some middlebox strips out the EDO on the SYN-ACK without dropping the > packet; thus the originating endpoint receives junk. > > I would stipulate that the middlebox in question is seriously broken. > But I don't agree that such a mess is too unlikely to consider. TCP is not a diagnostic tool. (yes, I'm going to continue to repeat that). > With Data-Offset-zero, any packet (including a SYN-ACK) which uses > the option-length field would also set Data-Offset to zero. Any endpoint > which receives a Data-Offset of zero without an EDO option specifying > the actual length knows it has received junk, and must discard the > offending packet. So you're proposing a middlebox that DOES remove EDO but does not rewrite DO==0? Why would that ever happen? (SYN/ACK presumably should be excepted from splitting and joining, and even if it weren't what would it be joined with?) Maybe I should say that "TCP is not a diagnostic tool and middleboxes are not demonic". Joe From nobody Fri Oct 17 10:09:59 2014 Return-Path: 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 4F71B1A1B59 for ; Fri, 17 Oct 2014 10:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 lC2T2E1TNgLQ for ; Fri, 17 Oct 2014 10:09:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1722D1A1AEA for ; Fri, 17 Oct 2014 10:09:56 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9HH8Jkr019884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 10:08:20 -0700 (PDT) Message-ID: <54414D02.7010507@isi.edu> Date: Fri, 17 Oct 2014 10:08:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Leslie References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> <54401AB2.5070200@isi.edu> <20141017155110.GF83009@verdi> In-Reply-To: <20141017155110.GF83009@verdi> Content-Type: text/plain; charset=windows-1252 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/F_rJJlHz2xr6ld-z7_uLkwY8NEw Cc: tcpm@ietf.org, draft-ietf-tcpm-tcp-edo@tools.ietf.org, tcpm issue tracker Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:09:57 -0000 On 10/17/2014 8:51 AM, John Leslie wrote: > Joe Touch wrote: >> On 10/16/2014 12:01 PM, tcpm issue tracker wrote: >>> #18: MUST the EDO option be included in all subsequent segments after being >>> negotiated? >>> >>> If this is required, lack of EDO option would cause the segment to be >>> dropped >> >> I think the same answer to #1 applies here. > > Likewise, I think my answer to #1 applies... > >> The only way this would be of concern is if such an "asymmetric >> middlebox that also passes TCP" appeared on-path mid-connection... > > I'm not sure it has to be "asymmetric" if it appears mid-connection. > > And I really think it unwise to assume that no middlebox "appears" > mid-connection. TCP is used for some very-long connections, during > which routing may change and/or software updates may be applied. The typical such middlebox - a NAT - would break the connection if shifted without state being transferred. It'd be useful to describe why you think a stateless middlebox would be doing this sort of stuff, otherwise we're chasing phantoms... Joe From nobody Fri Oct 17 10:50:41 2014 Return-Path: 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 41CF81A00E8 for ; Fri, 17 Oct 2014 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 gRpaXJ9jhQFx for ; Fri, 17 Oct 2014 10:50:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CC71A00BF for ; Fri, 17 Oct 2014 10:50:38 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9HHnxek002629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 10:49:59 -0700 (PDT) Message-ID: <544156C7.5040906@isi.edu> Date: Fri, 17 Oct 2014 10:49:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> In-Reply-To: <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/ZjbLd_7bRPz7xnaa9t1fbapHxOs Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:50:40 -0000 On 10/17/2014 9:29 AM, David Borman wrote: > > On Oct 16, 2014, at 5:34 PM, Joe Touch wrote: > >> On 10/14/2014 2:44 PM, David Borman wrote: >>> I’ve just posted draft-borman-tcp4way-00.txt >> >> Some comments below. Cutting to the key issue, IMO. ... >> I'm not sure I agree with the claims here about option directionality; ... >> e.g., what if: >> >> the client wants A, B, C >> >> the server offers A,B,C,D,E,F,G >> but can't do A,B,C together >> >> the client picks A,B,C for the SYN/ACK >> but the server would have to terminate >> the connection and the client may have >> accepted data on an invalid connection > > This is a rat-hole not worth going down. >... so talking about how > fictional options might be ill-defined isn’t very useful. Here's a view from that fictional rat-hole: Client SYN indicates options that fill 40B... Server sends SYN with responses for those options, and uses the extension space to indicates other options it hasn't seen that it supports. In this case let's say it's: TCP-MD5 TCP-AO MPTCP At this point, you have a TCP that has offered three options that are NOT compatible with each other. TCP-AO is "MUST NOT" with TCP-MD5, and TCP-MD5 isn't compatible with MPTCP. So the client is now being offered a set of options that don't make sense. Note that although simultaneous opens may happen, there's no rule that requires the connection to unify the options offered in the two SYNs AFAICT. >> As noted in the discussion of EDO during SYN/ACK, *if* we believe there >> are middleboxes that might silently drop EDO asymmetrically BUT ALSO >> allow TCP to pass asymmetrically, then we can't rely on EDO to extend >> space in the SYN/ACK. > > That really feels like the tail wagging the dog. Unfortunately middle > boxes are a reality, but we have to be reasonable about how far we are > willing to go to accommodate their whims, and this asymmetrical argument > is going too far in my mind. I agree, but the SYN/ACK is the only segment with this issue *if* we require EDO in all segments once negotiated. Joe From nobody Fri Oct 17 14:29:53 2014 Return-Path: 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 873511A702A for ; Fri, 17 Oct 2014 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Z1SOX5Oc8hJ2 for ; Fri, 17 Oct 2014 14:29:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210801A6FE1 for ; Fri, 17 Oct 2014 14:29:50 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C93C7C1307ED6; Fri, 17 Oct 2014 21:29:43 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9HLTkOa027004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 23:29:47 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 23:29:46 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch , tcpm issue tracker , "draft-ietf-tcpm-tcp-edo@tools.ietf.org" , "pasi.sarolahti@iki.fi" Thread-Topic: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? Thread-Index: AQHP6XaVLM0Izt4CuEWw+xjfisth3Zw0zXjd Date: Fri, 17 Oct 2014 21:29:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1667D916@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org>, <54401AB2.5070200@isi.edu> In-Reply-To: <54401AB2.5070200@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.192.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/OtIoadjKVdcb6_8G0wa_e5Ae1lc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:29:51 -0000 I don't recall whether this has already been suggested in the earlier threa= ds:=0A= =0A= Given that the best answer to the question #18 seems to depend on the quest= ion whether certain (possibly hypothetical) middleboxes indeed exist or not= , one solution could be to mandate both modes in the EDO spec, right? For i= nstance, the connection originator would then (by some signal to be determi= ned) select which mode to use.=0A= =0A= Sure, that approach has downsides as well, but if we lack good data to make= an informed choice right now, we could let the market decide...=0A= =0A= Michael=0A= From nobody Fri Oct 17 14:33:07 2014 Return-Path: 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 8DFFB1A802A for ; Fri, 17 Oct 2014 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ZMSHYpFu3smX for ; Fri, 17 Oct 2014 14:33:05 -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 853A71A7113 for ; Fri, 17 Oct 2014 14:33:05 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9HLWmu3019433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 14:32:48 -0700 (PDT) Message-ID: <54418B00.4040400@isi.edu> Date: Fri, 17 Oct 2014 14:32:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , tcpm issue tracker , "draft-ietf-tcpm-tcp-edo@tools.ietf.org" , "pasi.sarolahti@iki.fi" References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org>, <54401AB2.5070200@isi.edu> <655C07320163294895BBADA28372AF5D1667D916@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1667D916@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 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/6btC8I7Rmyqq3KY5EvSApVbiyao Cc: "tcpm@ietf.org" Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 21:33:06 -0000 On 10/17/2014 2:29 PM, Scharf, Michael (Michael) wrote: > I don't recall whether this has already been suggested in the earlier > threads: > > Given that the best answer to the question #18 seems to depend on the > question whether certain (possibly hypothetical) middleboxes indeed > exist or not, one solution could be to mandate both modes in the EDO > spec, right? For instance, the connection originator would then (by > some signal to be determined) select which mode to use. > > Sure, that approach has downsides as well, but if we lack good data > to make an informed choice right now, we could let the market > decide... Sure; my preference would be to allow the two modes to be independent as separate options, e.g.: - EDO - a lightweight "TCP Integrity Option" that indicated the user data length for a given segment as transmitted That way, EDO could be coupled with TIO as needed, and TIO could be omitted where redundant (e.g., when using TCP-AO at least). Joe From nobody Fri Oct 17 15:17:25 2014 Return-Path: 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 6609D1A19F8 for ; Fri, 17 Oct 2014 15:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 pxzu4yg4rNYQ for ; Fri, 17 Oct 2014 15:17:15 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E391B1A19F1 for ; Fri, 17 Oct 2014 15:17:14 -0700 (PDT) Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9HMHD02024287; Fri, 17 Oct 2014 17:17:13 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <544156C7.5040906@isi.edu> Date: Fri, 17 Oct 2014 13:43:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7CkbmD5DatwrMKu3h7F2-3XODx8 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:17:16 -0000 > On Oct 17, 2014, at 12:49 PM, Joe Touch wrote: >=20 > On 10/17/2014 9:29 AM, David Borman wrote: >>=20 >> On Oct 16, 2014, at 5:34 PM, Joe Touch wrote: >>=20 >>> On 10/14/2014 2:44 PM, David Borman wrote: >>>> I=92ve just posted draft-borman-tcp4way-00.txt >>>=20 >>> Some comments below. >=20 > Cutting to the key issue, IMO. >=20 > ... >>> I'm not sure I agree with the claims here about option = directionality; > ... >>> e.g., what if: >>>=20 >>> the client wants A, B, C >>>=20 >>> the server offers A,B,C,D,E,F,G >>> but can't do A,B,C together >>>=20 >>> the client picks A,B,C for the SYN/ACK >>> but the server would have to terminate >>> the connection and the client may have >>> accepted data on an invalid connection >>=20 >> This is a rat-hole not worth going down. >> ... so talking about how >> fictional options might be ill-defined isn=92t very useful. >=20 > Here's a view from that fictional rat-hole: >=20 > Client SYN indicates options that fill 40B... >=20 > Server sends SYN with responses for those options, > and uses the extension space to indicates other > options it hasn't seen that it supports. > In this case let's say it's: > TCP-MD5 > TCP-AO > MPTCP >=20 > At this point, you have a TCP that has offered three options that are > NOT compatible with each other. TCP-AO is "MUST NOT" with TCP-MD5, and > TCP-MD5 isn't compatible with MPTCP. >=20 > So the client is now being offered a set of options that don't make = sense. It only doesn=92t make sense if you try to use them all at the same time, which would be silly. So I don=92t see what the problem is, the client only responds to one of those options, and ignores the others. All this really points out is that when there are incompatible options, there should be a documented procedure for how to handle the case when they are all negotiated. This case would be easy, if TCP-AO is = negotiated, then TCP-MD5 and MPTCP must be ignored. If TCPM-MD5 is negotiated, = MPTCP must be ignored. Then you are handling the simultaneous-open case today = where both sides indicate in their initial SYNs that they support all 3 = options. Not putting options into the SYN-ACK that weren=92t in the SYN should be viewed as no more than an optimization, and not a hard and fast rule, it should be harmless to put other options into the SYN-ACK, just not as efficient with the tight option space. -David From nobody Fri Oct 17 15:30:00 2014 Return-Path: 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 858451A1BBB for ; Fri, 17 Oct 2014 15:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 yREFJslzcAOF for ; Fri, 17 Oct 2014 15:29:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7541A1BAC for ; Fri, 17 Oct 2014 15:29:57 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9HMTd33020274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 15:29:39 -0700 (PDT) Message-ID: <54419853.7040705@isi.edu> Date: Fri, 17 Oct 2014 15:29:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> In-Reply-To: <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> Content-Type: text/plain; charset=windows-1252 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/xSXbcmo3C2NRuL_UZvAZq7ma_qI Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:29:58 -0000 On 10/17/2014 11:43 AM, David Borman wrote: > All this really points out is that when there are incompatible options, > there should be a documented procedure for how to handle the case when > they are all negotiated. Currently: SYN indicates desired options SYN/ACK indicates subset of desired options ACK indicates final set negotiated Right now, one side can easily avoid that by what it selects in its SYN. You're suggesting entirely different semantics for options that now need to be determined for all past and future options concurrently. I don't think that's feasible. Joe From nobody Fri Oct 17 15:49:00 2014 Return-Path: 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 74E761A7D84 for ; Fri, 17 Oct 2014 15:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 42S47_IgOrls for ; Fri, 17 Oct 2014 15:48:57 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9216F1A1BC8 for ; Fri, 17 Oct 2014 15:48:57 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 75D27C94BF; Fri, 17 Oct 2014 18:48:51 -0400 (EDT) Date: Fri, 17 Oct 2014 18:48:51 -0400 From: John Leslie To: Joe Touch Message-ID: <20141017224851.GG83009@verdi> References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> <20141017154420.GE83009@verdi> <54414CAE.1060503@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54414CAE.1060503@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QWb6amkWDRCXfEUGnqh_49nzsuo Cc: tcpm@ietf.org Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:48:59 -0000 Joe Touch wrote: > On 10/17/2014 8:44 AM, John Leslie wrote: > >> I understand the issue to be that EDO in the initial SYN indicates >> that the originating endpoint speaks EDO; that EDO is received by the >> "server", which then sends a SYN-ACK with EDO including a length, but >> some middlebox strips out the EDO on the SYN-ACK without dropping the >> packet; thus the originating endpoint receives junk. (I wonder whether Joe disagrees with that statement of the issue...) >> I would stipulate that the middlebox in question is seriously broken. >> But I don't agree that such a mess is too unlikely to consider. > > TCP is not a diagnostic tool. > (yes, I'm going to continue to repeat that). If Joe would stop saying this, I'd probably keep my mouth shut... But in fact, there is so much obfuscation getting in the way of our traditional diagnostic tools that we will sooner or later be forced to _use_ TCP as a diagnostic tool. :^( :^( :^( >> With Data-Offset-zero, any packet (including a SYN-ACK) which uses >> the option-length field would also set Data-Offset to zero. Any endpoint >> which receives a Data-Offset of zero without an EDO option specifying >> the actual length knows it has received junk, and must discard the >> offending packet. > > So you're proposing a middlebox that DOES remove EDO but does not > rewrite DO==0? I'm going to have to ask Joe to restate that question. I can make no sense of it as written. I believe folks have stipulated the existence of muddleboxes that remove individual options they "don't like". I am not an academic type; so I don't regularly scan the literature for papers documenting this, but a quick Google search reveals: http://dl.acm.org/citation.cfm?doid=2535828.2535830 (Can we please stop asking for citations for things which are blindingly obvious to people in Operations?) > Why would that ever happen? (SYN/ACK presumably should be excepted from > splitting and joining, and even if it weren't what would it be joined with?) Quoting from that paper: " Often, middleboxes remove a specific TCP option by replacing it " with the NOP TCP option to avoid having to update the segment length. And, on the question of SYN/ACK being excepted from splitting/joining, note the many attempts to pass user data in the first SYN. (No, I am not going to bother to google for that!) > Maybe I should say that "TCP is not a diagnostic tool and middleboxes > are not demonic". Maybe I should say, "We need diagnostic tools within TCP; and muddleboxes do not need to be demonic in order to screw things up." Or maybe we could find a way to discuss issues without resorting to exchanges like this? I find them very distasteful. -- John Leslie From nobody Fri Oct 17 15:56:46 2014 Return-Path: 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 176461A6FB2 for ; Fri, 17 Oct 2014 15:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7sKnN8m4GE-Q for ; Fri, 17 Oct 2014 15:56:42 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4141A1BC8 for ; Fri, 17 Oct 2014 15:56:42 -0700 (PDT) Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9HMufI0024773; Fri, 17 Oct 2014 17:56:41 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <54419853.7040705@isi.edu> Date: Fri, 17 Oct 2014 17:56:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rpq1PXVbB07ysi9uei4hwudyxu4 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:56:44 -0000 > On Oct 17, 2014, at 5:29 PM, Joe Touch wrote: >=20 >=20 >=20 > On 10/17/2014 11:43 AM, David Borman wrote: >> All this really points out is that when there are incompatible = options, >> there should be a documented procedure for how to handle the case = when >> they are all negotiated.=20 >=20 > Currently: > SYN indicates desired options > SYN/ACK indicates subset of desired options > ACK indicates final set negotiated >=20 > Right now, one side can easily avoid that by what it selects in its = SYN. > You're suggesting entirely different semantics for options that now = need > to be determined for all past and future options concurrently. >=20 > I don't think that's feasible. You keep missing the point. If an option isn=92t both sent and received in a packet with the SYN bit, it is not enabled. So with the 3WHS it doesn=92t matter if there are additional options in the SYN-ACK, they = will not be enabled because they weren=92t in the original SYN. The fact that the = SYN-ACK is a subset of what was in the SYN *is only an optimization*. The final = ACK has nothing to do with it, it=92s only what is exchanged in the packets = with the SYN bit that matter. Look at RFC1072, supported options were sent in any packet with the SYN bit set, so the SYN-ACK would have WS even if the inbound SYN didn=92t = have it. I=92m the one that pointed out because you had to both send and = receive the option to enable it, that sending the option in the SYN-ACK when it wasn=92t received in the SYN wasn=92t useful, and that=92s why RFC1323 = added that you only sent the options in the SYN-ACK if they were received in the SYN. But it was purely an optimization. With the 3WHS, all TCP implementations should ignore any options in the received SYN-ACK that they didn=92t send in the initial SYN. If they don=92t, they are = broken. With the 4WHS, the client has a second chance to enable additional = options with its SYN-ACK, provided they were received in the servers SYN-ACK. =09 -David >=20 > Joe >=20 >=20 From nobody Fri Oct 17 16:01:15 2014 Return-Path: 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 30CF21A8748 for ; Fri, 17 Oct 2014 16:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 HXVueorrzN_C for ; Fri, 17 Oct 2014 16:01:13 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C5A661A8742 for ; Fri, 17 Oct 2014 16:01:12 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 690DFC94BF; Fri, 17 Oct 2014 19:01:09 -0400 (EDT) Date: Fri, 17 Oct 2014 19:01:09 -0400 From: John Leslie To: Joe Touch Message-ID: <20141017230109.GH83009@verdi> References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> <54401AB2.5070200@isi.edu> <20141017155110.GF83009@verdi> <54414D02.7010507@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54414D02.7010507@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wth4t54xphNFoHwON9vE8s_1P2I Cc: tcpm@ietf.org Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:01:14 -0000 Joe Touch wrote: > On 10/17/2014 8:51 AM, John Leslie wrote: >> Joe Touch wrote: >> >>> The only way this would be of concern is if such an "asymmetric >>> middlebox that also passes TCP" appeared on-path mid-connection... >> >> I'm not sure it has to be "asymmetric" if it appears mid-connection. >> >> And I really think it unwise to assume that no middlebox "appears" >> mid-connection. TCP is used for some very-long connections, during >> which routing may change and/or software updates may be applied. > > The typical such middlebox - a NAT - would break the connection if > shifted without state being transferred. NATs aren't the only middleboxes out there. Nor is it safe to assume there will only be one middlebox on a path. Programming only for "typical" cases produces support nightmares. > It'd be useful to describe why you think a stateless middlebox would be > doing this sort of stuff, otherwise we're chasing phantoms... NAT is not the only "stateful" thing middleboxes do; and it's common advice to middlebox-writers to pass doubtful traffic when they reboot, hoping to recover state by context. I haven't put much thought into what a "stateless" middlebox might be doing -- my experience is with middleboxes which keep "state", but not NAT-like state which breaks as soon as you have to forward an "incoming" packet. I really must advise against defining "unlikely" middlebox behavior as out-of-scope for EDO. (Need I remind folks that NSA is known to be maintaining middleboxes?) -- John Leslie From nobody Fri Oct 17 16:25:21 2014 Return-Path: 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 4CE8C1A1A03 for ; Fri, 17 Oct 2014 16:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 lDumPi0IiuvM for ; Fri, 17 Oct 2014 16:25:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CCC1A1A02 for ; Fri, 17 Oct 2014 16:25:16 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9HNOdGu001807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 16:24:39 -0700 (PDT) Message-ID: <5441A537.6090903@isi.edu> Date: Fri, 17 Oct 2014 16:24:39 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Leslie References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org> <54401AB2.5070200@isi.edu> <20141017155110.GF83009@verdi> <54414D02.7010507@isi.edu> <20141017230109.GH83009@verdi> In-Reply-To: <20141017230109.GH83009@verdi> Content-Type: text/plain; charset=windows-1252 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/LbkzuyenoAPy7tKa_xTLHtcJWnw Cc: tcpm@ietf.org Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:25:18 -0000 On 10/17/2014 4:01 PM, John Leslie wrote: > Joe Touch wrote: >> On 10/17/2014 8:51 AM, John Leslie wrote: >>> Joe Touch wrote: >>> >>>> The only way this would be of concern is if such an "asymmetric >>>> middlebox that also passes TCP" appeared on-path mid-connection... >>> >>> I'm not sure it has to be "asymmetric" if it appears mid-connection. >>> >>> And I really think it unwise to assume that no middlebox "appears" >>> mid-connection. TCP is used for some very-long connections, during >>> which routing may change and/or software updates may be applied. >> >> The typical such middlebox - a NAT - would break the connection if >> shifted without state being transferred. > > NATs aren't the only middleboxes out there. > > Nor is it safe to assume there will only be one middlebox on a path. > > Programming only for "typical" cases produces support nightmares. Agreed. But I wonder how many boxes rewrite segments that are stateless. If that's either extremely rare or (more likely, IMO), a fantasy, we're doing a lot of work to address a use case that doesn't exist. >> It'd be useful to describe why you think a stateless middlebox would be >> doing this sort of stuff, otherwise we're chasing phantoms... > > NAT is not the only "stateful" thing middleboxes do; and it's > common advice to middlebox-writers to pass doubtful traffic when they > reboot, hoping to recover state by context. That's a good way to corrupt the very state you're trying to recover. Good to know that's "common advice". > I haven't put much thought into what a "stateless" middlebox might > be doing -- my experience is with middleboxes which keep "state", but > not NAT-like state which breaks as soon as you have to forward an > "incoming" packet. We need to know what they do, not what they might *ever* do. We can't chase ghosts (despite the upcoming holiday). > I really must advise against defining "unlikely" middlebox behavior > as out-of-scope for EDO. TCP is not a diagnostic tool. If a user is that concerned about these issues, IMO they ought to be using IPsec or TCP-AO. We should not design every feature into every option. Joe From nobody Fri Oct 17 16:30:05 2014 Return-Path: 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 779881A1A03 for ; Fri, 17 Oct 2014 16:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 V7YhTO4j8BQ2 for ; Fri, 17 Oct 2014 16:29:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C3F1A1A02 for ; Fri, 17 Oct 2014 16:29:56 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9HNTZvt002652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 16:29:35 -0700 (PDT) Message-ID: <5441A65F.3080508@isi.edu> Date: Fri, 17 Oct 2014 16:29:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> In-Reply-To: <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/xdLMk3Mfnh7ZyG46T6u6tjySQUE Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:29:58 -0000 On 10/17/2014 3:56 PM, David Borman wrote: > >> On Oct 17, 2014, at 5:29 PM, Joe Touch wrote: >> >> >> >> On 10/17/2014 11:43 AM, David Borman wrote: >>> All this really points out is that when there are incompatible options, >>> there should be a documented procedure for how to handle the case when >>> they are all negotiated. >> >> Currently: >> SYN indicates desired options >> SYN/ACK indicates subset of desired options >> ACK indicates final set negotiated >> >> Right now, one side can easily avoid that by what it selects in its SYN. >> You're suggesting entirely different semantics for options that now need >> to be determined for all past and future options concurrently. >> >> I don't think that's feasible. > > You keep missing the point. If an option isn’t both sent and received > in a packet with the SYN bit, it is not enabled. ... > With the 3WHS, all TCP > implementations should ignore any options in the received SYN-ACK that > they didn’t send in the initial SYN. If they don’t, they are broken. > > With the 4WHS, the client has a second chance to enable additional options > with its SYN-ACK, provided they were received in the servers SYN-ACK. So: - in 3WHS, the SYN-ACK cannot add new options - in 4WHS, the SYN-ACK can In 3WHS, the SYN is where all new options happen and are confirmed using a 3WHS. If 4WHS adds new options in the SYN-ACK, it needs another message to complete a 3WHS based on the options selected for a given connection. I.e., the client adds new options during SYN-ACK, the server confirms what it selects as a subset in the ACK to the client - but the client might still not like the subset picked. It needs a message to confirm that final choice. JOe From nobody Fri Oct 17 16:54:47 2014 Return-Path: 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 E20481A87BB for ; Fri, 17 Oct 2014 16:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 sEEtKUjDcUc1 for ; Fri, 17 Oct 2014 16:54:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BCC1A7016 for ; Fri, 17 Oct 2014 16:54:44 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9HNrEhB007047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Oct 2014 16:53:14 -0700 (PDT) Message-ID: <5441ABEA.7030301@isi.edu> Date: Fri, 17 Oct 2014 16:53:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Leslie References: <060.65d83fd5b18d3f526c150336ef6fff90@trac.tools.ietf.org> <20141017154420.GE83009@verdi> <54414CAE.1060503@isi.edu> <20141017224851.GG83009@verdi> In-Reply-To: <20141017224851.GG83009@verdi> Content-Type: text/plain; charset=windows-1252 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/mYx897seLFBGOBhctgrwwYWgk7w Cc: tcpm@ietf.org Subject: Re: [tcpm] #17 (tcp-edo): Can the EDO extension be allowed in SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 23:54:46 -0000 On 10/17/2014 3:48 PM, John Leslie wrote: > Joe Touch wrote: >> On 10/17/2014 8:44 AM, John Leslie wrote: >> >>> I understand the issue to be that EDO in the initial SYN indicates >>> that the originating endpoint speaks EDO; that EDO is received by the >>> "server", which then sends a SYN-ACK with EDO including a length, but >>> some middlebox strips out the EDO on the SYN-ACK without dropping the >>> packet; thus the originating endpoint receives junk. > > (I wonder whether Joe disagrees with that statement of the issue...) > >>> I would stipulate that the middlebox in question is seriously broken. >>> But I don't agree that such a mess is too unlikely to consider. >> >> TCP is not a diagnostic tool. >> (yes, I'm going to continue to repeat that). > > If Joe would stop saying this, I'd probably keep my mouth shut... > > But in fact, there is so much obfuscation getting in the way of our > traditional diagnostic tools that we will sooner or later be forced > to _use_ TCP as a diagnostic tool. We might, but if we do we'll need to design a true diagnostics option for that purpose. I don't intend to cloud the design of every new option with diagnostics in the meantime. >>> With Data-Offset-zero, any packet (including a SYN-ACK) which uses >>> the option-length field would also set Data-Offset to zero. Any endpoint >>> which receives a Data-Offset of zero without an EDO option specifying >>> the actual length knows it has received junk, and must discard the >>> offending packet. >> >> So you're proposing a middlebox that DOES remove EDO but does not >> rewrite DO==0? > > I'm going to have to ask Joe to restate that question. I can make no > sense of it as written. > > I believe folks have stipulated the existence of muddleboxes that > remove individual options they "don't like". If by "stipulated" you mean there's empirical evidence, yes. > I am not an academic type; > so I don't regularly scan the literature for papers documenting this, > but a quick Google search reveals: > > http://dl.acm.org/citation.cfm?doid=2535828.2535830 > > (Can we please stop asking for citations for things which are > blindingly obvious to people in Operations?) The reason we ask for citations is to understand whether we agree with your interpretation of the claims. In this case, the primary reference in [Hesmans13] for this evidence is [Honda11], which is the one I cited in the updated EDO draft already. >> Why would that ever happen? (SYN/ACK presumably should be excepted from >> splitting and joining, and even if it weren't what would it be joined with?) > > Quoting from that paper: > > " Often, middleboxes remove a specific TCP option by replacing it > " with the NOP TCP option to avoid having to update the segment length. That's a claim made in [Hesmans13] with no corroborating evidence. The claim follows a citation of [Honda11], which discussions option removal but never mentions the NOP option or keeping the option length constant. [Hesmans13] makes no claim to have done a study of this by examining the actual contents of packets. That's why citing the paper is important. > And, on the question of SYN/ACK being excepted from splitting/joining, > note the many attempts to pass user data in the first SYN. (No, I am > not going to bother to google for that!) Fair enough; I won't respond to unsubstantiated assertions either, though. I will note that [Hesmans13] doesn't talk about the SYN or SYN/ACK being split. [Honda11] notes that all splitting or coalescing involves options being rewritten from rather than transparently passed, so it wouldn't matter. Joe From nobody Fri Oct 17 19:23:26 2014 Return-Path: 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 7353D1A0092 for ; Fri, 17 Oct 2014 19:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Wk1NrW8wHyEd for ; Fri, 17 Oct 2014 19:23:21 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037191A008F for ; Fri, 17 Oct 2014 19:23:20 -0700 (PDT) Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9I2NJ1o029597; Fri, 17 Oct 2014 21:23:19 -0500 (CDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <5441A65F.3080508@isi.edu> Date: Fri, 17 Oct 2014 21:23:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Kep-tFQq1wz0ubJI17RDMgX2hMM Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 02:23:23 -0000 > On Oct 17, 2014, at 6:29 PM, Joe Touch wrote: >=20 >=20 >=20 > On 10/17/2014 3:56 PM, David Borman wrote: >>=20 >>> On Oct 17, 2014, at 5:29 PM, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 10/17/2014 11:43 AM, David Borman wrote: >>>> All this really points out is that when there are incompatible = options, >>>> there should be a documented procedure for how to handle the case = when >>>> they are all negotiated.=20 >>>=20 >>> Currently: >>> SYN indicates desired options >>> SYN/ACK indicates subset of desired options >>> ACK indicates final set negotiated >>>=20 >>> Right now, one side can easily avoid that by what it selects in its = SYN. >>> You're suggesting entirely different semantics for options that now = need >>> to be determined for all past and future options concurrently. >>>=20 >>> I don't think that's feasible. >>=20 >> You keep missing the point. If an option isn=92t both sent and = received >> in a packet with the SYN bit, it is not enabled.=20 > ... >> With the 3WHS, all TCP >> implementations should ignore any options in the received SYN-ACK = that >> they didn=92t send in the initial SYN. If they don=92t, they are = broken. >>=20 >> With the 4WHS, the client has a second chance to enable additional = options >> with its SYN-ACK, provided they were received in the servers SYN-ACK. >=20 > So: >=20 > - in 3WHS, the SYN-ACK cannot add new options The SYN-ACK can contain new options, they just won=92t get enabled, since they weren=92t received in the SYN. It is an optimization to exclude from the SYN-ACK options that can=92t be enabled. > - in 4WHS, the SYN-ACK can >=20 > In 3WHS, the SYN is where all new options happen and are confirmed = using > a 3WHS. Again, both sides propose what options they can support, and they enable the intersection of what they sent in their SYN, and received in the other sides SYN or SYN-ACK. It is only an optimization that the SYN-ACK doesn=92t need to include options that it already knows will never be = enabled for this connection, since they weren=92t received in the SYN. Both sides only enable the intersection of options that were both sent and received in a packet with the SYN bit set. Let me make it clearer with the simultaneous open: In that case, both sides send a SYN packet with some set of options. When they each = receive each others SYN, they both now have the intersection of options both = sent and received in a packet with a SYN, and know what options are enabled. What=92s in the SYN-ACK that they then send is superfluous, both sides have already determined what options are supported for this connection. =20 > If 4WHS adds new options in the SYN-ACK, it needs another message to > complete a 3WHS based on the options selected for a given connection. >=20 > I.e., the client adds new options during SYN-ACK, the server confirms > what it selects as a subset in the ACK to the client - but the client > might still not like the subset picked. It needs a message to confirm > that final choice. The final ACK doesn=92t have any part of the option negotiation, in = either the 3way or 4way handshake. Again, any option that is both sent and received in a packet with the SYN bit set enables the option. With the 4way handshake the client sends two packets with the SYN bit, so if the server has included additional options in its SYN-ACK that weren=92t received in the SYN, then the client can enable those options by including them in its SYN-ACK. That is the whole point of the 4way handshake, that with the EDO option it allows more options to be enabled than will fit in the initial SYN which has limited option space. -David > JOe >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Oct 19 15:43:43 2014 Return-Path: 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 387731A066C for ; Sun, 19 Oct 2014 15:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nj9rrmNjpglf for ; Sun, 19 Oct 2014 15:43:39 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6081E1A0366 for ; Sun, 19 Oct 2014 15:43:38 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 19 Oct 2014 23:44:31 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 19 Oct 2014 23:43:36 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Sun, 19 Oct 2014 23:43:35 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.134.250]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9JMhVM1013816; Sun, 19 Oct 2014 23:43:32 +0100 Message-ID: <201410192243.s9JMhVM1013816@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 19 Oct 2014 23:43:00 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <5433FFB0.5090205@isi.edu> References: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> <20141006013104.GC72713@verdi> <5432CC74.6020107@isi.edu> <201410071037.s97AbXHR006583@bagheera.jungle.bt.co.uk> <5433FFB0.5090205@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/2r_t3acmZ5V4jATl2Ha4kBZWbvA Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 22:43:42 -0000 Joe, At 15:58 07/10/2014, Joe Touch wrote: >On 10/7/2014 3:37 AM, Bob Briscoe wrote: > > Joe, > > > > At 18:08 06/10/2014, Joe Touch wrote: > >> > I prefer getting an Experimental document out fairly quickly for > >> EDO. > >> > >> The track has nothing to do with the speed of WG handling. There are no > >> experiments we're waiting for in the case of EDO - it's the OOB case > >> that definitely needs experiments, and probably also the SYNOPSIS case > >> too. > > > > I hope the examples I gave at the start of this thread show that EDO is > > not immune to middlebox problems, and therefore should be conditional on > > middlebox traversal experiments (as should OOB and SYNOPSIS). > >IMO, these experiments should be conditional on some evidence they're a >real concern, i.e.: > > - deployed in public networks in more than rare exceptions > > - a device the WG agrees that protocols should traverse > (vs. a device considered incorrectly implemented that should > be fixed or replaced) > >It's easy to posit device properties that can interfere with a proposal, >but I don't agree that we need to deal with every possible byzantine case. > >Hesmans,et al., "Are TCP Extensions Middlebox-proof?", Conext 2013 >explores how options react to middlebox behaviors that include splitting >and coalescing, but the only middlebox behavior seen is a failure of ALG >translation of active FTP through NATs. Splitting and coalescing are >described, but (unlike other behaviors) their description has no citations. > >The citations in that paper go back to this: >Honda, et al., "Is it still possible to extend TCP?", IMC 2011. >"Although middleboxes do split and coalesce segments, *NONE* [emphasis >mine] did so while passing unknown options...". A) If we were to write guidelines on middlebox design, I suspect we would say that a middlebox SHOULD/MUST forward unknown options. B) It is fairly obvious that two TCP stacks either side of a proxy will sometimes split or coalesce segments: * If the origin is app-limited so that small segments arrive into a buffer at the proxy, then the proxy is likely to coalesce them into a larger segment when it sends them out. * If a sequence of coalesced segments overflows the MTU, the proxy will then split the last segment and start the next segment with the remainder. So what would you advise this proxy to do? Not resegment? That's not easy to implement, because the outgoing side has to somehow remember where the segment boundaries were when they arrived. 'Ideally' the proxy shouldn't intervene uninvited. Then the sender is talking to the proxy as a proper endpoint, and the proxy is similarly talking to the receiver. However: * that requires extra complexity configuring the sender with the address of the appropriate proxy, which changes if the sender is mobile, or changes to connect via a VPN, etc etc. * that still greatly slows the deployment of new options. If 10% of endpoints and 10% of proxies have deployed a new option, the chance of finding a fully deployed path is 10%*10% = 1%. ...this isn't as easy as just banging a fist on the table and shouting "No!" I prefer to make TCP options robust to resegmentation and robust to option stripping. This would constructively simplify the whole system. >Can we please stop chasing phantoms? I'm fine with this. I am trying to find out what is out there myself (Michio's paper was an output of one of our projects), and go deeper by understanding why middleboxes are like they are. Anyway, I don't think I ever said that we need to cater for middleboxes that resegment AND forward unknown options. So I think you might be arguing against an invented adversary (chasing phantoms?). Perhaps we have different goals. You are saying all we have to do is take account of what is out there. I believe we have to do that and more. We have to propose rules that middleboxes can follow, and there must be no reason why they wouldn't follow the rules. That means the rules have to work in their interest, and allow them to be lazy. It is certainly not realistic to expect these vendors to follow rules that entirely rule out their business model, no matter how much I don't like their architecture. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Sun Oct 19 17:41:08 2014 Return-Path: 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 4C4431A1A64 for ; Sun, 19 Oct 2014 17:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 W_3CxcmjlEWj for ; Sun, 19 Oct 2014 17:41:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830261A1A0D for ; Sun, 19 Oct 2014 17:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2550; q=dns/txt; s=iport; t=1413765665; x=1414975265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BLV4BVls2SJcjmQDfhas6pjXjTEbgOVleMIsI5MXG+s=; b=dglSq90dMde+nG2UHasihMV9g8jD+QnjslACopmFpUgB1InN0Onmudb9 ZPCsi1ZbwouPoIJQJCf2kcmsH9eM69V5Bqw0rIy1XjWErASsNxzr7a9K8 Qc3eWjEY1HhCJVgx321gjJ4NbkEAUqGuOIUDukkbILxhgtC3CfbntRJLN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAL5YRFStJV2Y/2dsb2JhbABbgmsjU1gEgwLJEYdOAhtzFgFyC4QCAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQOBQgBiDYBDKtdlBoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSyOdDEHBoJxNoEeBY9kghyERohDPIMKkSyDd2wBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,749,1406592000"; d="scan'208";a="88459989" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 20 Oct 2014 00:41:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9K0f4Pq005403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 00:41:04 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 19:41:04 -0500 From: "Jakob Heitz (jheitz)" To: "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-heitzhe-tcpm-vm-rto-00.txt Thread-Index: AQHP6/e/GE8jE6PowUuTOG76K4IJ05w4Imxw Date: Mon, 20 Oct 2014 00:41:04 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE50D93B959@xmb-aln-x02.cisco.com> References: <20141019235228.23107.88305.idtracker@ietfa.amsl.com> In-Reply-To: <20141019235228.23107.88305.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NS2JY-DVjJWRI0vEKkAvsFfzPQ4 Cc: Chuan He Subject: [tcpm] FW: New Version Notification for draft-heitzhe-tcpm-vm-rto-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 00:41:07 -0000 SGkgVENQTSwNCg0KV2Ugd2VyZSBleHBlcmltZW50aW5nIHdpdGggVENQIGNvZGUgaW4gYSBWTSBz ZXR0aW5nLg0KV2UgcmVkdWNlZCB0aGUgbWluaW11bSBSVE8sIGJlY2F1c2UgYXZlcmFnZSBSVFQg c2hvdWxkIGJlIG11Y2ggbG93ZXIgdGhhbiAxIHNlY29uZC4NCldlIGdvdCBsb3RzIG9mIHNwdXJp b3VzIHJldHJhbnNtaXNzaW9ucyBpbiBhIGhlYXZpbHkgbG9hZGVkIGhvc3QuDQpBcyBhIHJlc3Vs dCwgd2UgZGV2ZWxvcGVkIGFuIGFsdGVybmF0aXZlIHRvIHRoZSBleHBvbmVudGlhbCB3ZWlnaHRl ZCBtb3ZpbmcgYXZlcmFnZQ0KYWxnb3JpdGhtIHRvIGRldGVybWluZSB0aGUgUlRPLiBJdCBvcGVy YXRlcyB3ZWxsIHdpdGhvdXQgYW55IG1pbmltdW0gUlRPIHNldHRpbmcuDQoNClBsZWFzZSB0YWtl IGEgbG9vayBhbmQgY29tbWVudC4NCg0KLS1KYWtvYg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDE5LCAyMDE0IDQ6NTIgUE0N ClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KTsgQ2h1YW4gSGU7IENodWFuIEhlOyBKYWtvYiBIZWl0 eiAoamhlaXR6KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o ZWl0emhlLXRjcG0tdm0tcnRvLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1oZWl0emhlLXRjcG0tdm0tcnRvLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEpha29iIEhlaXR6IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZToJCWRyYWZ0LWhlaXR6aGUtdGNwbS12bS1ydG8NClJldmlzaW9uOgkwMA0KVGl0bGU6CQlU Q1AgUmV0cmFuc21pc3Npb24gVGltZXIgZm9yIFZpcnR1YWwgTWFjaGluZXMNCkRvY3VtZW50IGRh dGU6CTIwMTQtMTAtMTkNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTUN ClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1oZWl0emhlLXRjcG0tdm0tcnRvLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhlaXR6aGUtdGNwbS12bS1ydG8vDQpIdG1saXpl ZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVpdHpoZS10Y3BtLXZt LXJ0by0wMA0KDQoNCkFic3RyYWN0Og0KICAgQSBSb3VuZCBUcmlwIFRpbWUgKFJUVCkgZXN0aW1h dGUgdGhhdCBkZWNheXMgcGVyZm9ybXMgYmFkbHkgaW4gYQ0KICAgYnVyc3R5IGVudmlyb25tZW50 LiBBIHJvdW5kIHRyaXAgdGltZSBlc3RpbWF0b3IgdGhhdCBkb2VzIG5vdCBkZWNheQ0KICAgZm9y IGEgcGVyaW9kIG9mIHRpbWUgaXMgcHJvcG9zZWQuDQoNCiAgIEl0IGRvZXMgbm90IHJlcXVpcmUg YSBtaW5pbXVtIHZhbHVlIHRvIGJlIGNvbmZpZ3VyZWQuIEl0IHdvcmtzDQogICBlcXVhbGx5IHdl bGwgd2hlbiB0aGUgdHlwaWNhbCBSVFQgaXMgMTAwdVMgYXMgd2hlbiBpdCBpcyAxMCBzZWNvbmRz Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sun Oct 19 17:58:39 2014 Return-Path: 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 3B36F1A1A6D for ; Sun, 19 Oct 2014 17:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9QKcRvIstE6w for ; Sun, 19 Oct 2014 17:58:35 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2D71A00CD for ; Sun, 19 Oct 2014 17:58:33 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 20 Oct 2014 01:59:26 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 20 Oct 2014 01:59:29 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 20 Oct 2014 01:58:30 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.250]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9K0wQnS014207; Mon, 20 Oct 2014 01:58:27 +0100 Message-ID: <201410200058.s9K0wQnS014207@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Oct 2014 01:58:26 +0100 To: SCHARF Michael , "SAROLAHTI, Pasi" , Yoshifumi Nishida From: Bob Briscoe MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2116089960==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/DEhLlWFWNjz1a1z3DvpCQwxofFU Cc: tcpm IETF list Subject: [tcpm] More option space on any segment: draft-briscoe-tcpm-inner-space-00 (was syn-op-sis-02) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 00:58:38 -0000 --=====================_2116089960==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Chairs and list, My individual draft has a new file-name (and title): inner-space-00 This is a major rev of syn-op-sis-02, but I won't be using that name any more. Sorry to confuse everyone by changing the name. But the old name was no longer relevant. I believe the new Inner Space protocol could be a significant advance for TCP. It should allow new TCP options to be introduced: i) with minimal middlebox traversal problems; ii) avoiding incremental deployment problems with pre-existing servers; iii) without a round of handshaking delay iv) without having to provide their own loss recovery and ordering mechanism v) without arbitrary limits on available space. I believe this could be a significant simplifying foundation over which tcpinc (TCP increased security) could be built. So I want to encourage folks on the list to read and criticise it with some urgency, because tcpinc is working to a fairly tight schedule. I've been working on this fairly intensely in my 'spare' time over the last few weeks, working through all the possible interactions with middleboxes and other options, then simplifying and iterating through the checks again. I'm v happy with how it's turned out now. It's intended for experimental status. Listening to the advice on the list, I've chosen a basic 'mandatory to implement' core, and included optional extensions in appendices. I've also written-up an extensive Design Rationale section, because there's a lot of subtlety in it, even tho the core protocol looks v simple. The appendices and the rationale make the doc v long (48pp). Sorry about that! But the core spec is actually still only 13pp. Cheers Bob >From: >To: Bob Briscoe , "Bob J. Briscoe" >Subject: New Version Notification for draft-briscoe-tcpm-inner-space-00.txt >Date: Sun, 19 Oct 2014 16:59:03 -0700 > > >A new version of I-D, draft-briscoe-tcpm-inner-space-00.txt >has been successfully submitted by Bob Briscoe and posted to the >IETF repository. > >Name: draft-briscoe-tcpm-inner-space >Revision: 00 >Title: Inner Space for TCP Options >Document date: 2014-10-19 >Group: Individual Submission >Pages: 45 >URL: >http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-inner-space-00.txt >Status: >https://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/ >Htmlized: http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-00 > > >Abstract: > This document describes an experimental method to extend the limited > space for control options in every segment of a TCP connection. It > can use a dual handshake so that, from the very first SYN segment, > extra option space can immediately start to be used optimistically. > At the same time the dual handshake prevents a legacy server from > getting confused and sending the control options to the application > as user-data. The dual handshake is only one strategy - a single > handshake will usually suffice once deployment has got started. The > protocol is designed to traverse most known middleboxes including > connection splitters, because it sits wholly within the TCP Data. It > also provides reliable ordered delivery for control options. > Therefore, it should allow new TCP options to be introduced i) with > minimal middlebox traversal problems; ii) avoiding incremental > deployment problems with pre-existing servers; iii) without an extra > round of handshaking delay iv) without having to provide its own loss > recovery and ordering mechanism and v) without arbitrary limits on > available space. > > > > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT --=====================_2116089960==.ALT Content-Type: text/html; charset="us-ascii" Chairs and list,

My individual draft has a new file-name (and title): inner-space-00
This is a major rev of syn-op-sis-02, but I won't be using that name any more.
Sorry to confuse everyone by changing the name. But the old name was no longer relevant.

I believe the new Inner Space protocol could be a significant advance for TCP.

It should allow new TCP options to be introduced:
i) with minimal middlebox traversal problems;
ii) avoiding incremental deployment problems with pre-existing servers;
iii) without a round of handshaking delay
iv) without having to provide their own loss recovery and ordering mechanism
v) without arbitrary limits on available space.

I believe this could be a significant simplifying foundation over which tcpinc (TCP increased security) could be built. So I want to encourage folks on the list to read and criticise it with some urgency, because tcpinc is working to a fairly tight schedule.


I've been working on this fairly intensely in my 'spare' time over the last few weeks, working through all the possible interactions with middleboxes and other options, then simplifying and iterating through the checks again. I'm v happy with how it's turned out now.

It's intended for experimental status. Listening to the advice on the list, I've chosen a basic 'mandatory to implement' core, and included optional extensions in appendices.

I've also written-up an extensive Design Rationale section, because there's a lot of subtlety in it, even tho the core protocol looks v simple.

The appendices and the rationale make the doc v long (48pp). Sorry about that! But the core spec is actually still only 13pp.

Cheers



Bob

From: <internet-drafts@ietf.org>
To: Bob Briscoe <bob.briscoe@bt.com>, "Bob J. Briscoe" <bob.briscoe@bt.com>
Subject: New Version Notification for draft-briscoe-tcpm-inner-space-00.txt
Date: Sun, 19 Oct 2014 16:59:03 -0700


A new version of I-D, draft-briscoe-tcpm-inner-space-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:             draft-briscoe-tcpm-inner-space
Revision:       00
Title:           Inner Space for TCP Options
Document date:  2014-10-19
Group:           Individual Submission
Pages:           45
URL:            http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-inner-space-00.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/
Htmlized:       http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-00


Abstract:
   This document describes an experimental method to extend the limited
   space for control options in every segment of a TCP connection.  It
   can use a dual handshake so that, from the very first SYN segment,
   extra option space can immediately start to be used optimistically.
   At the same time the dual handshake prevents a legacy server from
   getting confused and sending the control options to the application
   as user-data.  The dual handshake is only one strategy - a single
   handshake will usually suffice once deployment has got started.  The
   protocol is designed to traverse most known middleboxes including
   connection splitters, because it sits wholly within the TCP Data.  It
   also provides reliable ordered delivery for control options.
   Therefore, it should allow new TCP options to be introduced i) with
   minimal middlebox traversal problems; ii) avoiding incremental
   deployment problems with pre-existing servers; iii) without an extra
   round of handshaking delay iv) without having to provide its own loss
   recovery and ordering mechanism and v) without arbitrary limits on
   available space.

                                                                                 


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_2116089960==.ALT-- From nobody Sun Oct 19 18:15:35 2014 Return-Path: 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 5D0CB1A1A79 for ; Sun, 19 Oct 2014 18:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lAxriJbn7mRi for ; Sun, 19 Oct 2014 18:15:25 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814A41A1A74 for ; Sun, 19 Oct 2014 18:15:23 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 20 Oct 2014 02:15:22 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 20 Oct 2014 02:15:21 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 20 Oct 2014 02:15:21 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.109.250]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9K1FIMH014340; Mon, 20 Oct 2014 02:15:19 +0100 Message-ID: <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Oct 2014 02:15:16 +0100 To: Joe Touch From: Bob Briscoe In-Reply-To: <543DA031.6090705@isi.edu> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> <543DA031.6090705@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5A2qAHQT20NbZdpYk7PKMgZHWGA Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 01:15:30 -0000 Joe, At 23:14 14/10/2014, Joe Touch wrote: >On 10/14/2014 2:36 PM, Bob Briscoe wrote: > > Joe, > > > > At 19:41 14/10/2014, Joe Touch wrote: > > > > > >> On 10/14/2014 11:25 AM, Bob Briscoe wrote: > >> > MIrja, Joe, > >> ... > >> >> > 2) What's about putting the EDO length option as the first (or last) > >> >> > option in the payload more or less as proposed in Bob's approach > >> (if we > >> >> > require it to be present in each segment anyway as discussed in the > >> >> > previous mail thread). This way it could not be removed by a > >> >> middlebox... > >> >> > >> >> All options are in the "payload" area, i.e., in the area after the > >> base > >> >> TCP header. The header is what indicates what portion of that > >> payload is > >> >> an extension to that base header. > >> > > >> > I think Mirja is suggesting that a TCP Option before the Data Offset > >> > ('outer') that points to extended option space beyond the Data Offset > >> > ('inner') is fragile. If the outer option is stripped, then the inner > >> > options turn into potentially corrupt user-data. I.e. the outer and > >> > inner do not share the same fate. > >> > >> I don't understand this. > >> > >> DO extends the TCP header into the front of the payload. > >> > >> Any TCP option that extends that space in any way needs to be in that > >> area. > >> > >> DO can't be stripped. The options it makes space for can. Regardless of > >> how a TCP option extends the DO space, if that happens mid-connection > >> (again, a hypothetical only), the extension space will be interpreted as > >> user data. It doesn't matter whether the additional space is at the > >> front or end of the post-DO payload. > > > > I am not saying DO might be stripped. > > > > Syn-op-sis does not involve any additional TCP options in the TCP option > > space, ie the space between the end of the 20B base TCP header and the > > max 60B Data Offset. This makes each syn-op-sis segment /inherently/ > > robust against option stripping. > >Oh, right - you've encoded the option opaquely in the data. > >That's not a TCP option anymore. TCP options are fields defined by the >option structure defined in RFC793. You're defining a new way to signal >the presence of options using a magic number. > >That's a lot of obfuscation in the absence of re-encoding the user data >to avoid collision AND in the absence of a checksum. > > > All the additional options of syn-op-sis are beyond the Data Offset, > > including the option that creates the additional space for the other > > options. So they all share the same fate. > >Agreed. > > > Whereas, in EDO the option that creates the space beyond DO is not > > itself beyond DO. > >Right, because it's a TCP option. > > > So the option that creates the space is at risk of > > being stripped without stripping the space it created. The two do not > > /inherently/ share the same fate. > >Correct. > > > Yes, checks can be added to EDO to check for option stripping (e.g. > > deferring use of extra space until after the SYN/ACK). But this has to > > assume that stripping behaviour remains consistent through the flow. > >Yes. Again, TCP is not a diagnostic tool. > > > Whereas, with syn-op-sis, each individual segment is robust against > > option stripping, all by itself. > > > > I think this is what Mirja was referring to. > > > > > >> > In the syn-op-sis approach, the extra space and the option that creates > >> > the extra space are both beyond the Data Offset (both inner). So they > >> > share fate. > >> > >> Even if that were true, it would mean that user data would be corrupted > >> by both the option and the extension. > > > > * The syn-op-sis client ensures that it aborts the connection to a > > legacy server before it passes this corrupt TCP Data to the app. > >You have to prohibit use of TFO (and maybe some others, e.g., TCPCT) >with syn-op-sys in that case. Nope (we've been through that argument, and I recall you suddenly 'got it' at one point). > > * And a syn-op-sis server catches this corrupt TCP data and removes the > > options before passing the remaining payload to the app. > > > > This only relies on the endpoints, which are stateful, to maintain > > consistent behaviour throughout the connection. Half-way through a > > connection, a server isn't suddenly going to forget that it supports > > syn-op-sis and start passing corrupt data to the app. > > > > Whereas it is not so certain that the experienced middlebox behaviour > > will remain consistent throughout a connection. It might not be the same > > middlebox in both directions, and the path might change to pass through > > a different middlebox part-way through a connection. > >We have no evidence of middleboxes that suddenly appear on a path >asymmetrically AND allow a connection to continue. > >However, if we did, we'd also have to consider devices that split >segments without understanding options but which don't copy options (one >of the cases described in the study). > >That breaks syn-op-sis in two ways: > > - user data is corrupted with the extended options > - user data is interpreted as extended options incorrectly I have developed syn-op-sis. The sender includes options within the reliable ordered data stream prefixed by a framing option at the original segment boundaries. Then the receiver can reconstruct the original segment boundaries, and extract the options that applied at that boundary. It has a number of nice properties, not least reliable ordered delivery of options even in the fairly common case when there is no user-data in one direction. The majority of known options can shift into the TCP datastream: MSS, SACK-ok, WS, MPTCP, TFO, AO, tcpcrypt. Certain options (specifically timestamp and SACK) are inherently about transmission of individual segments so they have to remain in the main TCP header. These (and any new options with similar properties) would still not traverse middleboxes that both resegment and do not forward unrecognised options. However, new options like those in the longer list above would traverse middleboxes, even if they resegment and even if they don't forward unrecognised options. At risk of confusing everyone, I have renamed the file and the scheme from syn-op-sis to inner-space. I have just posted draft-briscoe-tcpm-inner-space-00 >Note that a middlebox that splits segments but uses the options only on >the first segment is likely to pass EDO uncorrupted and unaffected >(presuming the extension is within the first segment). Yup. > >> ... > >> >> > One quick question for Bob: Is there a specific reason that > >> you've put > >> >> > the syn-op-sis option at the end (and not at the beginning) of the > >> >> payload? > >> >> > >> >> I'll let Bob answer that in detail if desired; AFAICT, it's largely to > >> >> allow middleboxes that don't understand the extension to be able to > >> >> parse and process the data field. I think this is a mistake, > >> because at > >> >> some point in that field the data is corrupted, and it is just > >> making a > >> >> bet that such boxes should be supported until they silently fail. I'd > >> >> prefer they just fail from the start. > >> > > >> > I suspect that what Joe says might happen with some middleboxes, ie. > >> the > >> > start of the payload looks like they would expect, but they suddently > >> > find some unexpected bytes so they drop the packet. > >> > > >> > However, I'd like to experiment, because I suspect many of these > >> > app-layer boxes will parse up to whatever point they need to, then > >> stop. > >> > So they won't ever notice the unexpected bytes at the end. For > >> instance, > >> > my employer's Web filter (that I'm sitting behind right now) looks for > >> > the URL that is the argument to the HTTP GET command in order to decide > >> > whether to block the page. It doesn't parse all the HTML, and it may > >> not > >> > even parse all the HTTP after the GET. These filters are widely used to > >> > protect children from porn etc, and they are widely used for less noble > >> > (usually commercial) purposes. > >> > >> Sure, and they might even parse HTTPS to the point of finding the SNI. > >> > >> > On 7 out of the 142 paths tested in Michio Honda et al "Is it Still > >> > Possible to Extend TCP?" there was a box that silently dropped packets > >> > to port 80 that contained unexpected data instead of valid HTTP. The > >> > unexpected data was commands that the experimenters' had written into > >> > the payload to control their echo-responder. They hadn't expected that > >> > these commands would disrupt the experiment. I don't know of any > >> > experiments that have included expected data followed by unexpected > >> data. > >> > > >> > Whatever, in draft-03 of syn-op-sis (that I'm still working on), I've > >> > put the extension options at the front by default, and made the trailer > >> > mode optional (so experiments can be conducted to find if it is > >> needed). > >> > >> If we do think that this case is common, then we can easily have all the > >> extensions (SYN and otherwise) use space at the end of the segment. It > >> can be something most variants can easily support in a flag, > > > > Yup. It's do-able,... > > > > ...but it's not completely straightforward. For instance, when I tried > > to design against resegmentation, I suggested a "sent payload size" > > field in an email to you. The idea was that the receiver could > > reconstruct where the segment boundaries had been originally - in order > > to find where the options had been put originally. > > > > However, the sender has to place the 'sent payload size' field at the > > start of the segment it refers to. If it places it at the end of each > > segment, the receiver has to wait until the very end of the stream > > before it can work backwards to find where all the segments were - not a > > lot of use. > >Right - the EDO still stays in the DO space, but the extension is at the >tail. If we add the "original segment length" within EDO, then the >receiver might be able to reconstitute the segment if split. > >However, because EDO would still be inside the DO space, the typical >split would copy it into the first segment only. > >-- > >Note that I still think this is inappropriate for EDO. If we want TCP >integrity restoration, we ought to design an option to achieve this. >However, it presents a problem of how to process options that span >segments when the ACK and header flags may differ. > >This turns TCP into a two-layer protocol - one layer for resegmentation >and a different one for the control info. That seems silly - if we want >that level of robustness, we ought to design a tunnel protocol >specifically for that purpose. That's what I've done. TCP is (of course) already a 2-layer protocol - headers at L4 and app-data at L7. I've tunnelled the control options within the app-data in such a way that the receiver can extract them before passing the app-data to the app. >I repeat: > > TCP is not a diagnostic tool. If one starts from the premise that resegmentation within the path is a fault, then separating segmentation into a sub-layer of TCP would be 'diagnostics'. If one starts from the premise that resegmentation ought to be possible on a normal path, then a separate segmentation layer in TCP is 'robust protocol design'. > >> FWIW - I > >> doubt we actually need the entire extension space indicated so far. > > > > TCP is 33 years old. There's no point upgrading it now unless we ensure > > enough space for another 30-50 years at least. > > > > When you start using options to transfer keys (e.g. TCPcrypt) they get > > pretty big (and uncompressable of course). I know it's hard to predict > > what key sizes will be needed (let alone what algorithms will have been > > broken) over such timescales. However, I would be embarrassed if we > > couldn't carry a 4096-bit (512B) key in newly enlarged option space. > >Well, you can barely do so now. > >EOO and EPOO are both one byte, so you can jump over roughly 1K of user >payload (EOO). We already send packets larger than 1K, and if the key + >user data is larger than 1K then EPOO is too small. > >They need to be roughly 14 bits (unless we consider jumbograms, at which >point they need to be 30 bits). When I wrote the above about tcpcrypt, I had already realised the fields in syn-op-sis needed to be larger. Their sizes in the new inner-space draft are now as you suggest - just posted. > > TCPcrypt currently has to do its main key exchange in the payload, which > > is messy. > >IMO, TCPcrypt is messy. TCP isn't out there to support EVERYTHING. Just >like IP doesn't. At the moment, I agree that tcpcrypt is trying to do something that makes it very messy and complex. I believe, implementing 'tcpcrypt-v2' within inner-space would allow tcpcrypt to be decoupled from the TCP state machine, and greatly simplify it. It would be more like a structured version of TLS, meaning that the control channel would be in-band (and therefore subject to encryption) but it would be identified as the control channel by TCP, rather than having to identify /itself/ as the control channel like TLS does. > > We should be ensuring that TCP supports whatever might need to > > be done in the option space without each new option having to hack a > > solution when the space is too small. > >Sometimes the answer to "I want to do that in TCP" can - and should - be >"NO". I don't see tcpcrypt as any different in this respect to TCP-AO. I am trying to restructure TCP so that it makes this sort of thing natural, safe and easy to do simply and correctly. > > I take the view that we might as well allow the set of options to be as > > large as the largest possible segment. That turns out not to be hard or > > wasteful anyway. > >You'd burn 14 bytes total if you did that (EOO and EPOO need to be 30 >bits each). See the new inner-space draft. By default it caters for 16-bit max IP payload, with a jumbo extension for 32-bit max payload size. Overhead is in the hundredths of a percent. Cheers Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Sun Oct 19 23:33:06 2014 Return-Path: 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 786E21A1BEC for ; Sun, 19 Oct 2014 23:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Mb2w8SXjsYl2 for ; Sun, 19 Oct 2014 23:33:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3321A1BE3 for ; Sun, 19 Oct 2014 23:33:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNV15563; Mon, 20 Oct 2014 06:32:59 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 07:32:59 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.88]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 14:32:54 +0800 From: Youjianjie To: "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7C6yn6URl1adl0qtQLFH/DuYRJw4hSEg Date: Mon, 20 Oct 2014 06:32:53 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ABEfepHcvC2hY-9jj4oSGqutHfg Subject: [tcpm] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-you-tcpm-configuring-tcp-initial-window-00=2Etxt?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:33:03 -0000 SGkgYWxsLA0KDQpUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBhIG1ldGhvZCB0byBjb25maWd1cmUg VENQJ3MgaW5pdGlhbCBjb25nZXN0aW9uIHdpbmRvdyBieSBhIG5ldyBBUEkuDQpZb3VyIHF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KDQpCZXN0IFJlZ2FyZHMsDQpKaWFu amllDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumX tDogMjAxNOW5tDEw5pyIMjDml6UgMTQ6MjYNCuaUtuS7tuS6ujogWW91amlhbmppZTsgSHVhbmd5 aWhvbmcgKFJhY2hlbCk7IEh1YW5neWlob25nIChSYWNoZWwpOyBZb3VqaWFuamllDQrkuLvpopg6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmct dGNwLWluaXRpYWwtd2luZG93LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13aW5kb3ctMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppYW5qaWUgWW91IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRj cC1pbml0aWFsLXdpbmRvdw0KUmV2aXNpb246CTAwDQpUaXRsZToJCUNvbmZpZ3VyaW5nIFRDUCdz IEluaXRpYWwgV2luZG93DQpEb2N1bWVudCBkYXRlOgkyMDE0LTEwLTE5DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk4DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWlu aXRpYWwtd2luZG93LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRv dy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15b3Ut dGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13aW5kb3ctMDANCg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoYXQgVENQJ3MgaW5pdGlhbCBjb25nZXN0aW9uIHdp bmRvdyBpcyBub3QgYQ0KICAgY29uc3RhbnQgaW4gZGlmZmVyZW50IHVzZSBjYXNlcy4gIEl0IHBy b3Bvc2VzIGEgZmxleGlibGUgbWV0aG9kIHRvDQogICBjb25maWd1cmUgdGhlIGluaXRpYWwgd2lu ZG93IGluIG9yZGVyIHRvIGtlZXAgdXAgd2l0aCB0aGUgY3VycmVudA0KICAgbmV0d29yayBzdGF0 ZS4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Oct 20 01:19:01 2014 Return-Path: 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 D62291A6FDE for ; Mon, 20 Oct 2014 01:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 pX_b7YljJdK7 for ; Mon, 20 Oct 2014 01:18:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5F51A6FDD for ; Mon, 20 Oct 2014 01:18:56 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9B116A47BB48D; Mon, 20 Oct 2014 08:18:52 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9K8Ijvd008976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 10:18:51 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 10:18:51 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch , tcpm issue tracker , "draft-ietf-tcpm-tcp-edo@tools.ietf.org" , "pasi.sarolahti@iki.fi" Thread-Topic: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? Thread-Index: AQHP6XaVLM0Izt4CuEWw+xjfisth3Zw0zXjd///h3gCAA/kY8A== Date: Mon, 20 Oct 2014 08:18:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1667E02E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <060.624214ca9c69a99fd8bc388f7f1cfd13@trac.tools.ietf.org>, <54401AB2.5070200@isi.edu> <655C07320163294895BBADA28372AF5D1667D916@FR712WXCHMBA15.zeu.alcatel-lucent.com> <54418B00.4040400@isi.edu> In-Reply-To: <54418B00.4040400@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QQasjF-Tnj1Z0Z1Sn6gqMJ9diXo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] #18 (tcp-edo): MUST the EDO option be included in all subsequent segments after being negotiated? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 08:18:58 -0000 > On 10/17/2014 2:29 PM, Scharf, Michael (Michael) wrote: > > I don't recall whether this has already been suggested in the earlier > > threads: > > > > Given that the best answer to the question #18 seems to depend on the > > question whether certain (possibly hypothetical) middleboxes indeed > > exist or not, one solution could be to mandate both modes in the EDO > > spec, right? For instance, the connection originator would then (by > > some signal to be determined) select which mode to use. > > > > Sure, that approach has downsides as well, but if we lack good data > > to make an informed choice right now, we could let the market > > decide... >=20 > Sure; my preference would be to allow the two modes to be independent > as > separate options, e.g.: >=20 > - EDO >=20 > - a lightweight "TCP Integrity Option" that indicated the > user data length for a given segment as transmitted >=20 > That way, EDO could be coupled with TIO as needed, and TIO could be > omitted where redundant (e.g., when using TCP-AO at least). Indeed, a separate option could be a useful approach, in particular if that= option could also be re-used for other TCP extensions. Obviously, the prot= ocol design would have to be sorted out. Michael (chair hat off) From nobody Mon Oct 20 02:42:14 2014 Return-Path: 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 5F9EC1A7020 for ; Mon, 20 Oct 2014 02:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 m2CTGNNwPetI for ; Mon, 20 Oct 2014 02:42:10 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB841A701F for ; Mon, 20 Oct 2014 02:42:10 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xg9TX-0002co-Rh; Mon, 20 Oct 2014 11:42:03 +0200 Received: from mail-ex13.exprod.uio.no ([129.240.120.75]) by mail-mx6.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Xg9TX-00081Q-2G; Mon, 20 Oct 2014 11:42:03 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex13.exprod.uio.no (2001:700:100:120::75) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 20 Oct 2014 11:41:56 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Mon, 20 Oct 2014 11:41:56 +0200 From: Runa Barik To: Youjianjie , "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7C6yn6URl1adl0qtQLFH/DuYRJw4hSEggAAvm5U= Date: Mon, 20 Oct 2014 09:41:55 +0000 Message-ID: <8b40056997754129b96351e867d2e0c9@mail-ex12.exprod.uio.no> References: In-Reply-To: Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 73 max rcpts/h 4 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1052057FCCE807F9C19EA41C0463C42A7952BA64 X-UiO-SPAM-Test: remote_host: 129.240.120.75 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 208 total 346676 max/h 387 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RtdMnEIdayzDUh9s0kxXj5mk47U Cc: "tag@iitmandi.ac.in" , "divakarand@i2r.a-star.edu.sg" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 09:42:12 -0000 SGkgYWxsLAoKRmlyc3QsIEkgYXBwcmVjaWF0ZSB0aGUgYXV0aG9ycyBzdWJtaXR0aW5nIGEgZHJh ZnQgb24gdGhpcyB3b3JrLiBJbiB0aGlzIGRyYWZ0LCBUQ1AgSW5pdGlhbCBXaW5kb3cgKElXKSBp cyBjb21wdXRlZCBiYXNlZCBvbiB0aGUgc2l6ZSBvZiB0aGUgcmVzb3VyY2VzLCBzYXkgZmxvdy1z aXplLiBIb3dldmVyLCBpdCBpcyBtb3JlIGltcG9ydGFudCB0byBjb25zaWRlciB3aGVuIHRoZSBh cHBsaWNhdGlvbiBkb2VzIG5vdCBrbm93IHRoZSBzaXplIGluIGFkdmFuY2UuIEFuZCB0aGUgYXV0 aG9ycyBzZXQgdGhlIElXIHVzaW5nIHNvY2tldCBvcHRpb25zLiAKCkkgd29ya2VkIG9uIHRoZSBw cm9ibGVtIHJlbGF0ZWQgdG8gZGVjaWRpbmcgdGhlIFRDUCBJbml0aWFsIFdpbmRvdyAoSVcpIGlu IG15IE1hc3RlciB0aGVzaXMgYGAgSW1wcm92aW5nIExhdGVuY3kgb2YgTWljZSBpbiB0aGUgSW50 ZXJuZXQ6IEFuIEFwcHJvYWNoIEJhc2VkIG9uIFRDUCBJbml0aWFsIFdpbmRvdyIgKHByb2JsZW0g Zm9jdXMgc3RhcnRlZCBpbiAyMDExKSB1bmRlciBEci4gRGluaWwgTW9uIERpdmFrYXJhbiBpbiBJ SVQgTWFuZGksIEluZGlhLiBXZSBjb25jbHVkZWQgdGhhdCBhIGNvbnN0YW50IHZhbHVlIG9mIElX IGlzIG5vdCBhcHByb3ByaWF0ZSBib3RoIGZyb20gU2ltdWxhdGlvbnMsIGFuZCBBbmFseXRpY2Fs IHRlY2gsIGFuZCB1bmRlcnN0b29kIHRoYXQgSVcgY2FuIGJlIGEgZnVuY3Rpb24gb2YgcmVzb3Vy Y2VzIGluIHNlbmRlci1zaWRlLCBhbmQgbmV0d29yayBzdGF0ZS4gRm9yIHNpbXBsaWNpdHksIHdl IGNvbnNpZGVyZWQgSVcgYXMgYSBmdW5jdGlvbiAgb2YgZmxvdy1zaXplLiBUaGVyZSBhcmUgYSBj b3VwbGUgb2YgcGFwZXJzIGFscmVhZHkgcHVibGlzaGVkIGluIFdXSUMnMTIsIExDTicxMywgTm9G JzE0IChhY2NlcHRlZCBmb3IgcHVibGljYXRpb24pLiBXZSBhbHNvIGltcGxlbWVudGVkIGFuIHVz ZXIgbGlicmFyeSwgYW5kIGluc2lkZSBMaW51eCBrZXJuZWwsIGFuZCB0aGVuIGV4cGVyaW1lbnRl ZCBvbiBhIHJlYWwgdGVzdGJlZCBuZXR3b3JrLiBUaGUgbmljZSB0aGluZyBhYm91dCB0aGlzIHdv cmsgaXMgdGhhdCwgZXZlbiBub3Qga25vd2luZyAgdGhlIG5ldHdvcmsgc3RhdGUsIHRoZSBmbG93 LXNpemUgYmFzZWQgSVcgZnVuY3Rpb24gd29ya3Mgd2VsbCBpbiB2YXJpb3VzIHNjZW5hcmlvcy4g CgpUaGVyZSBhcmUgdmFyaW91cyBpZGVhcyB0aGF0IGNhbiBkb25lIGZvciBjb21wdXRpbmcgSVcu IFRoZXNlIGNhbiBiZToKCiAxLiBCYXNlZCBvbiB0aGUgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIHRo YXQgZmFjZXMgaW4gSVcgbG9zcyBpbiB0aGUgcHJldmlvdXMgUlRULCBmb3IgY29tcHV0aW5nIHRo ZSBJVyBmb3IgbmV3IGNvbm5lY3Rpb247CjIuIEJhc2VkIG9uIHRoZSBudW1iZXIgb2YgcHJldmlv dXMgY29ubmVjdGlvbnMgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10b3VjaC10 Y3BtLWF1dG9tYXRpYy1pdy0wMyksIGFuZCBJVyBsb3NzOwozLiBCYXNlZCBvbiBmbG93IGNoYXJh Y3RlcmlzdGljcy4KCkkgdGhpbmsgdGhpcyBpcyBhIG5pY2Ugd29yayB0byBjb25zaWRlciBmdXJ0 aGVyLCBhbmQgSSBjYW4gY29udHJpYnV0ZSBtb3JlIG9uIHRoaXMuCgpSZWdhcmRzLAogLSBSdW5h IEJhcmlrCiAgIERlcGFydG1lbnQgb2YgSW5mb3JtYXRpY3MKICBVaU8sIE9zbG8sIE5vcndheS4K CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTogdGNwbSA8 dGNwbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgWW91amlhbmppZSA8eW91amlhbmpp ZUBodWF3ZWkuY29tPgpTZW50OiBNb25kYXksIE9jdG9iZXIgMjAsIDIwMTQgODozMiBBTQpUbzog dGNwbUBpZXRmLm9yZwpTdWJqZWN0OiBbdGNwbV0g16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13aW5kb3ctMDAu dHh0CgpIaSBhbGwsCgpUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBhIG1ldGhvZCB0byBjb25maWd1 cmUgVENQJ3MgaW5pdGlhbCBjb25nZXN0aW9uIHdpbmRvdyBieSBhIG5ldyBBUEkuCllvdXIgcXVl c3Rpb25zIGFuZCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuCgpCZXN0IFJlZ2FyZHMsCkppYW5q aWUKCi0tLS0t08q8/tStvP4tLS0tLQq3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIyMMjV IDE0OjI2CsrVvP7IyzogWW91amlhbmppZTsgSHVhbmd5aWhvbmcgKFJhY2hlbCk7IEh1YW5neWlo b25nIChSYWNoZWwpOyBZb3VqaWFuamllCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93LTAwLnR4dAoK CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5p dGlhbC13aW5kb3ctMDAudHh0CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlh bmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LgoKTmFtZTogICAgICAg ICAgIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdwpSZXZpc2lv bjogICAgICAgMDAKVGl0bGU6ICAgICAgICAgIENvbmZpZ3VyaW5nIFRDUCdzIEluaXRpYWwgV2lu ZG93CkRvY3VtZW50IGRhdGU6ICAyMDE0LTEwLTE5Ckdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFs IFN1Ym1pc3Npb24KUGFnZXM6ICAgICAgICAgIDgKVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1p bml0aWFsLXdpbmRvdy0wMC50eHQKU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRv dy8KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdS10 Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMAoKCkFic3RyYWN0OgogICBUaGlz IGRvY3VtZW50IGRpc2N1c3NlcyB0aGF0IFRDUCdzIGluaXRpYWwgY29uZ2VzdGlvbiB3aW5kb3cg aXMgbm90IGEKICAgY29uc3RhbnQgaW4gZGlmZmVyZW50IHVzZSBjYXNlcy4gIEl0IHByb3Bvc2Vz IGEgZmxleGlibGUgbWV0aG9kIHRvCiAgIGNvbmZpZ3VyZSB0aGUgaW5pdGlhbCB3aW5kb3cgaW4g b3JkZXIgdG8ga2VlcCB1cCB3aXRoIHRoZSBjdXJyZW50CiAgIG5ldHdvcmsgc3RhdGUuCgoKCgoK UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLgoKVGhlIElFVEYgU2VjcmV0YXJpYXQKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnRjcG0gbWFpbGlu ZyBsaXN0CnRjcG1AaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90Y3Bt From nobody Mon Oct 20 03:10:30 2014 Return-Path: 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 94A2D1A70FD for ; Mon, 20 Oct 2014 03:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cr1z2hMXOqXc for ; Mon, 20 Oct 2014 03:09:54 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A035D1A7031 for ; Mon, 20 Oct 2014 03:09:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,755,1406617200"; d="scan'208";a="204530652" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx12-out.netapp.com with ESMTP; 20 Oct 2014 03:09:54 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 20 Oct 2014 03:09:27 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Mon, 20 Oct 2014 03:09:26 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: draft-zimmermann-tcpm-undeployed Thread-Index: AQHP7E3tuamDwRWsakGAQfIYjBIHQA== Date: Mon, 20 Oct 2014 10:09:26 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.120.60.36] Content-Type: text/plain; charset="utf-8" Content-ID: <41D6CE3379D8E4408701ACB8EB1B00FC@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BA0iHyHaxPWZojRBl4HUkyv_1d8 Subject: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 10:09:57 -0000 X-List-Received-Date: Mon, 20 Oct 2014 10:09:57 -0000 SGkgYWxsLA0KDQphdCB0aGUgSUVURiA5MCB3ZSBnb3Qgc29tZSBmZWVkYmFjayBmcm9tIFlvc2hp ZnVtaSBhbmQgR29ycnkgbm8gdGhlIGRyYWZ0IChzZWUgbWludXRlcykuIFdlIGluY29ycG9yYXRl ZCB0aG9zZSBmZWVkYmFjayBpbiB2ZXJzaW9uIDAxLiBGcm9tIG91ciBwb2ludCBvZiB2aWV3IHRo ZSBkcmFmdCBpcyByZWFkeS4gSSB3b3VsZCBsaWtlIHRvIGtub3cgaG93IHdlIHByb2NlZWQgdy8g dGhlIGRyYWZ0PyBJIGRvbuKAmXQgdGhpbmsgdGhhdCB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhlIGRy YWZ0IGFnYWluIGluIEhvbm9sdWx1Lg0KDQpBbGV4 From nobody Mon Oct 20 03:41:22 2014 Return-Path: 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 8E9EE1A7022 for ; Mon, 20 Oct 2014 03:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 6giDNunZYxy0 for ; Mon, 20 Oct 2014 03:41:19 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB1F1A00B0 for ; Mon, 20 Oct 2014 03:41:19 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgAOn-0004Ji-PW; Mon, 20 Oct 2014 12:41:13 +0200 Received: from mail-ex02.exprod.uio.no ([129.240.52.5]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XgAOm-0003Gz-VS; Mon, 20 Oct 2014 12:41:13 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex02.exprod.uio.no (2001:700:100:52::5) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 20 Oct 2014 12:41:09 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Mon, 20 Oct 2014 12:41:09 +0200 From: Runa Barik To: Youjianjie , "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7C6yn6URl1adl0qtQLFH/DuYRJw4hSEggAAvm5WAABaK1g== Date: Mon, 20 Oct 2014 10:41:09 +0000 Message-ID: <4d2c316f002248ca91fcaa8d968d6a1b@mail-ex12.exprod.uio.no> References: , <8b40056997754129b96351e867d2e0c9@mail-ex12.exprod.uio.no> In-Reply-To: <8b40056997754129b96351e867d2e0c9@mail-ex12.exprod.uio.no> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 77 max rcpts/h 4 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3F19AD6E2163F342BE7B4D5A29C4033C80B17900 X-UiO-SPAM-Test: remote_host: 129.240.52.5 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 177 total 346382 max/h 380 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/tu6bgv0V_EhPzASyefSTKgmsiXw Cc: "divakarand@i2r.a-star.edu.sg" , "tag@iitmandi.ac.in" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 10:41:21 -0000 SGkgYWxsLAoKIEkgZm9yZ290IHRvIG1lbnRpb24gdGhlIHB1YmxpY2F0aW9ucyBvbiB0aGlzIHdv cmsuCiAxLiBodHRwOi8vbGluay5zcHJpbmdlci5jb20vY2hhcHRlci8xMC4xMDA3JTJGOTc4LTMt NjQyLTMwNjMwLTNfMjUKMi4gIGh0dHA6Ly9pZWVleHBsb3JlLmllZWUub3JnL3hwbHMvYWJzX2Fs bC5qc3A/YXJudW1iZXI9Njc2MTI4NCZ0YWc9MQozLiBodHRwOi8vd3d3Lm5ldHdvcmstb2YtdGhl LWZ1dHVyZS5vcmcKCldlIGFyZSBhYm91dCB0byBzdWJtaXQgYSBwYXBlciBgYENoYXJhY3Rlcml6 aW5nIHRoZSBlZmZlY3RzIG9mIFRDUCBJbml0aWFsIFdpbmRvdyIuCgpSZWdhcmRzLAotIFJ1bmEg QmFyaWsKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiB0Y3Bt IDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSdW5hIEJhcmlrIDxydW5hYmtA aWZpLnVpby5ubz4KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAyMDE0IDExOjQxIEFNClRvOiBZ b3VqaWFuamllOyB0Y3BtQGlldGYub3JnCkNjOiB0YWdAaWl0bWFuZGkuYWMuaW47IGRpdmFrYXJh bmRAaTJyLmEtc3Rhci5lZHUuc2cKU3ViamVjdDogUmU6IFt0Y3BtXSBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRv dy0wMC50eHQKCkhpIGFsbCwKCkZpcnN0LCBJIGFwcHJlY2lhdGUgdGhlIGF1dGhvcnMgc3VibWl0 dGluZyBhIGRyYWZ0IG9uIHRoaXMgd29yay4gSW4gdGhpcyBkcmFmdCwgVENQIEluaXRpYWwgV2lu ZG93IChJVykgaXMgY29tcHV0ZWQgYmFzZWQgb24gdGhlIHNpemUgb2YgdGhlIHJlc291cmNlcywg c2F5IGZsb3ctc2l6ZS4gSG93ZXZlciwgaXQgaXMgbW9yZSBpbXBvcnRhbnQgdG8gY29uc2lkZXIg d2hlbiB0aGUgYXBwbGljYXRpb24gZG9lcyBub3Qga25vdyB0aGUgc2l6ZSBpbiBhZHZhbmNlLiBB bmQgdGhlIGF1dGhvcnMgc2V0IHRoZSBJVyB1c2luZyBzb2NrZXQgb3B0aW9ucy4KCkkgd29ya2Vk IG9uIHRoZSBwcm9ibGVtIHJlbGF0ZWQgdG8gZGVjaWRpbmcgdGhlIFRDUCBJbml0aWFsIFdpbmRv dyAoSVcpIGluIG15IE1hc3RlciB0aGVzaXMgYGAgSW1wcm92aW5nIExhdGVuY3kgb2YgTWljZSBp biB0aGUgSW50ZXJuZXQ6IEFuIEFwcHJvYWNoIEJhc2VkIG9uIFRDUCBJbml0aWFsIFdpbmRvdyIg KHByb2JsZW0gZm9jdXMgc3RhcnRlZCBpbiAyMDExKSB1bmRlciBEci4gRGluaWwgTW9uIERpdmFr YXJhbiBpbiBJSVQgTWFuZGksIEluZGlhLiBXZSBjb25jbHVkZWQgdGhhdCBhIGNvbnN0YW50IHZh bHVlIG9mIElXIGlzIG5vdCBhcHByb3ByaWF0ZSBib3RoIGZyb20gU2ltdWxhdGlvbnMsIGFuZCBB bmFseXRpY2FsIHRlY2gsIGFuZCB1bmRlcnN0b29kIHRoYXQgSVcgY2FuIGJlIGEgZnVuY3Rpb24g b2YgcmVzb3VyY2VzIGluIHNlbmRlci1zaWRlLCBhbmQgbmV0d29yayBzdGF0ZS4gRm9yIHNpbXBs aWNpdHksIHdlIGNvbnNpZGVyZWQgSVcgYXMgYSBmdW5jdGlvbiAgb2YgZmxvdy1zaXplLiBUaGVy ZSBhcmUgYSBjb3VwbGUgb2YgcGFwZXJzIGFscmVhZHkgcHVibGlzaGVkIGluIFdXSUMnMTIsIExD TicxMywgTm9GJzE0IChhY2NlcHRlZCBmb3IgcHVibGljYXRpb24pLiBXZSBhbHNvIGltcGxlbWVu dGVkIGFuIHVzZXIgbGlicmFyeSwgYW5kIGluc2lkZSBMaW51eCBrZXJuZWwsIGFuZCB0aGVuIGV4 cGVyaW1lbnRlZCBvbiBhIHJlYWwgdGVzdGJlZCBuZXR3b3JrLiBUaGUgbmljZSB0aGluZyBhYm91 dCB0aGlzIHdvcmsgaXMgdGhhdCwgZXZlbiBub3Qga25vd2luZyAgdGhlIG5ldHdvcmsgc3RhdGUs IHRoZSBmbG93LXNpemUgYmFzZWQgSVcgZnVuY3Rpb24gd29ya3Mgd2VsbCBpbiB2YXJpb3VzIHNj ZW5hcmlvcy4KClRoZXJlIGFyZSB2YXJpb3VzIGlkZWFzIHRoYXQgY2FuIGRvbmUgZm9yIGNvbXB1 dGluZyBJVy4gVGhlc2UgY2FuIGJlOgoKIDEuIEJhc2VkIG9uIHRoZSBudW1iZXIgb2YgY29ubmVj dGlvbnMgdGhhdCBmYWNlcyBpbiBJVyBsb3NzIGluIHRoZSBwcmV2aW91cyBSVFQsIGZvciBjb21w dXRpbmcgdGhlIElXIGZvciBuZXcgY29ubmVjdGlvbjsKMi4gQmFzZWQgb24gdGhlIG51bWJlciBv ZiBwcmV2aW91cyBjb25uZWN0aW9ucyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRvdWNoLXRjcG0tYXV0b21hdGljLWl3LTAzKSwgYW5kIElXIGxvc3M7CjMuIEJhc2VkIG9uIGZs b3cgY2hhcmFjdGVyaXN0aWNzLgoKSSB0aGluayB0aGlzIGlzIGEgbmljZSB3b3JrIHRvIGNvbnNp ZGVyIGZ1cnRoZXIsIGFuZCBJIGNhbiBjb250cmlidXRlIG1vcmUgb24gdGhpcy4KClJlZ2FyZHMs CiAtIFJ1bmEgQmFyaWsKICAgRGVwYXJ0bWVudCBvZiBJbmZvcm1hdGljcwogIFVpTywgT3Nsbywg Tm9yd2F5LgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9t OiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBZb3VqaWFuamllIDx5 b3VqaWFuamllQGh1YXdlaS5jb20+ClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAxNCA4OjMy IEFNClRvOiB0Y3BtQGlldGYub3JnClN1YmplY3Q6IFt0Y3BtXSDXqreiOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdp bmRvdy0wMC50eHQKCkhpIGFsbCwKClRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGEgbWV0aG9kIHRv IGNvbmZpZ3VyZSBUQ1AncyBpbml0aWFsIGNvbmdlc3Rpb24gd2luZG93IGJ5IGEgbmV3IEFQSS4K WW91ciBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4KCkJlc3QgUmVnYXJk cywKSmlhbmppZQoKLS0tLS3Tyrz+1K28/i0tLS0tCreivP7IyzogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQq3osvNyrG85DogMjAxNMTq MTDUwjIwyNUgMTQ6MjYKytW8/sjLOiBZb3VqaWFuamllOyBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsg SHVhbmd5aWhvbmcgKFJhY2hlbCk7IFlvdWppYW5qaWUK1vfM4jogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13aW5kb3ct MDAudHh0CgoKQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5n LXRjcC1pbml0aWFsLXdpbmRvdy0wMC50eHQKaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBKaWFuamllIFlvdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuCgpOYW1l OiAgICAgICAgICAgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93 ClJldmlzaW9uOiAgICAgICAwMApUaXRsZTogICAgICAgICAgQ29uZmlndXJpbmcgVENQJ3MgSW5p dGlhbCBXaW5kb3cKRG9jdW1lbnQgZGF0ZTogIDIwMTQtMTAtMTkKR3JvdXA6ICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbgpQYWdlczogICAgICAgICAgOApVUkw6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteW91LXRjcG0tY29uZmlndXJp bmctdGNwLWluaXRpYWwtd2luZG93LTAwLnR4dApTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRp YWwtd2luZG93LwpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93LTAwCgoKQWJzdHJhY3Q6 CiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoYXQgVENQJ3MgaW5pdGlhbCBjb25nZXN0aW9u IHdpbmRvdyBpcyBub3QgYQogICBjb25zdGFudCBpbiBkaWZmZXJlbnQgdXNlIGNhc2VzLiAgSXQg cHJvcG9zZXMgYSBmbGV4aWJsZSBtZXRob2QgdG8KICAgY29uZmlndXJlIHRoZSBpbml0aWFsIHdp bmRvdyBpbiBvcmRlciB0byBrZWVwIHVwIHdpdGggdGhlIGN1cnJlbnQKICAgbmV0d29yayBzdGF0 ZS4KCgoKCgpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuCgpUaGUgSUVURiBTZWNyZXRh cmlhdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdGNw bSBtYWlsaW5nIGxpc3QKdGNwbUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RjcG0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNwbUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0= From nobody Mon Oct 20 04:38:17 2014 Return-Path: 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 ACB091A86F4 for ; Mon, 20 Oct 2014 04:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 fX44ePkG0Qpf for ; Mon, 20 Oct 2014 04:38:14 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id A0F071A86F2 for ; Mon, 20 Oct 2014 04:38:13 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 543C16C90086E17E; Mon, 20 Oct 2014 14:38:10 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> Date: Mon, 20 Oct 2014 14:38:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NcHUxBJCFY4zKkl6Ca6iY75E7ms Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 11:38:15 -0000 On 20 Oct 2014, at 13:09, Zimmermann, Alexander = wrote: > at the IETF 90 we got some feedback from Yoshifumi and Gorry no the = draft (see minutes). We incorporated those feedback in version 01. =46rom = our point of view the draft is ready. I would like to know how we = proceed w/ the draft? I don=92t think that we need to discuss the draft = again in Honolulu. Just wanted to check one thing: isn=92t TCPMUX supported by [x]inetd = implementations? It=92s probably not much used, but there seem to be = deployed implementations, so perhaps it isn't correct to call it = obsolete? Any opinions? Also, RFC 6013 strikes as quite recent for a =93Historic=94 document, = although I fully agree with its description in the roadmap. (I=92m not = against the change, just generally wondering why an independent stream = RFC is approved with one status, if it is going to be changed to = Historic soon after) - Pasi From nobody Mon Oct 20 05:52:34 2014 Return-Path: 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 889CA1A8718 for ; Mon, 20 Oct 2014 05:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 tf3oVP3CjY0L for ; Mon, 20 Oct 2014 05:52:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A1F1A8714 for ; Mon, 20 Oct 2014 05:52:31 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 84DE88ED8EC38; Mon, 20 Oct 2014 12:52:27 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9KCqRar025759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 14:52:27 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 14:52:27 +0200 From: "Scharf, Michael (Michael)" To: Runa Barik , Youjianjie , "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7C6yn6URl1adl0qtQLFH/DuYRJw4hSEggAAvm5WAABaK1oAAIeJg Date: Mon, 20 Oct 2014 12:52:26 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1667E5EE@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: , <8b40056997754129b96351e867d2e0c9@mail-ex12.exprod.uio.no> <4d2c316f002248ca91fcaa8d968d6a1b@mail-ex12.exprod.uio.no> In-Reply-To: <4d2c316f002248ca91fcaa8d968d6a1b@mail-ex12.exprod.uio.no> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9x7fBC1qAk1CHnQYn0_VubfkdCQ Cc: "tag@iitmandi.ac.in" , "divakarand@i2r.a-star.edu.sg" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 12:52:33 -0000 SmlhbmppZSwgUnVuYSwNCg0KUmVzZWFyY2ggcmVzdWx0cyByZWdhcmRpbmcgaG93IHRvIChhdXRv bWF0aWNhbGx5KSBzZXQgdGhlIElXIGFyZSBwcm9iYWJseSBiZXR0ZXIgZGlzY3Vzc2VkIGluIHRo ZSBJQ0NSRywgYXQgbGVhc3QgdW50aWwgSUNDUkcgY2FuIGdpdmUgVENQTSBhIGdvb2QgcmVjb21t ZW5kYXRpb24gaG93IHRvIGFjdHVhbGx5IGVuZ2luZWVyIGEgc29sdXRpb24uDQoNCkZ1cnRoZXJt b3JlLCBpbiB0aGUgcGFzdCB0aGVyZSBoYXMgYmVlbiBhIGNlcnRhaW4gY29uc2Vuc3VzIHRoYXQg SUVURiB3b3JraW5nIGdyb3VwcyBvbmx5IHN0YW5kYXJkaXplIGFic3RyYWN0IEFQSXMgdG8gdGhl IG5ldHdvcmsgc3RhY2suIFRoZSBhY3R1YWwgaW1wbGVtZW50YXRpb24gZS5nLiBhcyBhIHNvY2tl dCBvcHRpb24gZGVwZW5kcyBvbiB0aGUgb3BlcmF0aW5nIHN5c3RlbS4NCg0KQmVzdCByZWdhcmRz DQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRj cG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSdW5hIEJhcmlr DQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAxNCAxMjo0MSBQTQ0KPiBUbzogWW91amlh bmppZTsgdGNwbUBpZXRmLm9yZw0KPiBDYzogZGl2YWthcmFuZEBpMnIuYS1zdGFyLmVkdS5zZzsg dGFnQGlpdG1hbmRpLmFjLmluDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC15b3UtdGNwbS0NCj4gY29uZmlndXJpbmctdGNwLWluaXRpYWwt d2luZG93LTAwLnR4dA0KPiANCj4gSGkgYWxsLA0KPiANCj4gIEkgZm9yZ290IHRvIG1lbnRpb24g dGhlIHB1YmxpY2F0aW9ucyBvbiB0aGlzIHdvcmsuDQo+ICAxLiBodHRwOi8vbGluay5zcHJpbmdl ci5jb20vY2hhcHRlci8xMC4xMDA3JTJGOTc4LTMtNjQyLTMwNjMwLTNfMjUNCj4gMi4gIGh0dHA6 Ly9pZWVleHBsb3JlLmllZWUub3JnL3hwbHMvYWJzX2FsbC5qc3A/YXJudW1iZXI9Njc2MTI4NCZ0 YWc9MQ0KPiAzLiBodHRwOi8vd3d3Lm5ldHdvcmstb2YtdGhlLWZ1dHVyZS5vcmcNCj4gDQo+IFdl IGFyZSBhYm91dCB0byBzdWJtaXQgYSBwYXBlciBgYENoYXJhY3Rlcml6aW5nIHRoZSBlZmZlY3Rz IG9mIFRDUA0KPiBJbml0aWFsIFdpbmRvdyIuDQo+IA0KPiBSZWdhcmRzLA0KPiAtIFJ1bmEgQmFy aWsNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiB0 Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSdW5hIEJhcmlrDQo+IDxy dW5hYmtAaWZpLnVpby5ubz4NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAyMDE0IDExOjQx IEFNDQo+IFRvOiBZb3VqaWFuamllOyB0Y3BtQGlldGYub3JnDQo+IENjOiB0YWdAaWl0bWFuZGku YWMuaW47IGRpdmFrYXJhbmRAaTJyLmEtc3Rhci5lZHUuc2cNCj4gU3ViamVjdDogUmU6IFt0Y3Bt XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdS10Y3BtLQ0KPiBjb25maWd1 cmluZy10Y3AtaW5pdGlhbC13aW5kb3ctMDAudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBGaXJz dCwgSSBhcHByZWNpYXRlIHRoZSBhdXRob3JzIHN1Ym1pdHRpbmcgYSBkcmFmdCBvbiB0aGlzIHdv cmsuIEluDQo+IHRoaXMgZHJhZnQsIFRDUCBJbml0aWFsIFdpbmRvdyAoSVcpIGlzIGNvbXB1dGVk IGJhc2VkIG9uIHRoZSBzaXplIG9mDQo+IHRoZSByZXNvdXJjZXMsIHNheSBmbG93LXNpemUuIEhv d2V2ZXIsIGl0IGlzIG1vcmUgaW1wb3J0YW50IHRvIGNvbnNpZGVyDQo+IHdoZW4gdGhlIGFwcGxp Y2F0aW9uIGRvZXMgbm90IGtub3cgdGhlIHNpemUgaW4gYWR2YW5jZS4gQW5kIHRoZSBhdXRob3Jz DQo+IHNldCB0aGUgSVcgdXNpbmcgc29ja2V0IG9wdGlvbnMuDQo+IA0KPiBJIHdvcmtlZCBvbiB0 aGUgcHJvYmxlbSByZWxhdGVkIHRvIGRlY2lkaW5nIHRoZSBUQ1AgSW5pdGlhbCBXaW5kb3cgKElX KQ0KPiBpbiBteSBNYXN0ZXIgdGhlc2lzIGBgIEltcHJvdmluZyBMYXRlbmN5IG9mIE1pY2UgaW4g dGhlIEludGVybmV0OiBBbg0KPiBBcHByb2FjaCBCYXNlZCBvbiBUQ1AgSW5pdGlhbCBXaW5kb3ci IChwcm9ibGVtIGZvY3VzIHN0YXJ0ZWQgaW4gMjAxMSkNCj4gdW5kZXIgRHIuIERpbmlsIE1vbiBE aXZha2FyYW4gaW4gSUlUIE1hbmRpLCBJbmRpYS4gV2UgY29uY2x1ZGVkIHRoYXQgYQ0KPiBjb25z dGFudCB2YWx1ZSBvZiBJVyBpcyBub3QgYXBwcm9wcmlhdGUgYm90aCBmcm9tIFNpbXVsYXRpb25z LCBhbmQNCj4gQW5hbHl0aWNhbCB0ZWNoLCBhbmQgdW5kZXJzdG9vZCB0aGF0IElXIGNhbiBiZSBh IGZ1bmN0aW9uIG9mIHJlc291cmNlcw0KPiBpbiBzZW5kZXItc2lkZSwgYW5kIG5ldHdvcmsgc3Rh dGUuIEZvciBzaW1wbGljaXR5LCB3ZSBjb25zaWRlcmVkIElXIGFzDQo+IGEgZnVuY3Rpb24gIG9m IGZsb3ctc2l6ZS4gVGhlcmUgYXJlIGEgY291cGxlIG9mIHBhcGVycyBhbHJlYWR5DQo+IHB1Ymxp c2hlZCBpbiBXV0lDJzEyLCBMQ04nMTMsIE5vRicxNCAoYWNjZXB0ZWQgZm9yIHB1YmxpY2F0aW9u KS4gV2UNCj4gYWxzbyBpbXBsZW1lbnRlZCBhbiB1c2VyIGxpYnJhcnksIGFuZCBpbnNpZGUgTGlu dXgga2VybmVsLCBhbmQgdGhlbg0KPiBleHBlcmltZW50ZWQgb24gYSByZWFsIHRlc3RiZWQgbmV0 d29yay4gVGhlIG5pY2UgdGhpbmcgYWJvdXQgdGhpcyB3b3JrDQo+IGlzIHRoYXQsIGV2ZW4gbm90 IGtub3dpbmcgIHRoZSBuZXR3b3JrIHN0YXRlLCB0aGUgZmxvdy1zaXplIGJhc2VkIElXDQo+IGZ1 bmN0aW9uIHdvcmtzIHdlbGwgaW4gdmFyaW91cyBzY2VuYXJpb3MuDQo+IA0KPiBUaGVyZSBhcmUg dmFyaW91cyBpZGVhcyB0aGF0IGNhbiBkb25lIGZvciBjb21wdXRpbmcgSVcuIFRoZXNlIGNhbiBi ZToNCj4gDQo+ICAxLiBCYXNlZCBvbiB0aGUgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIHRoYXQgZmFj ZXMgaW4gSVcgbG9zcyBpbiB0aGUNCj4gcHJldmlvdXMgUlRULCBmb3IgY29tcHV0aW5nIHRoZSBJ VyBmb3IgbmV3IGNvbm5lY3Rpb247DQo+IDIuIEJhc2VkIG9uIHRoZSBudW1iZXIgb2YgcHJldmlv dXMgY29ubmVjdGlvbnMNCj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10b3Vj aC10Y3BtLWF1dG9tYXRpYy1pdy0wMyksIGFuZCBJVw0KPiBsb3NzOw0KPiAzLiBCYXNlZCBvbiBm bG93IGNoYXJhY3RlcmlzdGljcy4NCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBhIG5pY2Ugd29yayB0 byBjb25zaWRlciBmdXJ0aGVyLCBhbmQgSSBjYW4gY29udHJpYnV0ZQ0KPiBtb3JlIG9uIHRoaXMu DQo+IA0KPiBSZWdhcmRzLA0KPiAgLSBSdW5hIEJhcmlrDQo+ICAgIERlcGFydG1lbnQgb2YgSW5m b3JtYXRpY3MNCj4gICBVaU8sIE9zbG8sIE5vcndheS4NCj4gDQo+IA0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogdGNwbSA8dGNwbS1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgWW91amlhbmppZQ0KPiA8eW91amlhbmppZUBo dWF3ZWkuY29tPg0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjAsIDIwMTQgODozMiBBTQ0KPiBU bzogdGNwbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdGNwbV0g16q3ojogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC15b3UtdGNwbS0NCj4gY29uZmlndXJpbmctdGNwLWluaXRpYWwt d2luZG93LTAwLnR4dA0KPiANCj4gSGkgYWxsLA0KPiANCj4gVGhpcyBkb2N1bWVudCBkaXNjdXNz ZXMgYSBtZXRob2QgdG8gY29uZmlndXJlIFRDUCdzIGluaXRpYWwgY29uZ2VzdGlvbg0KPiB3aW5k b3cgYnkgYSBuZXcgQVBJLg0KPiBZb3VyIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgYXJlIGFwcHJl Y2lhdGVkLg0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiBKaWFuamllDQo+IA0KPiAtLS0tLdPKvP7U rbz+LS0tLS0NCj4gt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ILeiy83KsbzkOiAyMDE0xOoxMNTCMjDI1SAxNDoyNg0K PiDK1bz+yMs6IFlvdWppYW5qaWU7IEh1YW5neWlob25nIChSYWNoZWwpOyBIdWFuZ3lpaG9uZyAo UmFjaGVsKTsNCj4gWW91amlhbmppZQ0KPiDW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC0NCj4gaW5pdGlhbC13aW5kb3ctMDAu dHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXlvdS10Y3BtLWNvbmZp Z3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0NCj4gMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiBy ZXBvc2l0b3J5Lg0KPiANCj4gTmFtZTogICAgICAgICAgIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3Vy aW5nLXRjcC1pbml0aWFsLXdpbmRvdw0KPiBSZXZpc2lvbjogICAgICAgMDANCj4gVGl0bGU6ICAg ICAgICAgIENvbmZpZ3VyaW5nIFRDUCdzIEluaXRpYWwgV2luZG93DQo+IERvY3VtZW50IGRhdGU6 ICAyMDE0LTEwLTE5DQo+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g UGFnZXM6ICAgICAgICAgIDgNCj4gVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvdS10Y3BtLQ0KPiBjb25maWd1cmluZy10Y3AtaW5pdGlh bC13aW5kb3ctMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC15b3UtdGNwbS0NCj4gY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2lu ZG93Lw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eW91LXRjcG0tY29uZmlndXJpbmctDQo+IHRjcC1pbml0aWFsLXdpbmRvdy0wMA0KPiANCj4gDQo+ IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGF0IFRDUCdzIGluaXRp YWwgY29uZ2VzdGlvbiB3aW5kb3cgaXMgbm90DQo+IGENCj4gICAgY29uc3RhbnQgaW4gZGlmZmVy ZW50IHVzZSBjYXNlcy4gIEl0IHByb3Bvc2VzIGEgZmxleGlibGUgbWV0aG9kIHRvDQo+ICAgIGNv bmZpZ3VyZSB0aGUgaW5pdGlhbCB3aW5kb3cgaW4gb3JkZXIgdG8ga2VlcCB1cCB3aXRoIHRoZSBj dXJyZW50DQo+ICAgIG5ldHdvcmsgc3RhdGUuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGlu ZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y3BtDQo= From nobody Mon Oct 20 08:37:38 2014 Return-Path: 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 E01AC1A1B45 for ; Mon, 20 Oct 2014 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.31 X-Spam-Level: ** X-Spam-Status: No, score=2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 5wS1l0w_o3MH for ; Mon, 20 Oct 2014 08:37:29 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E511A1B23 for ; Mon, 20 Oct 2014 08:35:32 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gq15so4096648lab.40 for ; Mon, 20 Oct 2014 08:35:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OB8yycAkYqovonIQjqVjGnMEOL0jQjV8T8zNUBKBElU=; b=K8cUDtdIl557l6XOBgTr5fsIW5GfehZV72dMgs1b1CUAHwFVu76++5q3+q9g8C6p/b CXhEElIGCmAZN56GcjKKFrO6kMssb1u0UiLhwnzkNuE4nl7awRNyRfd7KLFabtNxuCe8 iby18F3gUbPjODsUCjttVj70alhyZvDTS2AslohQTTgNWV8v9fDYVFW+RMtGDXB97HHL YjPhFDTOCUmoa+16c9L8bgcxiQOK2q++T4BT8g+joVeXDkkPY3w9Q4An+lOvDYGGtIoy UY/Gwtx+9PKOfuo4K9ScCIBdY6eHdOC/fxkrrzlJdi3+XaAfom5nsqg3t1ZjMlZ/RYCj Q/Sg== X-Gm-Message-State: ALoCoQmTMN0JUUlidKD72/0NNf1ZIZquksTqDHo5nQUyDOm8RSRa8nujG+IVIc5rMEeYVuZ0Qy33 MIME-Version: 1.0 X-Received: by 10.112.73.35 with SMTP id i3mr28482510lbv.75.1413819330855; Mon, 20 Oct 2014 08:35:30 -0700 (PDT) Received: by 10.25.21.207 with HTTP; Mon, 20 Oct 2014 08:35:30 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: References: Date: Mon, 20 Oct 2014 17:35:30 +0200 Message-ID: From: Hagen Paul Pfeifer To: Youjianjie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/44kAydDjhMForhjXUMgCNPkHw-I Cc: "tcpm@ietf.org" Subject: Re: [tcpm] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-you-tcpm-configuring-tcp-initial-window-00=2Etxt?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:37:32 -0000 On 20 October 2014 08:32, Youjianjie wrote: > This document discusses a method to configure TCP's initial congestion window by a new API. > Your questions and comments are appreciated. Hello Youjianjie, how do I - from a user/programmer perspective - know a save and fair IW value in advance? And how you make sure that misconfigurations will never negatively effects _network stability_ (not your local stack stability)? A great deal of the Linux kernel community will refuse this effort. Particular because someone will publish a blog post titled "Make Internet Connection faster" with tips to "setsockopt(fd, TCP_IW, 200)" and everybody will add this their software (like the socketbuffer tunning tips to set buffers to thousands of gbyte). IW is a sensitive parameter with probably huge negative impact if using wrong - like selecting an unfair congestion control algorithm. BTW: do you have analysis done in your setup with 50Kbit/s in a MANET multihop scenario and short lived TCP flows? Best regards, Hagen From nobody Mon Oct 20 11:46:53 2014 Return-Path: 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 D63491A9027 for ; Mon, 20 Oct 2014 11:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 BOmeZzVufSYc for ; Mon, 20 Oct 2014 11:46:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95BC1A903D for ; Mon, 20 Oct 2014 11:46:30 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9KIk9l0020268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 11:46:09 -0700 (PDT) Message-ID: <54455871.30909@isi.edu> Date: Mon, 20 Oct 2014 11:46:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Pasi Sarolahti , "Zimmermann, Alexander" References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> In-Reply-To: <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/L0PPAlM4ggz9-VOdI4YiKEatncI Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:46:50 -0000 On 10/20/2014 4:38 AM, Pasi Sarolahti wrote: > Just wanted to check one thing: isn’t TCPMUX supported by [x]inetd > implementations? It appears so, but that's the server side, depending on the services listed in inetd.conf. The question is whether any client contacts it and whether those clients end up connecting. TCPMUX doesn't handle connections from unknown ports; the client has to use TCPMUX to send the port in-band before the rest of the user data. > It’s probably not much used, but there seem to be > deployed implementations, so perhaps it isn't correct to call it > obsolete? Any opinions? I don't think it qualifies for this document. A deeper investigation of whether there are clients that use this seems needed. Joe From nobody Mon Oct 20 11:49:09 2014 Return-Path: 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 D79D31A904C for ; Mon, 20 Oct 2014 11:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 mUTPVTfmzabK for ; Mon, 20 Oct 2014 11:49:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCCF1A9036 for ; Mon, 20 Oct 2014 11:49:00 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9KImTiT020937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 11:48:29 -0700 (PDT) Message-ID: <544558FD.3090802@isi.edu> Date: Mon, 20 Oct 2014 11:48:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Youjianjie , "tcpm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/nyVWadszv2fmRzqrxc4l49DF6FM Subject: Re: [tcpm] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-you-tcpm-configuring-tcp-initial-window-00=2Etxt?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:49:05 -0000 There has been a proposal to automate the IW which was described here: http://tools.ietf.org/html/draft-touch-tcpm-automatic-iw-03 An API might interact with that mechanism, e.g., changing parameters. Joe On 10/19/2014 11:32 PM, Youjianjie wrote: > Hi all, > > This document discusses a method to configure TCP's initial congestion window by a new API. > Your questions and comments are appreciated. > > Best Regards, > Jianjie > > -----邮件åŸä»¶----- > å‘件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > å‘é€æ—¶é—´: 2014å¹´10月20æ—¥ 14:26 > 收件人: Youjianjie; Huangyihong (Rachel); Huangyihong (Rachel); Youjianjie > 主题: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt > > > A new version of I-D, draft-you-tcpm-configuring-tcp-initial-window-00.txt > has been successfully submitted by Jianjie You and posted to the IETF repository. > > Name: draft-you-tcpm-configuring-tcp-initial-window > Revision: 00 > Title: Configuring TCP's Initial Window > Document date: 2014-10-19 > Group: Individual Submission > Pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-you-tcpm-configuring-tcp-initial-window-00.txt > Status: https://datatracker.ietf.org/doc/draft-you-tcpm-configuring-tcp-initial-window/ > Htmlized: http://tools.ietf.org/html/draft-you-tcpm-configuring-tcp-initial-window-00 > > > Abstract: > This document discusses that TCP's initial congestion window is not a > constant in different use cases. It proposes a flexible method to > configure the initial window in order to keep up with the current > network state. > > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Oct 20 11:55:41 2014 Return-Path: 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 BA94C1A90DE for ; Mon, 20 Oct 2014 11:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 U2Vp4ExdgKp1 for ; Mon, 20 Oct 2014 11:55:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE361A90D5 for ; Mon, 20 Oct 2014 11:55:37 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9KIsWbW022068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 11:54:33 -0700 (PDT) Message-ID: <54455A68.9040708@isi.edu> Date: Mon, 20 Oct 2014 11:54:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bob Briscoe , SCHARF Michael , "SAROLAHTI, Pasi" , Yoshifumi Nishida References: <201410200058.s9K0wQnS014207@bagheera.jungle.bt.co.uk> In-Reply-To: <201410200058.s9K0wQnS014207@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/E9FU93bbvW65L6-onDZH4jh_BDo Cc: tcpm IETF list Subject: Re: [tcpm] More option space on any segment: draft-briscoe-tcpm-inner-space-00 (was syn-op-sis-02) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:55:38 -0000 On 10/19/2014 5:58 PM, Bob Briscoe wrote: > Chairs and list, > > My individual draft has a new file-name (and title): inner-space-00 > > This is a major rev of syn-op-sis-02 > , but I > won't be using that name any more. > Sorry to confuse everyone by changing the name. But the old name was no > longer relevant. > > I believe the new Inner Space protocol could be a significant advance > for TCP. IMO, you're on the path to implementing TCP inside TCP. That is, right up until a middlebox starts parsing and modifying the inner TCP, at which point you'll need TCP-in-TCP-in-TCP, ad infinitum. IMO this whole exercise is a significant step backwards, except as a good example of why we need constraints for middleboxes. Joe From nobody Mon Oct 20 12:04:28 2014 Return-Path: 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 C6ECE1A9115 for ; Mon, 20 Oct 2014 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 biog7vsuGUMg for ; Mon, 20 Oct 2014 12:04:24 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75F91A9134 for ; Mon, 20 Oct 2014 12:04:24 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9KJ46Ct023740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 12:04:06 -0700 (PDT) Message-ID: <54455CA6.2020105@isi.edu> Date: Mon, 20 Oct 2014 12:04:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bob Briscoe References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> <543DA031.6090705@isi.edu> <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> In-Reply-To: <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/SUgGPgcjCzmyTayb2gjRr0JPDD4 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:04:26 -0000 On 10/19/2014 6:15 PM, Bob Briscoe wrote: > Joe, ... >> > * The syn-op-sis client ensures that it aborts the connection to a >> > legacy server before it passes this corrupt TCP Data to the app. >> >> You have to prohibit use of TFO (and maybe some others, e.g., TCPCT) >> with syn-op-sys in that case. > > Nope (we've been through that argument, and I recall you suddenly 'got > it' at one point). You mentioned putting TFO in the extension space for the extended SYN. You still have the problem of the legacy SYN - if that uses TFO, you'd be trying to stop a connection after user data were passed to the app. I.e., you have to prohibit TFO on the legacy SYN. Joe From nobody Mon Oct 20 12:20:06 2014 Return-Path: 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 08F5E1AC3B0 for ; Mon, 20 Oct 2014 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 VgrQzbykmZ9R for ; Mon, 20 Oct 2014 12:19:50 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8C21AC3C4 for ; Mon, 20 Oct 2014 12:19:42 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgIUW-0003jF-O1; Mon, 20 Oct 2014 21:19:40 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1XgIUW-0007Y8-4v; Mon, 20 Oct 2014 21:19:40 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: Date: Mon, 20 Oct 2014 21:19:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hagen Paul Pfeifer X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 21524 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2B7D797E092C85A27978DC5CBC29E0C6E8826813 X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 438 max/h 11 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4MaJSVD2Ue0B0ITCkDvKr47x2Gw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:19:52 -0000 Hi Hagen, I'm not Youjianjie, still - what if 10 is used as a default (like now) and an upper limit? Cheers, Michael > On 20. okt. 2014, at 17.35, Hagen Paul Pfeifer wrote: >=20 > On 20 October 2014 08:32, Youjianjie wrote: >> This document discusses a method to configure TCP's initial = congestion window by a new API. >> Your questions and comments are appreciated. >=20 > Hello Youjianjie, >=20 > how do I - from a user/programmer perspective - know a save and fair > IW value in advance? And how you make sure that misconfigurations will > never negatively effects _network stability_ (not your local stack > stability)? A great deal of the Linux kernel community will refuse > this effort. Particular because someone will publish a blog post > titled "Make Internet Connection faster" with tips to "setsockopt(fd, > TCP_IW, 200)" and everybody will add this their software (like the > socketbuffer tunning tips to set buffers to thousands of gbyte). IW is > a sensitive parameter with probably huge negative impact if using > wrong - like selecting an unfair congestion control algorithm. >=20 > BTW: do you have analysis done in your setup with 50Kbit/s in a MANET > multihop scenario and short lived TCP flows? >=20 > Best regards, Hagen >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Oct 20 13:21:06 2014 Return-Path: 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 4FE811ACDD3 for ; Mon, 20 Oct 2014 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.379 X-Spam-Level: **** X-Spam-Status: No, score=4.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 fuERK5M6i-PD for ; Mon, 20 Oct 2014 13:21:02 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217DC1ACDA1 for ; Mon, 20 Oct 2014 13:21:02 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgJRo-0002wK-9h; Mon, 20 Oct 2014 22:20:56 +0200 Received: from mail-ex02.exprod.uio.no ([129.240.52.5]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XgJRn-0003mz-OI; Mon, 20 Oct 2014 22:20:56 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex02.exprod.uio.no (2001:700:100:52::5) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 20 Oct 2014 22:20:55 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Mon, 20 Oct 2014 22:20:54 +0200 From: Runa Barik To: Joe Touch , Youjianjie , "tcpm@ietf.org" Thread-Topic: =?gb2312?B?W3RjcG1dINeqt6I6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh?= =?gb2312?B?ZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93LTAw?= =?gb2312?Q?.txt?= Thread-Index: AQHP7C6yn6URl1adl0qtQLFH/DuYRJw4hSEggACt24CAADgEdA== Date: Mon, 20 Oct 2014 20:20:54 +0000 Message-ID: References: , <544558FD.3090802@isi.edu> In-Reply-To: <544558FD.3090802@isi.edu> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 86 max rcpts/h 6 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1B02B02300AECA1F989AE509028C890DEDB7BF1D X-UiO-SPAM-Test: remote_host: 129.240.52.5 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 22 total 347934 max/h 380 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4hlBe8vL7qpFjTpfjb4l87T5yYw Subject: Re: [tcpm] =?gb2312?b?16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?gb2312?b?ciBkcmFmdC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13aW5k?= =?gb2312?b?b3ctMDAudHh0?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:21:04 -0000 SGkgSi4gVG91Y2gsCgogICAgICAgICAgICBUaGUgd29yayBpbiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10b3VjaC10Y3BtLWF1dG9tYXRpYy1pdy0wMywgcHJvcG9zZXMgYW4gYW4g YWxnb3JpdGhtIGZvcgphdXRvbWF0aW5nIElXLXNpemUgb2YgVENQIGNvbm5lY3Rpb25zLCBiYXNl ZCBvbiB0aGUgc3RhdGlzdGljcyBvZiBJVy1sb3NzZXMgb2YgcHJldmlvdXMgY29ubmVjdGlvbnMu IEl0IHVwZGF0ZXMgdGhlIElXLXNpemUgYmFzZWQgb24gdGhlIG51bWJlciBvZiBsb3NzZXMgb2Jz ZXJ2ZWQgZm9yIHRoZSBJVyBzZWdtZW50cyBpbiB0aGUgcHJldmlvdXMgIHNheSAxMDAwIGNvbm5l Y3Rpb25zLCBzdWNoIHRoYXQgdGhlIElXLXNpemUgaXMgaW5jcmVhc2VkIGlmIHRoZSBmcmFjdGlv biBvZiBsb3NzZXMgaXMgYmVsb3cgYSB0aHJlc2hvbGQsIGFuZCBkZWNyZWFzZWQgb3RoZXJ3aXNl LiBUaGUgcHJvYmxlbSBpcywgaXQgc2V0cyBhIHNpbmdsZSBJVy1zaXplIGZvciBhIGxhcmdlIG51 bWJlciBvZiBjb25zZWN1dGl2ZSBjb25uZWN0aW9ucyBpZiB0aGVzZSBjb25uZWN0aW9ucyBvYnNl cnZlIHNhbWUgbnVtYmVyIHByZXZpb3VzIElXIGxvc3Nlcy4gSSB0aGluayB0aGUgdmFyaWF0aW9u IGluIElXIGZvciBmbG93cyBpcyB2ZXJ5IHNtYWxsLCB3aGljaCBtZWFucyBzdGlsbCB0aGUgY29u Y2VwdCBvZiBhIHNpbmdsZSBjb25zdGFudCBJVyBmb3IgbWFueSBmbG93cy4gCgpSZWdhcmRzLAot IFJ1bmEgQmFyaWsKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJv bTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSm9lIFRvdWNoIDx0 b3VjaEBpc2kuZWR1PgpTZW50OiBNb25kYXksIE9jdG9iZXIgMjAsIDIwMTQgODo0OCBQTQpUbzog WW91amlhbmppZTsgdGNwbUBpZXRmLm9yZwpTdWJqZWN0OiBSZTogW3RjcG1dINeqt6I6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWlu aXRpYWwtd2luZG93LTAwLnR4dAoKVGhlcmUgaGFzIGJlZW4gYSBwcm9wb3NhbCB0byBhdXRvbWF0 ZSB0aGUgSVcgd2hpY2ggd2FzIGRlc2NyaWJlZCBoZXJlOgoKaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtdG91Y2gtdGNwbS1hdXRvbWF0aWMtaXctMDMKCkFuIEFQSSBtaWdodCBpbnRl cmFjdCB3aXRoIHRoYXQgbWVjaGFuaXNtLCBlLmcuLCBjaGFuZ2luZyBwYXJhbWV0ZXJzLgoKSm9l CgoKT24gMTAvMTkvMjAxNCAxMTozMiBQTSwgWW91amlhbmppZSB3cm90ZToKPiBIaSBhbGwsCj4K PiBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBhIG1ldGhvZCB0byBjb25maWd1cmUgVENQJ3MgaW5p dGlhbCBjb25nZXN0aW9uIHdpbmRvdyBieSBhIG5ldyBBUEkuCj4gWW91ciBxdWVzdGlvbnMgYW5k IGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4KPgo+IEJlc3QgUmVnYXJkcywKPiBKaWFuamllCj4K PiAtLS0tLdPKvP7Urbz+LS0tLS0KPiC3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10KPiC3osvNyrG85DogMjAxNMTqMTDUwjIw yNUgMTQ6MjYKPiDK1bz+yMs6IFlvdWppYW5qaWU7IEh1YW5neWlob25nIChSYWNoZWwpOyBIdWFu Z3lpaG9uZyAoUmFjaGVsKTsgWW91amlhbmppZQo+INb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93LTAw LnR4dAo+Cj4KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteW91LXRjcG0tY29uZmlndXJp bmctdGNwLWluaXRpYWwtd2luZG93LTAwLnR4dAo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgSmlhbmppZSBZb3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lgo+ Cj4gTmFtZTogICAgICAgICBkcmFmdC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13 aW5kb3cKPiBSZXZpc2lvbjogICAgIDAwCj4gVGl0bGU6ICAgICAgICAgICAgICAgIENvbmZpZ3Vy aW5nIFRDUCdzIEluaXRpYWwgV2luZG93Cj4gRG9jdW1lbnQgZGF0ZTogICAgICAgIDIwMTQtMTAt MTkKPiBHcm91cDogICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uCj4gUGFnZXM6 ICAgICAgICAgICAgICAgIDgKPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2lu ZG93LTAwLnR4dAo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC15b3UtdGNwbS1jb25maWd1cmluZy10Y3AtaW5pdGlhbC13aW5kb3cvCj4gSHRt bGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdS10Y3BtLWNv bmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMAo+Cj4KPiBBYnN0cmFjdDoKPiAgICBUaGlz IGRvY3VtZW50IGRpc2N1c3NlcyB0aGF0IFRDUCdzIGluaXRpYWwgY29uZ2VzdGlvbiB3aW5kb3cg aXMgbm90IGEKPiAgICBjb25zdGFudCBpbiBkaWZmZXJlbnQgdXNlIGNhc2VzLiAgSXQgcHJvcG9z ZXMgYSBmbGV4aWJsZSBtZXRob2QgdG8KPiAgICBjb25maWd1cmUgdGhlIGluaXRpYWwgd2luZG93 IGluIG9yZGVyIHRvIGtlZXAgdXAgd2l0aCB0aGUgY3VycmVudAo+ICAgIG5ldHdvcmsgc3RhdGUu Cj4KPgo+Cj4KPgo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4KPgo+IFRoZSBJRVRG IFNlY3JldGFyaWF0Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+IHRjcG0gbWFpbGluZyBsaXN0Cj4gdGNwbUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQo+CgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwp0Y3BtIG1haWxpbmcgbGlzdAp0Y3BtQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ== From nobody Mon Oct 20 13:51:45 2014 Return-Path: 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 36AC51ACE14 for ; Mon, 20 Oct 2014 13:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Rtaw5MOCr0jE for ; Mon, 20 Oct 2014 13:51:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB0B1ACE84 for ; Mon, 20 Oct 2014 13:51:41 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9KKouDo013827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 13:50:57 -0700 (PDT) Message-ID: <544575B0.90608@isi.edu> Date: Mon, 20 Oct 2014 13:50:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bob Briscoe References: <3C694E6F4F1EBB43B13CE0A47A0A2E01714236@NDJSMBX103.ndc.nasa.gov> <201410021431.s92EVDnC015019@bagheera.jungle.bt.co.uk> <542D68A8.7020203@isi.edu> <201410021614.s92GEowA015383@bagheera.jungle.bt.co.uk> <542D7C8B.2050401@isi.edu> <201410030057.s930vQAu017004@bagheera.jungle.bt.co.uk> <542DF84E.4020404@isi.edu> <201410031114.s93BE6Mw019580@bagheera.jungle.bt.co.uk> <20141004202431.GA72713@verdi> <5430C9FB.2010000@isi.edu> <20141006013104.GC72713@verdi> <5432CC74.6020107@isi.edu> <201410071037.s97AbXHR006583@bagheera.jungle.bt.co.uk> <5433FFB0.5090205@isi.edu> <201410192243.s9JMhVM1013816@bagheera.jungle.bt.co.uk> In-Reply-To: <201410192243.s9JMhVM1013816@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/yHA-yU6Ja1UOtpjU10UsaAJuR3k Cc: tcpm IETF list Subject: Re: [tcpm] draft-ietf-tcpm-tcp-edo X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:51:43 -0000 On 10/19/2014 3:43 PM, Bob Briscoe wrote: > Joe, ... > A) If we were to write guidelines on middlebox design, I suspect we > would say that a middlebox SHOULD/MUST forward unknown options. I have better guidelines; I'm writing them up for the IAB (which, IMO, dropped the ball in not doing so properly a looong time ago). > B) It is fairly obvious that two TCP stacks either side of a proxy will > sometimes split or coalesce segments: > * If the origin is app-limited so that small segments arrive into a > buffer at the proxy, then the proxy is likely to coalesce them into a > larger segment when it sends them out. > * If a sequence of coalesced segments overflows the MTU, the proxy will > then split the last segment and start the next segment with the remainder. > > So what would you advise this proxy to do? IMO they're performing as a transparent proxy. Transparent may be bad, but the least they can do is correctly implement a proxy - i.e., source and sink options on either side of the connection separately. I don't think the Internet is a monument to "do what you want and we'll accommodate it". There *MUST* be limits. > Not resegment? That's not > easy to implement, because the outgoing side has to somehow remember > where the segment boundaries were when they arrived. > > 'Ideally' the proxy shouldn't intervene uninvited. Then the sender is > talking to the proxy as a proper endpoint, and the proxy is similarly > talking to the receiver. > > However: > * that requires extra complexity configuring the sender with the address > of the appropriate proxy, which changes if the sender is mobile, or > changes to connect via a VPN, etc etc. > * that still greatly slows the deployment of new options. If 10% of > endpoints and 10% of proxies have deployed a new option, the chance of > finding a fully deployed path is 10%*10% = 1%. > > ...this isn't as easy as just banging a fist on the table and shouting > "No!" If you intend on accommodating anything a proxy wants to do, that's what you'll end up doing anyway. ... > Anyway, I don't think I ever said that we need to cater for middleboxes > that resegment AND forward unknown options. So I think you might be > arguing against an invented adversary (chasing phantoms?). I hope so. IMO, as long as we have a middlebox that terminates options on either side we're fine. ... > We have to propose rules that middleboxes can follow, and there must be > no reason why they wouldn't follow the rules. Middleboxes are built by the lazy and/or greedy who want to benefit from the rules everyone *else* plays. It's time to allow them to break and take the heat for their own misbehavior. > That means the rules have > to work in their interest, and allow them to be lazy. I have no intention of making an Internet that runs over the Internet solely to ensure that middlebox vendors have a job. > It is certainly > not realistic to expect these vendors to follow rules that entirely rule > out their business model, no matter how much I don't like their > architecture. Not all business models NEED to succeed, and the it's not clear the Internet CAN support them all. We need to stop acting like accommodating their model isn't damaging the rest of us. Joe From nobody Mon Oct 20 15:59:06 2014 Return-Path: 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 5737E1ACFAA for ; Mon, 20 Oct 2014 15:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PMeDxdKGtC13 for ; Mon, 20 Oct 2014 15:59:03 -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 D3C3E1ACF5E for ; Mon, 20 Oct 2014 15:59:03 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9KMwitg024422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 15:58:44 -0700 (PDT) Message-ID: <544593A4.2090108@isi.edu> Date: Mon, 20 Oct 2014 15:58:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/zLP_GUOlInoT4vpPggj1w-DxDeQ Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 22:59:05 -0000 On 10/17/2014 7:23 PM, David Borman wrote: ... >> - in 3WHS, the SYN-ACK cannot add new options > > The SYN-ACK can contain new options, they just won’t get enabled, > since they weren’t received in the SYN. "Add" was ambiguous; I had intended "offer and enable". Yes, they can be offered but won't be enabled. ... >> - in 4WHS, the SYN-ACK can >> >> In 3WHS, the SYN is where all new options happen and are confirmed using >> a 3WHS. > > Again, both sides propose what options they can support, and they enable > the intersection of what they sent in their SYN, and received in the > other sides SYN or SYN-ACK. There are four messages: X-SYN Y-SYN X-SYN/ACK Y-SYN/ACK Presumably, the intersection will be of the options in the SYNs but there are options that don't discuss the case of receiving a SYN while in SYN-SENT as a separate case. They merely talk about reacting to the SYN/ACK seen. > It is only an optimization that the SYN-ACK > doesn’t need to include options that it already knows will never be enabled > for this connection, since they weren’t received in the SYN. > > Both sides only enable the intersection of options that were both sent > and received in a packet with the SYN bit set. > > Let me make it clearer with the simultaneous open: In that case, both > sides send a SYN packet with some set of options. When they each receive > each others SYN, they both now have the intersection of options both sent > and received in a packet with a SYN, and know what options are enabled. > What’s in the SYN-ACK that they then send is superfluous, both sides > have already determined what options are supported for this connection. I understand your logic but I'm not convinced that all options are defined to work that way. >> If 4WHS adds new options in the SYN-ACK, it needs another message to >> complete a 3WHS based on the options selected for a given connection. >> >> I.e., the client adds new options during SYN-ACK, the server confirms >> what it selects as a subset in the ACK to the client - but the client >> might still not like the subset picked. It needs a message to confirm >> that final choice. > > The final ACK doesn’t have any part of the option negotiation, in either > the 3way or 4way handshake. Again, we'd have to check the definition of every option to ensure that's the case. Strictly, the SYN can offer a set, the SYN/ACK can offer a subset back, and the ACK can turn on a subset of those indicated in the SYN/ACK. I don't know if any option takes advantage of that sequence, though. > Again, any option that is both sent and received in a packet with the > SYN bit set enables the option. Offers the option. Options are offered then confirmed. > With the 4way handshake the client > sends two packets with the SYN bit, so if the server has included > additional options in its SYN-ACK that weren’t received in the SYN, > then the client can enable those options by including them in its > SYN-ACK. The client offers a set of options in the SYN The server responds with a SYN: - does it confirm any of those options yet? - what other options does it send? it needs to send all the options it *can support* because it doesn't know which ones the client wants to enable, but not all those combinations may be desirable by the server The client sends the SYN/ACK: This message is supposed to complete the set selected TCP does support simultaneous open, but not all options are necessarily defined as supporting that. As per above, the server SYN isn't like any other SYN. It doesn't contain the options the server enables for the connection because that's not how servers typically work. It has to contain all the options that COULD be used on a connection, but it's entirely possible there are sets that don't make sense. The server has to have a chance to decide that the final set negotiated isn't what it wanted. It gets that chance when it decides to open a connection or when it responds to the whole set of options offered - but neither happens in this case. Again, I conclude that this is missing at least one more message, if not another entire phase of handshake. Joe From nobody Tue Oct 21 02:58:30 2014 Return-Path: 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 CB60E1A0263 for ; Tue, 21 Oct 2014 02:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4sFn_C3_KzqL for ; Tue, 21 Oct 2014 02:58:19 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAB11A0267 for ; Tue, 21 Oct 2014 02:58:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,761,1406617200"; d="scan'208";a="204792660" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx12-out.netapp.com with ESMTP; 21 Oct 2014 02:58:18 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 21 Oct 2014 02:57:47 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Tue, 21 Oct 2014 02:57:47 -0700 From: "Zimmermann, Alexander" To: Pasi Sarolahti Thread-Topic: [tcpm] draft-zimmermann-tcpm-undeployed Thread-Index: AQHP7FpSMgoM+xcoCU2hh5FlS7V14Zw6x7UA Date: Tue, 21 Oct 2014 09:57:47 +0000 Message-ID: <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> In-Reply-To: <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wy-5QgD3YqKySIavMQrmrCo782s Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 09:58:23 -0000 > Am 20.10.2014 um 13:38 schrieb Pasi Sarolahti : >=20 > On 20 Oct 2014, at 13:09, Zimmermann, Alexander wrote: >=20 >> at the IETF 90 we got some feedback from Yoshifumi and Gorry no the draf= t (see minutes). We incorporated those feedback in version 01. From our poi= nt of view the draft is ready. I would like to know how we proceed w/ the d= raft? I don=92t think that we need to discuss the draft again in Honolulu. >=20 > Just wanted to check one thing: isn=92t TCPMUX supported by [x]inetd impl= ementations? It=92s probably not much used, but there seem to be deployed i= mplementations, so perhaps it isn't correct to call it obsolete? Any opinio= ns? Making something as obsolete !=3D not deployed in implementation Please rake a look at https://www.ietf.org/iesg/statement/designating-rfcs-= as-historic.html =84Moving a document to "Historic" status requires a specific IETF-=ADwide Last Call and a formal action of the IESG.=20 * A document is obsolete when there is a newer version that replaces it. RF= C 821 is obsoleted by RFC 2821, which is, in turn, obsoleted by RFC 5321. The tec= hnology that RFC 821 describes =97 SMTP =97 is still current technology, but the do= cumentation of it in RFC 821 is obsolete.=20 * A document is labelled Historic when what it describes is no longer consi= dered current: no longer recommended for use.=93 The latter point is exactly what we would like to express: no longer recomm= ended for use >=20 > Also, RFC 6013 strikes as quite recent for a =93Historic=94 document, alt= hough I fully agree with its description in the roadmap. The specification (RFC 6013) is not getting any better if we wait longer. There is no implementation in the wild available, it doesn=92t follow RFC 6= 994 ,=85 > (I=92m not against the change, just generally wondering why an independen= t stream RFC is approved with one status, Ask IESG. AFAIR Wes was the AD at this time ;-) Alex > if it is going to be changed to Historic soon after) >=20 > - Pasi >=20 From nobody Tue Oct 21 04:10:53 2014 Return-Path: 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 4CA821A1A27 for ; Tue, 21 Oct 2014 04:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 lB5r0TsRUs0G for ; Tue, 21 Oct 2014 04:10:40 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.197]) by ietfa.amsl.com (Postfix) with ESMTP id 02F171A1A38 for ; Tue, 21 Oct 2014 04:09:34 -0700 (PDT) Received: from [130.233.145.212] (130.233.145.212) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 543C16C9009E3097; Tue, 21 Oct 2014 14:09:31 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> Date: Tue, 21 Oct 2014 14:09:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/VSwq6Hb5huBtQRZaNUmMaJ0yMbI Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:10:50 -0000 On 21 Oct 2014, at 12:57, Zimmermann, Alexander = wrote: >=20 >> Am 20.10.2014 um 13:38 schrieb Pasi Sarolahti = : >>=20 >> On 20 Oct 2014, at 13:09, Zimmermann, Alexander = wrote: >>=20 >>> at the IETF 90 we got some feedback from Yoshifumi and Gorry no the = draft (see minutes). We incorporated those feedback in version 01. =46rom = our point of view the draft is ready. I would like to know how we = proceed w/ the draft? I don=92t think that we need to discuss the draft = again in Honolulu. >>=20 >> Just wanted to check one thing: isn=92t TCPMUX supported by [x]inetd = implementations? It=92s probably not much used, but there seem to be = deployed implementations, so perhaps it isn't correct to call it = obsolete? Any opinions? >=20 > Making something as obsolete !=3D not deployed in implementation Yep. But the title is "Moving Undeployed TCP Extensions to Historic=85=94 = :-) > * A document is labelled Historic when what it describes is no longer = considered current: > no longer recommended for use.=93 >=20 > The latter point is exactly what we would like to express: no longer = recommended for use So why is it no longer recommended? The IESG statement also calls for = explanation for the transition. rfc4614bis explains the case for the = other documents pretty well, but the reasons for obsoleting TCPMUX are = not given there. (it might not harm if the important explaining = sentences from rfc4641bis would be shortly repeated also here for each = document) >> Also, RFC 6013 strikes as quite recent for a =93Historic=94 document, = although I fully agree with its description in the roadmap. >=20 > The specification (RFC 6013) is not getting any better if we wait = longer. > There is no implementation in the wild available, it doesn=92t follow = RFC 6994 ,=85 Right, it shouldn=92t be hard to argue why the transition needs to be = made. (but I still think it would help further evaluation steps if short = reasoning was provided here) - Pasi From nobody Tue Oct 21 04:47:45 2014 Return-Path: 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 623CF1A1B00 for ; Tue, 21 Oct 2014 04:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vKzlU3Z58VWB for ; Tue, 21 Oct 2014 04:47:42 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F24F1A1AFA for ; Tue, 21 Oct 2014 04:47:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,762,1406617200"; d="scan'208";a="204816001" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx12-out.netapp.com with ESMTP; 21 Oct 2014 04:47:42 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 21 Oct 2014 04:47:11 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Tue, 21 Oct 2014 04:47:10 -0700 From: "Zimmermann, Alexander" To: Pasi Sarolahti Thread-Topic: [tcpm] draft-zimmermann-tcpm-undeployed Thread-Index: AQHP7FpSMgoM+xcoCU2hh5FlS7V14Zw6x7UAgAAT44CAAAquAA== Date: Tue, 21 Oct 2014 11:47:09 +0000 Message-ID: References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <28C1434990637B4AB21DDD1117866408@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/E0hZLDOtNyAJP1nEsydxlSpe8yQ Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 11:47:44 -0000 > Am 21.10.2014 um 13:09 schrieb Pasi Sarolahti : >=20 >=20 > On 21 Oct 2014, at 12:57, Zimmermann, Alexander wrote: >=20 >>=20 >>> Am 20.10.2014 um 13:38 schrieb Pasi Sarolahti : >>>=20 >>> On 20 Oct 2014, at 13:09, Zimmermann, Alexander wrote: >>>=20 >>>> at the IETF 90 we got some feedback from Yoshifumi and Gorry no the dr= aft (see minutes). We incorporated those feedback in version 01. From our p= oint of view the draft is ready. I would like to know how we proceed w/ the= draft? I don=92t think that we need to discuss the draft again in Honolulu= . >>>=20 >>> Just wanted to check one thing: isn=92t TCPMUX supported by [x]inetd im= plementations? It=92s probably not much used, but there seem to be deployed= implementations, so perhaps it isn't correct to call it obsolete? Any opin= ions? >>=20 >> Making something as obsolete !=3D not deployed in implementation >=20 > Yep. But the title is =84Moving Undeployed TCP Extensions to Historic=85= =94 :-) OK, we should fix that :-) >=20 >> * A document is labelled Historic when what it describes is no longer co= nsidered current: >> no longer recommended for use.=93 >>=20 >> The latter point is exactly what we would like to express: no longer rec= ommended for use >=20 > So why is it no longer recommended? The IESG statement also calls for exp= lanation for the transition. See for example this thread: http://www.ietf.org/mail-archive/web/ietf/curr= ent/msg81410.html (or http://marc.info/?t=3D137611379100002&r=3D1&w=3D2) Wes: =84There are probably security issues=93 Joe: =84There are semantics issues to; see draft-touch-tcp-portnames-00 fo= r information=93 Bob Braden: =84Indeed, TCPMUX is quite historic=85 it represents a Road No= t Taken=93 Another source is: draft-touch-tcpm-sno-02.txt If Joe, Wes or Bob think now that we should not obsolete TCPMUX, fine by me= . I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the communi= ty) opinion.=20 > rfc4614bis explains the case for the other documents pretty well, but the= reasons for obsoleting TCPMUX are not given there. (it might not harm if t= he important explaining sentences from rfc4641bis would be shortly repeated= also here for each document) I can do that. NP. Personally, I do not want to submit the draft as an individual draft. Basic= ally due to the fact that today nobody knows how we can obsolete an RFC which comes out of the i= ndependent track. Could we start a call of adoption on the draft? The stuff we discuss right = now are quite minor and easy to fix. I do not see a showstopper here >=20 >>> Also, RFC 6013 strikes as quite recent for a =93Historic=94 document, a= lthough I fully agree with its description in the roadmap. >>=20 >> The specification (RFC 6013) is not getting any better if we wait longer= . >> There is no implementation in the wild available, it doesn=92t follow RF= C 6994 ,=85 >=20 > Right, it shouldn=92t be hard to argue why the transition needs to be mad= e. (but I still think it would help further evaluation steps if short reaso= ning was provided here) Be concrete :-) What do you have in mind? Alex =20 >=20 > - Pasi >=20 From nobody Tue Oct 21 06:19:48 2014 Return-Path: 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 2F3FD1A1B85 for ; Tue, 21 Oct 2014 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.909 X-Spam-Level: *** X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 QaC_Wgr7MRnC for ; Tue, 21 Oct 2014 06:19:45 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E5F1A1B8C for ; Tue, 21 Oct 2014 06:19:44 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so993275lab.21 for ; Tue, 21 Oct 2014 06:19:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UWMnaHSim/hwE5vLxr2PruUkAZ882OzBvLELnOidZRc=; b=e5huqUYagKhd7Y/z96G+lrbVfIBd+VVFJt7b4F8OXNedsSUkkYM3KkjsFD5yGNzUK4 5C9ARTDj7I0YrDANI0SWvu5/PkhppAe+6QP8fEtFDuqd5WqGqMhBrwC+2HRvzRYCHhav jXG13m51by3FaDcT+UUUVn6g57mE1u0s/FX/1u8+/R4/3NyO3svIC19gBZ0gaCUPWGdi 1smDFov67NtxuFne12T76CaJ//tL6pgToYQqYPQaZGQTRFl9Av9JOzMBXzKhY/0ktffj d4TtmW81TqjyeBgNOOec/9j9p3fsRI6BBz8KnydO/fQWzRpnEzovvO/M0NzzP22Kg9Bb kG4w== X-Gm-Message-State: ALoCoQkPf5kBkd3xBOuvS7ehqpSjvG8k3ilutpc9eVcjVOMefxAFo/Iyc1VUFaquU8ooYk91K6ys MIME-Version: 1.0 X-Received: by 10.152.88.105 with SMTP id bf9mr34986125lab.30.1413897577784; Tue, 21 Oct 2014 06:19:37 -0700 (PDT) Received: by 10.25.21.207 with HTTP; Tue, 21 Oct 2014 06:19:37 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: References: Date: Tue, 21 Oct 2014 15:19:37 +0200 Message-ID: From: Hagen Paul Pfeifer To: Michael Welzl , Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hupnGOFbZciKubJJT4l7Dd0HnRk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:19:47 -0000 On 20 October 2014 21:19, Michael Welzl wrote: > Hi Hagen, Hi Michael > what if 10 is used as a default (like now) and an upper limit? I am not a friend of any static stack global or user configured IW - let me explain this. Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say that the IW should increase "savely" over the years. But the IW has nothing to do with time! It has something to do with available bandwidth (and delay, but skip this for now). The problem is that the bandwidth do not increase over time for *all links*. The bandwidth is not equal everywhere to every time for everyone. There are links out there with path characteristics from 1990 and older - but the clients use modern operating systems and we must make sure that TCP will operate in this environment too. I participate at the Freifunk Mesh in Munich [1]. A mesh network providing internet connectivity for the masses. Often the link quality is really bad with a lot of MAC layer retransmissions resulting in low bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP on "classic wifi links". Now assume a setsockopt() IW of 50 - this will lead to congested queues, dropped packets and interflow fairness problems and probably non-operative links because the application will re-send packets again and gain. Question: what is the right IW for a given application? -> it is not application specific - it is link specific! But we have already a solution to this: the TCP Control Block (RFC 2140) (to mention the author of the RFC: Joe Touch! ;)! The control block is already implemented in Linux network stack and cache CW parameters (amongst other things). This is a far better approach because it starts conservative in the initial probing phase (3/4 segments as specific) and memorize window parameters on a path basis (yes, another IW misbelieve: the available bandwidth (IW) is not a global value, it change over path and time characteristics). This automated approach is the best you can get for your money - there is not need for static defines in your kernel. And yes, Joe's I-D might be a good starting point to even tune the IW even more. Last week I met Jerry Chu (the author of IW10) at the LPC14 and he told me that some guys start pushing on IW10 - I was hoping that this happens not so immediately! ;-) Hagen [1] https://en.wikipedia.org/wiki/Freifunk From nobody Tue Oct 21 06:32:38 2014 Return-Path: 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 85CA61A3BA7 for ; Tue, 21 Oct 2014 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 rO-yQJZMVcBn for ; Tue, 21 Oct 2014 06:32:34 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id 09DAA1A1C04 for ; Tue, 21 Oct 2014 06:32:34 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.212) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5419499102E8C9E4; Tue, 21 Oct 2014 16:32:31 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: Date: Tue, 21 Oct 2014 16:32:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RNrCEXLapxzxEKCjY7ZQu65BU3E Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] Adopting draft-zimmermann-tcpm-undeployed? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:32:36 -0000 (Note: this is response to Alex=92 mail, but I changed the topic, = because there is an important question below) On 21 Oct 2014, at 14:47, Zimmermann, Alexander = wrote: >> So why is it no longer recommended? The IESG statement also calls for = explanation for the transition. >=20 > See for example this thread: = http://www.ietf.org/mail-archive/web/ietf/current/msg81410.html > (or http://marc.info/?t=3D137611379100002&r=3D1&w=3D2) >=20 > Wes: =84There are probably security issues=93 > Joe: =84There are semantics issues to; see = draft-touch-tcp-portnames-00 for information=93 > Bob Braden: =84Indeed, TCPMUX is quite historic=85 it represents = a Road Not Taken=93 >=20 > Another source is: draft-touch-tcpm-sno-02.txt >=20 > If Joe, Wes or Bob think now that we should not obsolete TCPMUX, fine = by me. > I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the = community) > opinion.=20 Great, this is basically what I was looking for. So why not shortly = summarize the security and semantics issues in the draft, to make things = clear? > Personally, I do not want to submit the draft as an individual draft. = Basically due to the fact > that today nobody knows how we can obsolete an RFC which comes out of = the independent track. > Could we start a call of adoption on the draft? The stuff we discuss = right now are quite minor > and easy to fix. I do not see a showstopper here Yes, I think we should be able to take this through tcpm fairly quickly, = but according to the normal procedure. So the plan would be that unless = anyone objects within next couple of weeks, we will adopt this as TCPM = document, and will start a WGLC soon after. (This is not to discourage = further comments, so please take a look and send comments as usual =97 = although currently there is not much text to comment on=85 :-) We don=92t need presentation slot in the next meeting, unless you want = to, but let=92s shortly check the status in the early part of the = meeting (no slides required). So, any opinions for or against adopting this draft as outlined above? >>> The specification (RFC 6013) is not getting any better if we wait = longer. >>> There is no implementation in the wild available, it doesn=92t = follow RFC 6994 ,=85 >>=20 >> Right, it shouldn=92t be hard to argue why the transition needs to be = made. (but I still think it would help further evaluation steps if short = reasoning was provided here) >=20 > Be concrete :-) What do you have in mind? As you say, RFC 6994 specifies how experimental options should be used, = so it supersedes the usage in RFC 6013. We also have ongoing work on = extending option space that will likely differ from what RFC 6013 has = (but we are not quite there yet). The extension mechanism probably also = has issues with middleboxes, as recently discussed. (roadmap says that = there is no wide deployment, but RFC 6013 is Experimental, so I don=92t = think wide deployment is even expected. Although probably there is no = ongoing experiment either.) - Pasi From nobody Tue Oct 21 06:38:43 2014 Return-Path: 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 BF7D21A6F11 for ; Tue, 21 Oct 2014 06:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 PyJZlwf9yZ2g for ; Tue, 21 Oct 2014 06:38:39 -0700 (PDT) Received: from atl4mhob02.myregisteredsite.com (atl4mhob02.myregisteredsite.com [209.17.115.40]) by ietfa.amsl.com (Postfix) with ESMTP id 07BFE1A6F15 for ; Tue, 21 Oct 2014 06:38:38 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s9LDcaBV025988 for ; Tue, 21 Oct 2014 09:38:36 -0400 Received: (qmail 26305 invoked by uid 0); 21 Oct 2014 13:38:36 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 21 Oct 2014 13:38:36 -0000 Message-ID: <544661D7.7040409@mti-systems.com> Date: Tue, 21 Oct 2014 09:38:31 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" , Pasi Sarolahti References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> In-Reply-To: <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fmbQ-LaUNcYW_lf2RYjagVarQ4Y Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:38:41 -0000 On 10/21/2014 5:57 AM, Zimmermann, Alexander wrote: >> (I’m not against the change, just generally wondering why an >> independent stream RFC is approved with one status, > > Ask IESG. AFAIR Wes was the AD at this time ;-) No, that was Lars and David :). While there is no burning need to reclassify it, that I can see, I do think it's sensible to do in light of other progress that this working group has made with TFO. As I understand it, TCPCT was largely driven by DNSSEC and replacing T/TCP (1644), whereas TFO is more web-inspired, but also can be used to support T/TCP-like use by other applications and has relatively more "rough consensus and running code" behind it. -- Wes Eddy MTI Systems From nobody Tue Oct 21 06:45:44 2014 Return-Path: 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 168941A6F30 for ; Tue, 21 Oct 2014 06:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tFs0H3jKQDam for ; Tue, 21 Oct 2014 06:45:24 -0700 (PDT) Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 853521A6F32 for ; Tue, 21 Oct 2014 06:45:18 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s9LDjGTl012138 for ; Tue, 21 Oct 2014 09:45:16 -0400 Received: (qmail 26240 invoked by uid 0); 21 Oct 2014 13:45:16 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 21 Oct 2014 13:45:16 -0000 Message-ID: <54466367.5030502@mti-systems.com> Date: Tue, 21 Oct 2014 09:45:11 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" , Pasi Sarolahti References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XwtxRS7FHnWv6kOgBSIIwEP_xbU Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:45:27 -0000 On 10/21/2014 7:47 AM, Zimmermann, Alexander wrote: > See for example this thread: http://www.ietf.org/mail-archive/web/ietf/current/msg81410.html > (or http://marc.info/?t=137611379100002&r=1&w=2) > > Wes: „There are probably security issues“ > Joe: „There are semantics issues to; see draft-touch-tcp-portnames-00 for information“ > Bob Braden: „Indeed, TCPMUX is quite historic… it represents a Road Not Taken“ > > Another source is: draft-touch-tcpm-sno-02.txt > > If Joe, Wes or Bob think now that we should not obsolete TCPMUX, fine by me. > I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community) > opinion. Looking at: 1) the IETF mailing list threads on it 2) the handful of issues that it presents in the modern day 3) that it isn't "on by default" in widely used code, and there don't seem to be many/any strong use cases or advocations for it on the web It seems to me that it should be historic. There are better ways of doing the same thing. -- Wes Eddy MTI Systems From nobody Tue Oct 21 07:13:14 2014 Return-Path: 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 B44571A6F3E for ; Tue, 21 Oct 2014 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 zw8aPfxXWb0c for ; Tue, 21 Oct 2014 07:13:01 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D961A6EE5 for ; Tue, 21 Oct 2014 07:13:01 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgaBH-0007Oj-IY; Tue, 21 Oct 2014 16:12:59 +0200 Received: from mail-ex12.exprod.uio.no ([129.240.120.74]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XgaBG-00038H-U5; Tue, 21 Oct 2014 16:12:59 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex12.exprod.uio.no (2001:700:100:120::74) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 16:12:55 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 16:12:55 +0200 From: Runa Barik To: Hagen Paul Pfeifer , Michael Welzl , Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAArM9Q= Date: Tue, 21 Oct 2014 14:12:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 94 max rcpts/h 6 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B2C4C5D54C66680201D55521F68A28A5414FFCBF X-UiO-SPAM-Test: remote_host: 129.240.120.74 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 49 total 320476 max/h 451 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-D6kCccfefY8WABU1wc8qmTuzSk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:13:04 -0000 Hi all,=0A= =0A= Inline comments,=0A= ________________________________________=0A= From: tcpm on behalf of Hagen Paul Pfeifer =0A= Sent: Tuesday, October 21, 2014 3:19 PM=0A= To: Michael Welzl; Joe Touch=0A= Cc: tcpm@ietf.org=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= On 20 October 2014 21:19, Michael Welzl wrote:=0A= > Hi Hagen,=0A= =0A= Hi Michael=0A= =0A= > what if 10 is used as a default (like now) and an upper limit?=0A= =0A= I am not a friend of any static stack global or user configured IW -=0A= let me explain this.=0A= =0A= Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say=0A= that the IW should increase "savely" over the years. But the IW has=0A= nothing to do with time! It has something to do with available=0A= bandwidth (and delay, but skip this for now). The problem is that the=0A= bandwidth do not increase over time for *all links*. =0A= =0A= There was a proposal, http://tools.ietf.org/html/draft-allman-tcpm-bump-ini= tcwnd-00;=0A= in this, IW can be set over time. And the reason considers network safety, = and performance improvement due to an increase in network capacity. I beli= eve IW value depends on available bandwidth; it also depends more on flow c= haracteristics in the Internet what I observed in my work during master the= sis. Large flows (flows with large in data-size) stay for a long time in th= e Internet; however, small flows want to leave the Internet as soon as poss= ible. Why not to give them chance to finish early. Moreover, we observed sm= all flows get more benefit compared to large flows, having a larger IW. Th= is makes IW dependent on flow characteristics. It may be, the available ban= dwidth is enough to accommodate for such change. Till now, I did not consid= er network-state in relation to setting IW, but we need to consider. =0A= =0A= The bandwidth is=0A= not equal everywhere to every time for everyone. There are links out=0A= there with path characteristics from 1990 and older - but the clients=0A= use modern operating systems and we must make sure that TCP will=0A= operate in this environment too.=0A= =0A= I participate at the Freifunk Mesh in Munich [1]. A mesh network=0A= providing internet connectivity for the masses. Often the link quality=0A= is really bad with a lot of MAC layer retransmissions resulting in low=0A= bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP=0A= on "classic wifi links".=0A= =0A= Now assume a setsockopt() IW of 50 - this will lead to congested=0A= queues, dropped packets and interflow fairness problems and probably=0A= non-operative links because the application will re-send packets again=0A= and gain. Question: what is the right IW for a given application? ->=0A= it is not application specific - it is link specific!=0A= =0A= But we have already a solution to this: the TCP Control Block (RFC=0A= 2140) (to mention the author of the RFC: Joe Touch! ;)!=0A= =0A= The control block is already implemented in Linux network stack and=0A= cache CW parameters (amongst other things). This is a far better=0A= approach because it starts conservative in the initial probing phase=0A= (3/4 segments as specific) and memorize window parameters on a path=0A= basis (yes, another IW misbelieve: the available bandwidth (IW) is not=0A= a global value, it change over path and time characteristics). This=0A= automated approach is the best you can get for your money - there is=0A= not need for static defines in your kernel. And yes, Joe's I-D might=0A= be a good starting point to even tune the IW even more.=0A= =0A= Last week I met Jerry Chu (the author of IW10) at the LPC14 and he=0A= told me that some guys start pushing on IW10 - I was hoping that this=0A= happens not so immediately! ;-)=0A= =0A= Hagen=0A= =0A= =0A= [1] https://en.wikipedia.org/wiki/Freifunk=0A= =0A= =0A= All I say, a constant IW may not be a good option. If we can understand the= network during the handshaking, we can get better performance.=0A= =0A= Regards,=0A= - Runa Barik=0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm= From nobody Tue Oct 21 07:27:26 2014 Return-Path: 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 D9C2D1A6F8E for ; Tue, 21 Oct 2014 07:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.879 X-Spam-Level: X-Spam-Status: No, score=0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 APSSwka6R2JQ for ; Tue, 21 Oct 2014 07:27:23 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF63F1A6F5D for ; Tue, 21 Oct 2014 07:27:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgaPB-0001bR-9j for tcpm@ietf.org; Tue, 21 Oct 2014 16:27:21 +0200 Received: from mail-ex13.exprod.uio.no ([129.240.120.75]) by mail-mx4.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XgaPA-0002FE-MV for tcpm@ietf.org; Tue, 21 Oct 2014 16:27:21 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex13.exprod.uio.no (2001:700:100:120::75) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 16:27:20 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 16:27:19 +0200 From: Runa Barik To: "tcpm@ietf.org" Thread-Topic: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7C6yn6URl1adl0qtQLFH/DuYRJw4hSEggAAvm5WAABaK1oAB0eMj Date: Tue, 21 Oct 2014 14:27:19 +0000 Message-ID: References: , <8b40056997754129b96351e867d2e0c9@mail-ex12.exprod.uio.no>, <4d2c316f002248ca91fcaa8d968d6a1b@mail-ex12.exprod.uio.no> In-Reply-To: <4d2c316f002248ca91fcaa8d968d6a1b@mail-ex12.exprod.uio.no> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 95 max rcpts/h 6 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2C52D2A5551F9C1CC53A6C24200D511E7075EE3E X-UiO-SPAM-Test: remote_host: 129.240.120.75 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 91 total 351037 max/h 493 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/f6YtbNeWCEDXVFv5aAFM8pFCNok Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:27:25 -0000 SGkgYWxsLAoKICBJIHdvdWxkIHN1Z2dlc3QgdG8gbG9vayBhdCB0aGUgZm9sbG93aW5nIHBhcGVy cyBJIHdvcmtlZCByZWdhcmRpbmcgVENQIElXLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCkZyb206IFJ1bmEgQmFyaWsKU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAy MDE0IDEyOjQxIFBNClRvOiBZb3VqaWFuamllOyB0Y3BtQGlldGYub3JnCkNjOiB0YWdAaWl0bWFu ZGkuYWMuaW47IGRpdmFrYXJhbmRAaTJyLmEtc3Rhci5lZHUuc2cKU3ViamVjdDogUkU6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWlu aXRpYWwtd2luZG93LTAwLnR4dAoKSGkgYWxsLAoKIEkgZm9yZ290IHRvIG1lbnRpb24gdGhlIHB1 YmxpY2F0aW9ucyBvbiB0aGlzIHdvcmsuCiAxLiBodHRwOi8vbGluay5zcHJpbmdlci5jb20vY2hh cHRlci8xMC4xMDA3JTJGOTc4LTMtNjQyLTMwNjMwLTNfMjUKMi4gIGh0dHA6Ly9pZWVleHBsb3Jl LmllZWUub3JnL3hwbHMvYWJzX2FsbC5qc3A/YXJudW1iZXI9Njc2MTI4NCZ0YWc9MQozLiBodHRw Oi8vd3d3Lm5ldHdvcmstb2YtdGhlLWZ1dHVyZS5vcmcKCldlIGFyZSBhYm91dCB0byBzdWJtaXQg YSBwYXBlciBgYENoYXJhY3Rlcml6aW5nIHRoZSBlZmZlY3RzIG9mIFRDUCBJbml0aWFsIFdpbmRv dyIuCgpSZWdhcmRzLAotIFJ1bmEgQmFyaWsKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBSdW5hIEJhcmlrIDxydW5hYmtAaWZpLnVpby5ubz4KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIw LCAyMDE0IDExOjQxIEFNClRvOiBZb3VqaWFuamllOyB0Y3BtQGlldGYub3JnCkNjOiB0YWdAaWl0 bWFuZGkuYWMuaW47IGRpdmFrYXJhbmRAaTJyLmEtc3Rhci5lZHUuc2cKU3ViamVjdDogUmU6IFt0 Y3BtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3Vy aW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMC50eHQKCkhpIGFsbCwKCkZpcnN0LCBJIGFwcHJlY2lh dGUgdGhlIGF1dGhvcnMgc3VibWl0dGluZyBhIGRyYWZ0IG9uIHRoaXMgd29yay4gSW4gdGhpcyBk cmFmdCwgVENQIEluaXRpYWwgV2luZG93IChJVykgaXMgY29tcHV0ZWQgYmFzZWQgb24gdGhlIHNp emUgb2YgdGhlIHJlc291cmNlcywgc2F5IGZsb3ctc2l6ZS4gSG93ZXZlciwgaXQgaXMgbW9yZSBp bXBvcnRhbnQgdG8gY29uc2lkZXIgd2hlbiB0aGUgYXBwbGljYXRpb24gZG9lcyBub3Qga25vdyB0 aGUgc2l6ZSBpbiBhZHZhbmNlLiBBbmQgdGhlIGF1dGhvcnMgc2V0IHRoZSBJVyB1c2luZyBzb2Nr ZXQgb3B0aW9ucy4KCkkgd29ya2VkIG9uIHRoZSBwcm9ibGVtIHJlbGF0ZWQgdG8gZGVjaWRpbmcg dGhlIFRDUCBJbml0aWFsIFdpbmRvdyAoSVcpIGluIG15IE1hc3RlciB0aGVzaXMgYGAgSW1wcm92 aW5nIExhdGVuY3kgb2YgTWljZSBpbiB0aGUgSW50ZXJuZXQ6IEFuIEFwcHJvYWNoIEJhc2VkIG9u IFRDUCBJbml0aWFsIFdpbmRvdyIgKHByb2JsZW0gZm9jdXMgc3RhcnRlZCBpbiAyMDExKSB1bmRl ciBEci4gRGluaWwgTW9uIERpdmFrYXJhbiBpbiBJSVQgTWFuZGksIEluZGlhLiBXZSBjb25jbHVk ZWQgdGhhdCBhIGNvbnN0YW50IHZhbHVlIG9mIElXIGlzIG5vdCBhcHByb3ByaWF0ZSBib3RoIGZy b20gU2ltdWxhdGlvbnMsIGFuZCBBbmFseXRpY2FsIHRlY2gsIGFuZCB1bmRlcnN0b29kIHRoYXQg SVcgY2FuIGJlIGEgZnVuY3Rpb24gb2YgcmVzb3VyY2VzIGluIHNlbmRlci1zaWRlLCBhbmQgbmV0 d29yayBzdGF0ZS4gRm9yIHNpbXBsaWNpdHksIHdlIGNvbnNpZGVyZWQgSVcgYXMgYSBmdW5jdGlv biAgb2YgZmxvdy1zaXplLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGFwZXJzIGFscmVhZHkgcHVi bGlzaGVkIGluIFdXSUMnMTIsIExDTicxMywgTm9GJzE0IChhY2NlcHRlZCBmb3IgcHVibGljYXRp b24pLiBXZSBhbHNvIGltcGxlbWVudGVkIGFuIHVzZXIgbGlicmFyeSwgYW5kIGluc2lkZSBMaW51 eCBrZXJuZWwsIGFuZCB0aGVuIGV4cGVyaW1lbnRlZCBvbiBhIHJlYWwgdGVzdGJlZCBuZXR3b3Jr LiBUaGUgbmljZSB0aGluZyBhYm91dCB0aGlzIHdvcmsgaXMgdGhhdCwgZXZlbiBub3Qga25vd2lu ZyAgdGhlIG5ldHdvcmsgc3RhdGUsIHRoZSBmbG93LXNpemUgYmFzZWQgSVcgZnVuY3Rpb24gd29y a3Mgd2VsbCBpbiB2YXJpb3VzIHNjZW5hcmlvcy4KClRoZXJlIGFyZSB2YXJpb3VzIGlkZWFzIHRo YXQgY2FuIGRvbmUgZm9yIGNvbXB1dGluZyBJVy4gVGhlc2UgY2FuIGJlOgoKIDEuIEJhc2VkIG9u IHRoZSBudW1iZXIgb2YgY29ubmVjdGlvbnMgdGhhdCBmYWNlcyBpbiBJVyBsb3NzIGluIHRoZSBw cmV2aW91cyBSVFQsIGZvciBjb21wdXRpbmcgdGhlIElXIGZvciBuZXcgY29ubmVjdGlvbjsKMi4g QmFzZWQgb24gdGhlIG51bWJlciBvZiBwcmV2aW91cyBjb25uZWN0aW9ucyAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRvdWNoLXRjcG0tYXV0b21hdGljLWl3LTAzKSwgYW5kIElX IGxvc3M7CjMuIEJhc2VkIG9uIGZsb3cgY2hhcmFjdGVyaXN0aWNzLgoKSSB0aGluayB0aGlzIGlz IGEgbmljZSB3b3JrIHRvIGNvbnNpZGVyIGZ1cnRoZXIsIGFuZCBJIGNhbiBjb250cmlidXRlIG1v cmUgb24gdGhpcy4KClJlZ2FyZHMsCiAtIFJ1bmEgQmFyaWsKICAgRGVwYXJ0bWVudCBvZiBJbmZv cm1hdGljcwogIFVpTywgT3NsbywgTm9yd2F5LgoKCgoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBZb3VqaWFuamllIDx5b3VqaWFuamllQGh1YXdlaS5jb20+ClNlbnQ6IE1vbmRheSwg T2N0b2JlciAyMCwgMjAxNCA4OjMyIEFNClRvOiB0Y3BtQGlldGYub3JnClN1YmplY3Q6IFt0Y3Bt XSDXqreiOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlvdS10Y3BtLWNvbmZp Z3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMC50eHQKCkhpIGFsbCwKClRoaXMgZG9jdW1lbnQg ZGlzY3Vzc2VzIGEgbWV0aG9kIHRvIGNvbmZpZ3VyZSBUQ1AncyBpbml0aWFsIGNvbmdlc3Rpb24g d2luZG93IGJ5IGEgbmV3IEFQSS4KWW91ciBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSBhcHBy ZWNpYXRlZC4KCkJlc3QgUmVnYXJkcywKSmlhbmppZQoKLS0tLS3Tyrz+1K28/i0tLS0tCreivP7I yzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXQq3osvNyrG85DogMjAxNMTqMTDUwjIwyNUgMTQ6MjYKytW8/sjLOiBZb3VqaWFuamllOyBI dWFuZ3lpaG9uZyAoUmFjaGVsKTsgSHVhbmd5aWhvbmcgKFJhY2hlbCk7IFlvdWppYW5qaWUK1vfM 4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15b3UtdGNwbS1jb25maWd1cmlu Zy10Y3AtaW5pdGlhbC13aW5kb3ctMDAudHh0CgoKQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMC50eHQKaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWFuamllIFlvdSBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuCgpOYW1lOiAgICAgICAgICAgZHJhZnQteW91LXRjcG0tY29uZmlndXJp bmctdGNwLWluaXRpYWwtd2luZG93ClJldmlzaW9uOiAgICAgICAwMApUaXRsZTogICAgICAgICAg Q29uZmlndXJpbmcgVENQJ3MgSW5pdGlhbCBXaW5kb3cKRG9jdW1lbnQgZGF0ZTogIDIwMTQtMTAt MTkKR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbgpQYWdlczogICAgICAgICAg OApVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93LTAwLnR4dApTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteW91LXRjcG0t Y29uZmlndXJpbmctdGNwLWluaXRpYWwtd2luZG93LwpIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwt d2luZG93LTAwCgoKQWJzdHJhY3Q6CiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoYXQgVENQ J3MgaW5pdGlhbCBjb25nZXN0aW9uIHdpbmRvdyBpcyBub3QgYQogICBjb25zdGFudCBpbiBkaWZm ZXJlbnQgdXNlIGNhc2VzLiAgSXQgcHJvcG9zZXMgYSBmbGV4aWJsZSBtZXRob2QgdG8KICAgY29u ZmlndXJlIHRoZSBpbml0aWFsIHdpbmRvdyBpbiBvcmRlciB0byBrZWVwIHVwIHdpdGggdGhlIGN1 cnJlbnQKICAgbmV0d29yayBzdGF0ZS4KCgoKCgpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuCgpUaGUgSUVURiBTZWNyZXRhcmlhdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNwbUBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNwbUBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0K From nobody Tue Oct 21 07:30:42 2014 Return-Path: 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 DC6841A6F45 for ; Tue, 21 Oct 2014 07:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 U6ywAecgf9qZ for ; Tue, 21 Oct 2014 07:30:32 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D641A1B74 for ; Tue, 21 Oct 2014 07:30:32 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgaSE-00027Q-Hk; Tue, 21 Oct 2014 16:30:30 +0200 Received: from [193.157.237.186] by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user runabk@uio.no (Exim 4.80) (envelope-from ) id 1XgaSD-00037C-Tu; Tue, 21 Oct 2014 16:30:30 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Runa Barik In-Reply-To: Date: Tue, 21 Oct 2014 16:30:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B79E8CF-CFF2-496A-8BA2-46B0D57223D1@ifi.uio.no> References: , To: Hagen Paul Pfeifer , Michael Welzl , Joe Touch X-Mailer: Apple Mail (2.1878.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 8 sum msgs/h 3 total rcpts 99 max rcpts/h 8 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EB0EBADD897E5D4B2E21E492C5F9C4DDCEABBC99 X-UiO-SPAM-Test: remote_host: 193.157.237.186 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 15 max/h 3 blacklist 0 greylist 1 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rRzrVxPqC2ESMCaJEeciDR2JdBE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:30:34 -0000 Hi all, Inline comments, ________________________________________ From: tcpm on behalf of Hagen Paul Pfeifer = Sent: Tuesday, October 21, 2014 3:19 PM To: Michael Welzl; Joe Touch Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for = draft-you-tcpm-configuring-tcp-initial-window-00.txt On 20 October 2014 21:19, Michael Welzl wrote: > Hi Hagen, Hi Michael > what if 10 is used as a default (like now) and an upper limit? I am not a friend of any static stack global or user configured IW - let me explain this. Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say that the IW should increase "savely" over the years. But the IW has nothing to do with time! It has something to do with available bandwidth (and delay, but skip this for now). The problem is that the bandwidth do not increase over time for *all links*.=20 There was a proposal, = http://tools.ietf.org/html/draft-allman-tcpm-bump-initcwnd-00; in this, IW can be set over time. And the reason considers network = safety, and performance improvement due to an increase in network = capacity. I believe IW value depends on available bandwidth; it also = depends more on flow characteristics in the Internet what I observed in = my work during master thesis. Large flows (flows with large in = data-size) stay for a long time in the Internet; however, small flows = want to leave the Internet as soon as possible. Why not to give them = chance to finish early. Moreover, we observed small flows get more = benefit compared to large flows, having a larger IW. This makes IW = dependent on flow characteristics. It may be, the available bandwidth is = enough to accommodate for such change. Till now, I did not consider = network-state in relation to setting IW, but we need to consider. =20 The bandwidth is not equal everywhere to every time for everyone. There are links out there with path characteristics from 1990 and older - but the clients use modern operating systems and we must make sure that TCP will operate in this environment too. I participate at the Freifunk Mesh in Munich [1]. A mesh network providing internet connectivity for the masses. Often the link quality is really bad with a lot of MAC layer retransmissions resulting in low bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP on "classic wifi links". Now assume a setsockopt() IW of 50 - this will lead to congested queues, dropped packets and interflow fairness problems and probably non-operative links because the application will re-send packets again and gain. Question: what is the right IW for a given application? -> it is not application specific - it is link specific! But we have already a solution to this: the TCP Control Block (RFC 2140) (to mention the author of the RFC: Joe Touch! ;)! The control block is already implemented in Linux network stack and cache CW parameters (amongst other things). This is a far better approach because it starts conservative in the initial probing phase (3/4 segments as specific) and memorize window parameters on a path basis (yes, another IW misbelieve: the available bandwidth (IW) is not a global value, it change over path and time characteristics). This automated approach is the best you can get for your money - there is not need for static defines in your kernel. And yes, Joe's I-D might be a good starting point to even tune the IW even more. Last week I met Jerry Chu (the author of IW10) at the LPC14 and he told me that some guys start pushing on IW10 - I was hoping that this happens not so immediately! ;-) Hagen [1] https://en.wikipedia.org/wiki/Freifunk All I say, a constant IW may not be a good option. If we can understand = the network during the handshaking, we can get better performance. Regards, - Runa Barik _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Oct 21 07:36:35 2014 Return-Path: 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 C74441A6FF9 for ; Tue, 21 Oct 2014 07:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=no 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 n3nL7edj-wgx for ; Tue, 21 Oct 2014 07:36:20 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C51A7000 for ; Tue, 21 Oct 2014 07:36:20 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.212) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5419499102E9ED95 for tcpm@ietf.org; Tue, 21 Oct 2014 17:36:19 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Oct 2014 17:36:17 +0300 References: <10072_1412768362_5435226A_10072_392_1_F6793389-F2A7-40F7-AAB5-39237221DB8D@iki.fi> To: "tcpm@ietf.org Extensions" Message-Id: <7DE527A2-148F-41B0-8BFA-B3E0A2B2574F@iki.fi> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/k7-TWJPZJc8AGQeUZLzJXYIL2WI Subject: [tcpm] Fwd: Presentation requests for IETF-91 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:36:26 -0000 Reminder: if you haven=92t done so yet, please send presentation = requests within the next couple of days. The deadline for submitting = initial WG agendas is approaching. Thanks! - Pasi Begin forwarded message: > From: Pasi Sarolahti > Subject: [tcpm] Presentation requests for IETF-91 > Date: 8 Oct 2014 14:38:58 GMT+3 > To: tcpm IETF list >=20 > Hi, >=20 > It is time to start building TCPM agenda for the Honolulu meeting. We = have requested a 2.5 hour slot for the TCPM meeting. If you want to = present your draft in the meeting, please send tcpm-chairs the following = information: >=20 > * Title > * Time needed (presentation + discussion) > * Name of speaker >=20 > Please send your requests by Thursday, October 23. >=20 > Thanks! >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Oct 21 09:56:17 2014 Return-Path: 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 8D3681A8AE6 for ; Tue, 21 Oct 2014 09:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 d18PxbbFljso for ; Tue, 21 Oct 2014 09:56:11 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A641A8AE0 for ; Tue, 21 Oct 2014 09:56:11 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9LGu9v0005664; Tue, 21 Oct 2014 11:56:09 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <544593A4.2090108@isi.edu> Date: Tue, 21 Oct 2014 11:56:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/2JZUbTEdu8Hz1wLwZqy37-Lsrpg Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:56:15 -0000 > On Oct 20, 2014, at 5:58 PM, Joe Touch wrote: >=20 > On 10/17/2014 7:23 PM, David Borman wrote: > ... >>> - in 4WHS, the SYN-ACK can >>>=20 >>> In 3WHS, the SYN is where all new options happen and are confirmed = using >>> a 3WHS. >>=20 >> Again, both sides propose what options they can support, and they = enable >> the intersection of what they sent in their SYN, and received in the >> other sides SYN or SYN-ACK.=20 >=20 > There are four messages: > X-SYN Y-SYN =09 > =09 > X-SYN/ACK Y-SYN/ACK >=20 > Presumably, the intersection will be of the options in the SYNs but > there are options that don't discuss the case of receiving a SYN while > in SYN-SENT as a separate case. They merely talk about reacting to the > SYN/ACK seen. No. For example, look at 7323, it is very explicit that it is sending and receiving the option in a packet with the SYN bit set that enables it, it makes no distinction between a SYN-only and a SYN/ACK packet. It also has the added optimization that there is no need to include the option in a SYN/ACK if it wasn=E2=80=99t received in the inbound = SYN, since it can never be enabled. It is the presence of the option in a packet with the SYN bit that matters, and that works for both the 3WHS and the simultaneous open. ... >> Let me make it clearer with the simultaneous open: In that case, = both >> sides send a SYN packet with some set of options. When they each = receive >> each others SYN, they both now have the intersection of options both = sent >> and received in a packet with a SYN, and know what options are = enabled. >> What=E2=80=99s in the SYN-ACK that they then send is superfluous, = both sides >> have already determined what options are supported for this = connection. >=20 > I understand your logic but I'm not convinced that all options are > defined to work that way. They aren=E2=80=99t. I=E2=80=99m sorry if you thought I was saying that = all TCP options were negotiated this way. Each option definition describes if/how it is negotiated. The method in RFC 7323 is to exchange the options in = packets with the SYN bit set. For options so defined, the 4WHS gives an = opportunity to enable additional options that didn=E2=80=99t fit into the initial = SYN-only packet. >>> If 4WHS adds new options in the SYN-ACK, it needs another message to >>> complete a 3WHS based on the options selected for a given = connection. >>>=20 >>> I.e., the client adds new options during SYN-ACK, the server = confirms >>> what it selects as a subset in the ACK to the client - but the = client >>> might still not like the subset picked. It needs a message to = confirm >>> that final choice. >>=20 >> The final ACK doesn=E2=80=99t have any part of the option = negotiation, in either >> the 3way or 4way handshake. >=20 > Again, we'd have to check the definition of every option to ensure > that's the case. Strictly, the SYN can offer a set, the SYN/ACK can > offer a subset back, and the ACK can turn on a subset of those = indicated > in the SYN/ACK. I don't know if any option takes advantage of that > sequence, though. Strictly, for these type of negotiated options, it is the presence of the option in packets with the SYN bit set that matter, not whether it is a SYN-only or SYN/ACK packet. It is sending and receiving the option in a packet with the SYN bit set that enables use of that option. Packets with the SYN bit are reliably delivered, ACK-only packets are = not. ... >> With the 4way handshake the client >> sends two packets with the SYN bit, so if the server has included >> additional options in its SYN-ACK that weren=E2=80=99t received in = the SYN, >> then the client can enable those options by including them in its >> SYN-ACK. =20 >=20 > The client offers a set of options in the SYN >=20 > The server responds with a SYN: SYN/ACK in the 4WHS > - does it confirm any of those options yet? > - what other options does it send? > it needs to send all the options it *can support* > because it doesn't know which ones the client > wants to enable, but not all those combinations may > be desirable by the server It includes any additional options that it makes sense to include, making use of the additional space provided by the EDO option. Nothing says it has to include everything. It doesn=E2=80=99t have to include things that don=E2=80=99t make sense, such a uni-directional options. > =09 > The client sends the SYN/ACK: > This message is supposed to complete the set selected >=20 > TCP does support simultaneous open, but not all options are = necessarily > defined as supporting that. >=20 > As per above, the server SYN isn't like any other SYN. It doesn't > contain the options the server enables for the connection because = that's > not how servers typically work. It has to contain all the options that > COULD be used on a connection, but it's entirely possible there are = sets > that don't make sense. >=20 > The server has to have a chance to decide that the final set = negotiated > isn't what it wanted. It gets that chance when it decides to open a > connection or when it responds to the whole set of options offered - = but > neither happens in this case. ... For options that are negotiated in the SYN exchange, the servers SYN/ACK in the 4WHS should only contain additional options if it is willing to enable them. Hence if something is non-sensical, it shouldn=E2=80=99t = include them. There is no requirement that the servers SYN/ACK contain every option that it knows about. The 4WHS is about providing an *opportunity* to enable additional = options that didn=E2=80=99t fit into the initial SYN-only packet, not a = *requirement* that the servers SYN/ACK has to contain all known additional options. -David From nobody Tue Oct 21 10:45:24 2014 Return-Path: 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 1EEFE1A6F32 for ; Tue, 21 Oct 2014 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ecxFPHnyS3y8 for ; Tue, 21 Oct 2014 10:45:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896201A6F10 for ; Tue, 21 Oct 2014 10:45:20 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9LHiTw3008628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 10:44:29 -0700 (PDT) Message-ID: <54469B7C.4080004@isi.edu> Date: Tue, 21 Oct 2014 10:44:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" , Pasi Sarolahti References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/6hH5BnJpnrVm0byg5OkjB6UHD3c Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:45:22 -0000 On 10/21/2014 4:47 AM, Zimmermann, Alexander wrote: ... >> So why is it no longer recommended? The IESG statement also calls for explanation for the transition. > > See for example this thread: http://www.ietf.org/mail-archive/web/ietf/current/msg81410.html > (or http://marc.info/?t=137611379100002&r=1&w=2) > > Wes: „There are probably security issues“ > Joe: „There are semantics issues to; see draft-touch-tcp-portnames-00 for information“ > Bob Braden: „Indeed, TCPMUX is quite historic… it represents a Road Not Taken“ > > Another source is: draft-touch-tcpm-sno-02.txt > > If Joe, Wes or Bob think now that we should not obsolete TCPMUX, fine by me. > I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community) > opinion. It's a huge hole in any sort of firewall, not to mention numerous specific attacks. I support obsoleting it, but the reason needs to be clear - severity of vulnerability and lack of deployed clients, NOT lack of deployed servers with this capability. I.e., although (x)inetd understands incoming requests, unmodified user applications can't simply change to port 1 and work; they need to send the actual service name as user data, and I don't know of any that do that. Joe From nobody Tue Oct 21 10:49:09 2014 Return-Path: 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 82B461A6FD5 for ; Tue, 21 Oct 2014 10:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 7JLdFxvrtFto for ; Tue, 21 Oct 2014 10:49:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70791A6FBF for ; Tue, 21 Oct 2014 10:48:58 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9LHlSoV019656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 10:47:28 -0700 (PDT) Message-ID: <54469C30.9070906@isi.edu> Date: Tue, 21 Oct 2014 10:47:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> In-Reply-To: <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/UATZtR3xvb0SKhatk1yd47aGJ7k Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:49:07 -0000 On 10/21/2014 9:56 AM, David Borman wrote: > >> On Oct 20, 2014, at 5:58 PM, Joe Touch wrote: >> >> On 10/17/2014 7:23 PM, David Borman wrote: >> ... >>>> - in 4WHS, the SYN-ACK can >>>> >>>> In 3WHS, the SYN is where all new options happen and are confirmed using >>>> a 3WHS. >>> >>> Again, both sides propose what options they can support, and they enable >>> the intersection of what they sent in their SYN, and received in the >>> other sides SYN or SYN-ACK. >> >> There are four messages: >> X-SYN Y-SYN >> >> X-SYN/ACK Y-SYN/ACK >> >> Presumably, the intersection will be of the options in the SYNs but >> there are options that don't discuss the case of receiving a SYN while >> in SYN-SENT as a separate case. They merely talk about reacting to the >> SYN/ACK seen. > > No. For example, look at 7323, it is very explicit that it is sending > and receiving the option in a packet with the SYN bit set that enables > it, it makes no distinction between a SYN-only and a SYN/ACK packet. Not all options are specified that way. > ... >>> Let me make it clearer with the simultaneous open: In that case, both >>> sides send a SYN packet with some set of options. When they each receive >>> each others SYN, they both now have the intersection of options both sent >>> and received in a packet with a SYN, and know what options are enabled. >>> What’s in the SYN-ACK that they then send is superfluous, both sides >>> have already determined what options are supported for this connection. >> >> I understand your logic but I'm not convinced that all options are >> defined to work that way. > > They aren’t. I’m sorry if you thought I was saying that all TCP options > were negotiated this way. Each option definition describes if/how it is > negotiated. The method in RFC 7323 is to exchange the options in packets > with the SYN bit set. For options so defined, the 4WHS gives an opportunity > to enable additional options that didn’t fit into the initial SYN-only packet. You're thus proposing NEW requirements on option negotiation, and that ought to be clear in your document as well as considered in comparison to all existing and pending options. ... >> The client offers a set of options in the SYN >> >> The server responds with a SYN: > SYN/ACK in the 4WHS > >> - does it confirm any of those options yet? >> - what other options does it send? >> it needs to send all the options it *can support* >> because it doesn't know which ones the client >> wants to enable, but not all those combinations may >> be desirable by the server > > It includes any additional options that it makes sense to include, > making use of the additional space provided by the EDO option. > Nothing says it has to include everything. It doesn’t have to > include things that don’t make sense, such a uni-directional > options. But it has to include *anything* that the client might want to ACK. I.e., your proposal is NOT consistent with current semantics of option use in SYN segments. Right now, IMO: - options offered in SYNs are those actually desired for a given connection - options in the SYN/ACK confirm the subset of those desired options You're proposing that options in the server's SYN be "a superset of those the client may want to enable on this connection". ... > For options that are negotiated in the SYN exchange, the servers SYN/ACK > in the 4WHS should only contain additional options if it is willing to > enable them. Hence if something is non-sensical, it shouldn’t include > them. There is no requirement that the servers SYN/ACK contain every > option that it knows about. > > The 4WHS is about providing an *opportunity* to enable additional options > that didn’t fit into the initial SYN-only packet, not a *requirement* that > the servers SYN/ACK has to contain all known additional options. It's the Server's SYN that has this property. From nobody Tue Oct 21 11:37:37 2014 Return-Path: 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 BB7541A87B9 for ; Tue, 21 Oct 2014 11:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.779 X-Spam-Level: **** X-Spam-Status: No, score=4.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 nlngg18jzXkE for ; Tue, 21 Oct 2014 11:37:33 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690D61A87A0 for ; Tue, 21 Oct 2014 11:37:12 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgeIx-00019q-0b; Tue, 21 Oct 2014 20:37:11 +0200 Received: from host-37-191-223-171.lynet.no ([37.191.223.171]) by mail-mx2.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) user runabk (Exim 4.80) (envelope-from ) id 1XgeIw-0005dw-6I; Tue, 21 Oct 2014 20:37:10 +0200 Message-ID: <5446A7D4.5070607@ifi.uio.no> Date: Tue, 21 Oct 2014 20:37:08 +0200 From: Runa Barik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hagen Paul Pfeifer , Michael Welzl , Joe Touch References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090303000605040502070409" X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 103 max rcpts/h 8 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F135CB4E80DFFD2A36C3094B63878D568DFE9174 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 37.191.223.171 spam_score: -49 maxlevel 80 minaction 1 bait 0 blacklist 0 greylist 1 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xS1FKEhEfCcwulzklbftW29uNBc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:37:35 -0000 This is a multi-part message in MIME format. --------------090303000605040502070409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, Sorry for duplicate e-mail. Inline comments. On ୨୧-୧୦-୧୪ PM 03:19, Hagen Paul Pfeifer wrote: > On 20 October 2014 21:19, Michael Welzl wrote: >> Hi Hagen, > Hi Michael > >> what if 10 is used as a default (like now) and an upper limit? > I am not a friend of any static stack global or user configured IW - > let me explain this. > > Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say > that the IW should increase "savely" over the years. But the IW has > nothing to do with time! It has something to do with available > bandwidth (and delay, but skip this for now). The problem is that the > bandwidth do not increase over time for *all links*. There was a proposal,http://tools.ietf.org/html/draft-allman-tcpm-bump-initcwnd-00; in this, IW can be set over time. And the reason considers network safety, and performance improvement due to an increase in network capacity. I believe IW value depends on available bandwidth; it also depends more on flow characteristics in the Internet what I observed in my work during master thesis. Large flows (flows with large in data-size) stay for a long time in the Internet; however, small flows want to leave the Internet as soon as possible. Why not to give them chance to finish early. Moreover, we observed small flows get more benefit compared to large flows, having a larger IW. This makes IW dependent on flow characteristics. It may be, the available bandwidth is enough to accommodate for such change. Till now, I did not consider network-state in relation to setting IW, but we need to consider. > The bandwidth is > not equal everywhere to every time for everyone. There are links out > there with path characteristics from 1990 and older - but the clients > use modern operating systems and we must make sure that TCP will > operate in this environment too. > > I participate at the Freifunk Mesh in Munich [1]. A mesh network > providing internet connectivity for the masses. Often the link quality > is really bad with a lot of MAC layer retransmissions resulting in low > bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP > on "classic wifi links". > > Now assume a setsockopt() IW of 50 - this will lead to congested > queues, dropped packets and interflow fairness problems and probably > non-operative links because the application will re-send packets again > and gain. Question: what is the right IW for a given application? -> > it is not application specific - it is link specific! > > But we have already a solution to this: the TCP Control Block (RFC > 2140) (to mention the author of the RFC: Joe Touch! ;)! > > The control block is already implemented in Linux network stack and > cache CW parameters (amongst other things). This is a far better > approach because it starts conservative in the initial probing phase > (3/4 segments as specific) and memorize window parameters on a path > basis (yes, another IW misbelieve: the available bandwidth (IW) is not > a global value, it change over path and time characteristics). This > automated approach is the best you can get for your money - there is > not need for static defines in your kernel. And yes, Joe's I-D might > be a good starting point to even tune the IW even more. > > Last week I met Jerry Chu (the author of IW10) at the LPC14 and he > told me that some guys start pushing on IW10 - I was hoping that this > happens not so immediately! ;-) > > Hagen > > > [1] https://en.wikipedia.org/wiki/Freifunk > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm All I say, a constant IW may not be a good option. If we can understand the network during the handshaking, we can get better performance. Regards, - Runa Barik --------------090303000605040502070409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all,

    Sorry for duplicate e-mail.

    Inline comments.

On ୨୧-୧୦-୧୪ PM 03:19, Hagen Paul Pfeifer wrote:
On 20 October 2014 21:19, Michael Welzl <michawe@ifi.uio.no> wrote:

Hi Hagen,

Hi Michael


what if 10 is used as a default (like now) and an upper limit?

I am not a friend of any static stack global or user configured IW -
let me explain this.

Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say
that the IW should increase "savely" over the years. But the IW has
nothing to do with time! It has something to do with available
bandwidth (and delay, but skip this for now). The problem is that the
bandwidth do not increase over time for *all links*.
There was a proposal, http://tools.ietf.org/html/draft-allman-tcpm-bump-initcwnd-00;
in this, IW can be set over time. And the reason considers network safety, and
performance improvement  due to an increase in network capacity.
I believe IW value depends on available bandwidth; it also depends
more on flow characteristics in the Internet what I observed in my work during master thesis.
Large flows (flows with large in data-size) stay for a long time in the Internet;
however, small flows want to leave the Internet as soon as possible.
Why not to give them chance to finish early. Moreover, we observed small flows get
more benefit compared to large flows, having  a larger IW. This makes IW dependent
on flow characteristics. It may be, the available bandwidth is enough to accommodate for such change.
Till now, I did not consider network-state in relation to setting IW, but we need to consider.

The bandwidth is
not equal everywhere to every time for everyone. There are links out
there with path characteristics from 1990 and older - but the clients
use modern operating systems and we must make sure that TCP will
operate in this environment too.

I participate at the Freifunk Mesh in Munich [1]. A mesh network
providing internet connectivity for the masses. Often the link quality
is really bad with a lot of MAC layer retransmissions resulting in low
bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP
on "classic wifi links".

Now assume a setsockopt() IW of 50 - this will lead to congested
queues, dropped packets and interflow fairness problems and probably
non-operative links because the application will re-send packets again
and gain. Question: what is the right IW for a given application? ->
it is not application specific - it is link specific!

But we have already a solution to this: the TCP Control Block (RFC
2140) (to mention the author of the RFC: Joe Touch! ;)!

The control block is already implemented in Linux network stack and
cache CW parameters (amongst other things). This is a far better
approach because it starts conservative in the initial probing phase
(3/4 segments as specific) and memorize window parameters on a path
basis (yes, another IW misbelieve: the available bandwidth (IW) is not
a global value, it change over path and time characteristics). This
automated approach is the best you can get for your money - there is
not need for static defines in your kernel. And yes, Joe's I-D might
be a good starting point to even tune the IW even more.

Last week I met Jerry Chu (the author of IW10) at the LPC14 and he
told me that some guys start pushing on IW10 - I was hoping that this
happens not so immediately! ;-)

Hagen


[1] https://en.wikipedia.org/wiki/Freifunk

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
All I say, a constant IW may not be a good option. If we can
understand the network during the handshaking, we can get better performance.

Regards,
- Runa Barik
 --------------090303000605040502070409-- From nobody Tue Oct 21 11:50:59 2014 Return-Path: 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 BADDD1A87DF for ; Tue, 21 Oct 2014 11:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 6efZb2KNPgiF for ; Tue, 21 Oct 2014 11:50:51 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C991A8820 for ; Tue, 21 Oct 2014 11:50:51 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9LIon5m007507; Tue, 21 Oct 2014 13:50:49 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <54469C30.9070906@isi.edu> Date: Tue, 21 Oct 2014 13:50:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> <54469C30.9070906@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/D4ic2wkgmxoyJx_5aD7FXMpKKAg Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:50:54 -0000 > On Oct 21, 2014, at 12:47 PM, Joe Touch wrote: > On 10/21/2014 9:56 AM, David Borman wrote: >>=20 >>> On Oct 20, 2014, at 5:58 PM, Joe Touch wrote: >>> On 10/17/2014 7:23 PM, David Borman wrote: ... >>>> Let me make it clearer with the simultaneous open: In that case, = both >>>> sides send a SYN packet with some set of options. When they each = receive >>>> each others SYN, they both now have the intersection of options = both sent >>>> and received in a packet with a SYN, and know what options are = enabled. >>>> What=E2=80=99s in the SYN-ACK that they then send is superfluous, = both sides >>>> have already determined what options are supported for this = connection. >>>=20 >>> I understand your logic but I'm not convinced that all options are >>> defined to work that way. >>=20 >> They aren=E2=80=99t. I=E2=80=99m sorry if you thought I was saying = that all TCP options >> were negotiated this way. Each option definition describes if/how it = is >> negotiated. The method in RFC 7323 is to exchange the options in = packets >> with the SYN bit set. For options so defined, the 4WHS gives an = opportunity >> to enable additional options that didn=E2=80=99t fit into the initial = SYN-only packet. >=20 > You're thus proposing NEW requirements on option negotiation, and that > ought to be clear in your document as well as considered in comparison > to all existing and pending options. What new requirements? It=E2=80=99s an extension that allows for = options that didn=E2=80=99t fit into the initial SYN to still be enabled, by = including them in the exchanged SYN/ACK packets. > ... >>> The client offers a set of options in the SYN >>>=20 >>> The server responds with a SYN: >> SYN/ACK in the 4WHS >>=20 >>> - does it confirm any of those options yet? >>> - what other options does it send? >>> it needs to send all the options it *can support* >>> because it doesn't know which ones the client >>> wants to enable, but not all those combinations may >>> be desirable by the server >>=20 >> It includes any additional options that it makes sense to include, >> making use of the additional space provided by the EDO option. >> Nothing says it has to include everything. It doesn=E2=80=99t have = to >> include things that don=E2=80=99t make sense, such a uni-directional >> options. >=20 > But it has to include *anything* that the client might want to ACK. No it doesn=E2=80=99t. It would only include options that it would = still like to be enabled, but weren=E2=80=99t included in the inbound SYN. = Why on earth would it offer up to enable options it doesn=E2=80=99t want to = use? > I.e., your proposal is NOT consistent with current semantics of option > use in SYN segments. >=20 > Right now, IMO: > - options offered in SYNs are those actually desired for > a given connection >=20 > - options in the SYN/ACK confirm the subset of those > desired options Yes, that is your opinion, but it is wrong. As documented in RFC 7323 and others, it is the sending and receiving of the option in packets with the SYN bit set that enables use of the option, e.g. Window Scale, Timestamps, SACK permitted. In the 3WHS, the options in the SYN are the options the client would like to be enabled, the options in the SYN/ACK are the options the server would like to be enabled. Both sides only enable the options that they both sent and received in a packet with the SYN bit set. For options that are enabled via this mechanism, it is only an optimization to not include in the SYN/ACK any option that was not received in the SYN, since it can never be enabled using the 3WHS. There is no restriction that a SYN/ACK can=E2=80=99t include TCP options that weren=E2=80=99t included in the SYN. > You're proposing that options in the server's SYN be "a superset of > those the client may want to enable on this connection=E2=80=9D. In the 4WAY handshake, yes, the servers SYN/ACK can make use of the EDO option and include additional options that it would like to enable for the connection. It isn=E2=80=99t strictly a superset, = because the server wouldn=E2=80=99t include options from the inbound SYN that it = doesn=E2=80=99t understand or want to enable. If it includes additional options in the SYN/ACK, and the returning client=E2=80=99s SYN/ACK also has those = options, then they are enabled, even though they weren=E2=80=99t present in the = original SYN. =20 >=20 > ... >> For options that are negotiated in the SYN exchange, the servers = SYN/ACK >> in the 4WHS should only contain additional options if it is willing = to >> enable them. Hence if something is non-sensical, it shouldn=E2=80=99t = include >> them. There is no requirement that the servers SYN/ACK contain every >> option that it knows about. >>=20 >> The 4WHS is about providing an *opportunity* to enable additional = options >> that didn=E2=80=99t fit into the initial SYN-only packet, not a = *requirement* that >> the servers SYN/ACK has to contain all known additional options. >=20 > It's the Server's SYN that has this property. You keep saying =E2=80=9CServer=E2=80=99s SYN=E2=80=9D. Do you mean = =E2=80=9CSYN-only=E2=80=9D packet? That=E2=80=99s only in a simultaneous open. As currently documented, in the 4WAY handshake the server responds to the inbound SYN-only with a SYN-ACK, not a SYN-only packet. And the property is that if each side sends and receives an option in a = packet with the SYN bit set, then the option is enabled; it=E2=80=99s the same = for 3WHS and 4WHS. -David= From nobody Tue Oct 21 12:06:27 2014 Return-Path: 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 148B71A885F for ; Tue, 21 Oct 2014 12:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 P5aKqG08qH2M for ; Tue, 21 Oct 2014 12:06:12 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2D31A8866 for ; Tue, 21 Oct 2014 12:05:50 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xgeke-0002s7-VD; Tue, 21 Oct 2014 21:05:48 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Xgeke-0001oQ-4i; Tue, 21 Oct 2014 21:05:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: Date: Tue, 21 Oct 2014 21:05:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> References: <, <>> To: Runa Barik X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 21598 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69032130B36F742472BD1A162C0BF6CE44987664 X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 450 max/h 11 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/s8OiGlqg84INyyYwDGVzkHCdUnE Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:06:15 -0000 Hi all, In line - > On 21. okt. 2014, at 16.12, Runa Barik wrote: >=20 > Hi all, >=20 > Inline comments, > ________________________________________ > From: tcpm on behalf of Hagen Paul Pfeifer = > Sent: Tuesday, October 21, 2014 3:19 PM > To: Michael Welzl; Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] New Version Notification for = draft-you-tcpm-configuring-tcp-initial-window-00.txt >=20 > On 20 October 2014 21:19, Michael Welzl wrote: >> Hi Hagen, >=20 > Hi Michael >=20 >> what if 10 is used as a default (like now) and an upper limit? >=20 > I am not a friend of any static stack global or user configured IW - > let me explain this. >=20 > Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say > that the IW should increase "savely" over the years. But the IW has > nothing to do with time! It has something to do with available > bandwidth (and delay, but skip this for now). The problem is that the > bandwidth do not increase over time for *all links*.=20 >=20 > There was a proposal, = http://tools.ietf.org/html/draft-allman-tcpm-bump-initcwnd-00; > in this, IW can be set over time. And the reason considers network = safety, and performance improvement due to an increase in network = capacity. I believe IW value depends on available bandwidth; it also = depends more on flow characteristics in the Internet what I observed in = my work during master thesis. Large flows (flows with large in = data-size) stay for a long time in the Internet; however, small flows = want to leave the Internet as soon as possible. Why not to give them = chance to finish early. Moreover, we observed small flows get more = benefit compared to large flows, having a larger IW. This makes IW = dependent on flow characteristics. It may be, the available bandwidth is = enough to accommodate for such change. Till now, I did not consider = network-state in relation to setting IW, but we need to consider. =20 I=E2=80=99ll note that the above paragraph is from Runa, not Hagen, and = get back to this point below > The bandwidth is > not equal everywhere to every time for everyone. There are links out > there with path characteristics from 1990 and older - but the clients > use modern operating systems and we must make sure that TCP will > operate in this environment too. >=20 > I participate at the Freifunk Mesh in Munich [1]. A mesh network > providing internet connectivity for the masses. Often the link quality > is really bad with a lot of MAC layer retransmissions resulting in low > bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP > on "classic wifi links". >=20 > Now assume a setsockopt() IW of 50 - this will lead to congested > queues, dropped packets and interflow fairness problems and probably > non-operative links because the application will re-send packets again > and gain. Up to here, I agree with you. > Question: what is the right IW for a given application? -> > it is not application specific - it is link specific! Here I=E2=80=99m not so sure, unless we go for extremes of course, as in = your IW50 example. Generally I do see the point of Runa above, in trying = to let short flows finish fast and get out of the network, it=E2=80=99s = a double benefit somehow. > But we have already a solution to this: the TCP Control Block (RFC > 2140) (to mention the author of the RFC: Joe Touch! ;)! >=20 > The control block is already implemented in Linux network stack and > cache CW parameters (amongst other things). This is a far better > approach because it starts conservative in the initial probing phase > (3/4 segments as specific) and memorize window parameters on a path > basis (yes, another IW misbelieve: the available bandwidth (IW) is not > a global value, it change over path and time characteristics). This > automated approach is the best you can get for your money - there is > not need for static defines in your kernel. And yes, Joe's I-D might > be a good starting point to even tune the IW even more. Interesting; while RFC 2140 is absolutely on my radar (we do some quite = closely related work in RMCAT), I forgot that it talks about IW. Can you = provide more detail about what is implemented in Linux for the IW there = - I thought by default none of this is happening for IW in Linux, all = flows just get 10? I agree that Ensemble Sharing could make sense for IW=E2=80=A6 however, = thanks to ECMP, there is of course no guarantee that different = connections to the same IP address really do traverse the same = bottleneck. So an approach that uses e.g. IW1 for later-joining = connections to the same IP address may be doing the exact right thing or = may be too conservative, depending on whether ECMP is in place or not. = Further, by applying this limitation only on later connections to the = same IP address, it may not kick in often enough. Alternatively, giving a different IW to flows depending on their size = may be doing the right thing more or less often=E2=80=A6 either way = it=E2=80=99s heuristics I guess. I think both options are worth = considering. Generally, giving a large IW only to short flows does = strike me as reasonable because long flows simply won=E2=80=99t benefit = much from it. My point in my previous email was only that no additional harm comes = from letting the application tell the transport layer a desired IW (or = maybe rather flow size, to allow transport to do the calculation), = provided that an upper limit is imposed by the transport. Cheers, Michael From nobody Tue Oct 21 12:23:43 2014 Return-Path: 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 6CF151A19F9 for ; Tue, 21 Oct 2014 12:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 fdZ-ChSDVIkL for ; Tue, 21 Oct 2014 12:23:39 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9481A03A6 for ; Tue, 21 Oct 2014 12:23:36 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so1884297wib.3 for ; Tue, 21 Oct 2014 12:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=o9nf43/of+kt5IFtS4Lu0V6ZkdWpYrf988Lksrh1XDg=; b=UpAxDrxw2W9UNiAqvMJYJ0BK/lDCIhBtJg7VDYgiejR0GuzX8NNc702aKASNVHgf4+ uBvvcffi/MVAcDcS9Z29UWsqaqOG53khkO+jk8qT2uzj8Zr69QMfrrYxoRzflKjIaGuP A08Gm82uKa/EPE98MRyUlKHpdgua8Hzt1xkeT20vh0yCL/iA07byuov6Wu2wzaHpORCl Met74lg4pVjkchlLr9PradZirYJhlKTGcMDCE3pTpk82eqYsrQgXsfVv+rUctBIQr3C+ Lu//4RfIz1RchC45gJYget6nBu+BcOLaLT4OQczbkX6CaxLy3B9E8LSp1zlX3EMZaX5c LwMg== X-Gm-Message-State: ALoCoQlMnl9y/Y3BSXG3ZzjfESaJi8lgp8iFV+xyeQLRieltBrBUGnU2ouKRqTxneBFjXLYaNbJu X-Received: by 10.194.205.132 with SMTP id lg4mr44275826wjc.84.1413919414875; Tue, 21 Oct 2014 12:23:34 -0700 (PDT) Received: from virgo.local ([2a02:810d:740:32b4:6a05:caff:fe03:ab31]) by mx.google.com with ESMTPSA id w13sm16341364wjq.29.2014.10.21.12.23.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 12:23:33 -0700 (PDT) Date: Tue, 21 Oct 2014 21:23:31 +0200 From: Hagen Paul Pfeifer To: Runa Barik Message-ID: <20141021192331.GB4851@virgo.local> References: <5446A7D4.5070607@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <5446A7D4.5070607@ifi.uio.no> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0-qAiVP2o8NdiIJuHq2yiAHr5FU Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:23:41 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Runa Barik | 2014-10-21 20:37:08 [+0200]: >All I say, a constant IW may not be a good option. If we can >understand the network during the handshaking, we can get better performance. Constants are always a guess - like the initial RTO. Starting with a sensitive guess and probe dynamically is always the best what you can do when you know nothing about network characteristics. Changing the IW on a per date basis like Mark's I-D propose is not what I support. Bandwidth *is* and will be different for a given date, compare CERN network bandwidth to multi-hop sensor networks - there is no right IW answer. As I already wrote: dynamically probing succeeded by metric caching is the best way to do. Meaning conservative in the beginning and utilize the pipe in subsequent connections. And bye the way: slow starting with IW10 *is* fast. If there is a problem then probably the application layer is broken. See how HTTP/2 fixed their congestion window problem. Hagen PS the shorted output of the TCP metric cache (sudo ip tcp_metrics show): 2a01:488:66:1000:b01c:b5d:0:1 age 2148.336sec rtt 60500us rttvar 19000us cwnd 10 54.235.102.146 age 28.452sec rtt 126500us rttvar 107000us cwnd 10 176.34.135.100 age 28.544sec rtt 82000us rttvar 82000us cwnd 10 54.244.6.176 age 8.428sec rtt 195000us rttvar 136000us cwnd 10 2a00:1450:4016:804::1014 age 76.572sec 2a00:1450:4016:802::1012 age 770.008sec rtt 39000us rttvar 31000us cwnd 14 2a00:1450:4016:802::1013 age 132.480sec rtt 39500us rttvar 36000us cwnd 14 2a00:1450:4016:803::1012 age 3139.532sec rtt 33000us rttvar 23000us cwnd 9 2a00:1450:4016:805::1014 age 1305.096sec rtt 39500us rttvar 29000us cwnd 14 2a02:26f0:7b:397::eed age 3936.224sec 2a00:1450:4016:805::1017 age 3139.984sec rtt 33000us rttvar 33000us cwnd 10 2a00:1450:4016:802::1010 age 4038.732sec rtt 30500us rttvar 30000us cwnd 12 2a00:1450:4016:804::1017 age 1923.280sec rtt 30500us rttvar 30000us cwnd 10 --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRGsrMACgkQSiKNRZg1DCJb8gCgq/0nnMrUOjvTVQVnurDm/T8T cVsAoKMcat+Bj700/De/p2vlqm4yP41+ =XwhP -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From nobody Tue Oct 21 13:11:07 2014 Return-Path: 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 DE3B91A6EEC for ; Tue, 21 Oct 2014 13:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 aJhP6KqewLYT for ; Tue, 21 Oct 2014 13:10:43 -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 DBF271A6EE1 for ; Tue, 21 Oct 2014 13:09:56 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9LK9BPh027412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 13:09:12 -0700 (PDT) Message-ID: <5446BD67.5030701@isi.edu> Date: Tue, 21 Oct 2014 13:09:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> <54469C30.9070906@isi.edu> <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> In-Reply-To: <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/vyWpUC_5dMObddEsdFK7frloVew Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:10:55 -0000 On 10/21/2014 11:50 AM, David Borman wrote: > >> On Oct 21, 2014, at 12:47 PM, Joe Touch wrote: ... >> You're thus proposing NEW requirements on option negotiation, and that >> ought to be clear in your document as well as considered in comparison >> to all existing and pending options. > > What new requirements? That options be negotiated exclusively by appearance in the SYN in each direction. >> ... >>>> The client offers a set of options in the SYN >>>> >>>> The server responds with a SYN: >>> SYN/ACK in the 4WHS >>> >>>> - does it confirm any of those options yet? >>>> - what other options does it send? >>>> it needs to send all the options it *can support* >>>> because it doesn't know which ones the client >>>> wants to enable, but not all those combinations may >>>> be desirable by the server >>> >>> It includes any additional options that it makes sense to include, >>> making use of the additional space provided by the EDO option. >>> Nothing says it has to include everything. It doesn’t have to >>> include things that don’t make sense, such a uni-directional >>> options. >> >> But it has to include *anything* that the client might want to ACK. > > No it doesn’t. It would only include options that it would still > like to be enabled, but weren’t included in the inbound SYN. Why > on earth would it offer up to enable options it doesn’t want to use? It has to send all the options that might be coming in the client's SYN/ACK. It has to read minds or be exhaustive. > >> I.e., your proposal is NOT consistent with current semantics of option >> use in SYN segments. >> >> Right now, IMO: >> - options offered in SYNs are those actually desired for >> a given connection >> >> - options in the SYN/ACK confirm the subset of those >> desired options > > Yes, that is your opinion, but it is wrong. As documented in > RFC 7323 and others, it is the sending and receiving of the option > in packets with the SYN bit set that enables use of the option, > e.g. Window Scale, Timestamps, SACK permitted. You've already admitted that all options aren't specified that way. > In the 3WHS, the > options in the SYN are the options the client would like to be > enabled, Agreed... > the options in the SYN/ACK are the options the server > would like to be enabled. Agreed. But in the 4WHS case, the client SYN and SYN/ACK have that property, but the server SYN/ACK has to include options the server supports that the client MIGHT want to enable. That's a significant change in semantics. ... >> You're proposing that options in the server's SYN be "a superset of >> those the client may want to enable on this connectionâ€. > > In the 4WAY handshake, yes, the servers SYN/ACK can make use of > the EDO option and include additional options that it would like > to enable for the connection. It isn’t strictly a superset, because > the server wouldn’t include options from the inbound SYN that it doesn’t > understand or want to enable. But it has to include ALL options it can support that the client MIGHT want to enable because it hasn't seen the client's SYN/ACK, so it (the server) doesn't know what options it might need to be agreeing to. --- I agree that the net result is the same (only the options that both sides want are enabled), and that the typical result is the same (only the options the client actually wants are suggested. But the server SYN has to be comprehensive - it has to include every option that this connection MIGHT support. >> ... >>> For options that are negotiated in the SYN exchange, the servers SYN/ACK >>> in the 4WHS should only contain additional options if it is willing to >>> enable them. Hence if something is non-sensical, it shouldn’t include >>> them. There is no requirement that the servers SYN/ACK contain every >>> option that it knows about. >>> >>> The 4WHS is about providing an *opportunity* to enable additional options >>> that didn’t fit into the initial SYN-only packet, not a *requirement* that >>> the servers SYN/ACK has to contain all known additional options. >> >> It's the Server's SYN that has this property. > > You keep saying “Server’s SYNâ€. Do you mean “SYN-only†packet? No - I meant the only SYN packet the server sends (the SYN/ACK in the more typical case). ... > And the property is that if each side sends and receives an option in a packet > with the SYN bit set, then the option is enabled; it’s the same for 3WHS and > 4WHS. Yes, but - as I thought you agreed in the last message - that's NOT a requirement of all options as currently designed. Joe From nobody Tue Oct 21 13:15:12 2014 Return-Path: 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 766E81A1A9A for ; Tue, 21 Oct 2014 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.378 X-Spam-Level: **** X-Spam-Status: No, score=4.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, MANGLED_AVOID=2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 0DeLsFNOUN9i for ; Tue, 21 Oct 2014 13:15:00 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234BD1A6F0E for ; Tue, 21 Oct 2014 13:14:40 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgfpG-0003Qg-DZ; Tue, 21 Oct 2014 22:14:38 +0200 Received: from mail-ex04.exprod.uio.no ([129.240.52.7]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XgfpF-0001aF-CI; Tue, 21 Oct 2014 22:14:38 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex04.exprod.uio.no (2001:700:100:52::7) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 22:14:36 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 22:14:36 +0200 From: Runa Barik To: Michael Welzl Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAArM9SAADWEgIAALxsa Date: Tue, 21 Oct 2014 20:14:35 +0000 Message-ID: References: <, <>> , <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> In-Reply-To: <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 106 max rcpts/h 8 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BCA76DF7293D7C97E2FA71213D0DB80986CDCFA8 X-UiO-SPAM-Test: remote_host: 129.240.52.7 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 14 total 350489 max/h 442 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SSlAzN9hlPAa-RLQxgcdeRJz160 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:15:02 -0000 Hi Michael,=0A= =0A= In line with tag RB -=0A= ________________________________________=0A= From: Michael Welzl =0A= Sent: Tuesday, October 21, 2014 9:05 PM=0A= To: Runa Barik=0A= Cc: Hagen Paul Pfeifer; Joe Touch; tcpm@ietf.org=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= Hi all,=0A= =0A= In line -=0A= =0A= > On 21. okt. 2014, at 16.12, Runa Barik wrote:=0A= >=0A= > Hi all,=0A= >=0A= > Inline comments,=0A= > ________________________________________=0A= > From: tcpm on behalf of Hagen Paul Pfeifer =0A= > Sent: Tuesday, October 21, 2014 3:19 PM=0A= > To: Michael Welzl; Joe Touch=0A= > Cc: tcpm@ietf.org=0A= > Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuri= ng-tcp-initial-window-00.txt=0A= >=0A= > On 20 October 2014 21:19, Michael Welzl wrote:=0A= >> Hi Hagen,=0A= >=0A= > Hi Michael=0A= >=0A= >> what if 10 is used as a default (like now) and an upper limit?=0A= >=0A= > I am not a friend of any static stack global or user configured IW -=0A= > let me explain this.=0A= >=0A= > Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say=0A= > that the IW should increase "savely" over the years. But the IW has=0A= > nothing to do with time! It has something to do with available=0A= > bandwidth (and delay, but skip this for now). The problem is that the=0A= > bandwidth do not increase over time for *all links*.=0A= >=0A= > There was a proposal, http://tools.ietf.org/html/draft-allman-tcpm-bump-i= nitcwnd-00;=0A= > in this, IW can be set over time. And the reason considers network safety= , and performance improvement due to an increase in network capacity. I be= lieve IW value depends on available bandwidth; it also depends more on flow= characteristics in the Internet what I observed in my work during master t= hesis. Large flows (flows with large in data-size) stay for a long time in = the Internet; however, small flows want to leave the Internet as soon as po= ssible. Why not to give them chance to finish early. Moreover, we observed = small flows get more benefit compared to large flows, having a larger IW. = This makes IW dependent on flow characteristics. It may be, the available b= andwidth is enough to accommodate for such change. Till now, I did not cons= ider network-state in relation to setting IW, but we need to consider.=0A= =0A= I=92ll note that the above paragraph is from Runa, not Hagen, and get back = to this point below=0A= =0A= =0A= > The bandwidth is=0A= > not equal everywhere to every time for everyone. There are links out=0A= > there with path characteristics from 1990 and older - but the clients=0A= > use modern operating systems and we must make sure that TCP will=0A= > operate in this environment too.=0A= >=0A= > I participate at the Freifunk Mesh in Munich [1]. A mesh network=0A= > providing internet connectivity for the masses. Often the link quality=0A= > is really bad with a lot of MAC layer retransmissions resulting in low=0A= > bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP=0A= > on "classic wifi links".=0A= >=0A= > Now assume a setsockopt() IW of 50 - this will lead to congested=0A= > queues, dropped packets and interflow fairness problems and probably=0A= > non-operative links because the application will re-send packets again=0A= > and gain.=0A= =0A= Up to here, I agree with you.=0A= =0A= =0A= > Question: what is the right IW for a given application? ->=0A= > it is not application specific - it is link specific!=0A= =0A= Here I=92m not so sure, unless we go for extremes of course, as in your IW5= 0 example. Generally I do see the point of Runa above, in trying to let sho= rt flows finish fast and get out of the network, it=92s a double benefit so= mehow.=0A= =0A= =0A= > But we have already a solution to this: the TCP Control Block (RFC=0A= > 2140) (to mention the author of the RFC: Joe Touch! ;)!=0A= >=0A= > The control block is already implemented in Linux network stack and=0A= > cache CW parameters (amongst other things). This is a far better=0A= > approach because it starts conservative in the initial probing phase=0A= > (3/4 segments as specific) and memorize window parameters on a path=0A= > basis (yes, another IW misbelieve: the available bandwidth (IW) is not=0A= > a global value, it change over path and time characteristics). This=0A= > automated approach is the best you can get for your money - there is=0A= > not need for static defines in your kernel. And yes, Joe's I-D might=0A= > be a good starting point to even tune the IW even more.=0A= =0A= Interesting; while RFC 2140 is absolutely on my radar (we do some quite clo= sely related work in RMCAT), I forgot that it talks about IW. Can you provi= de more detail about what is implemented in Linux for the IW there - I thou= ght by default none of this is happening for IW in Linux, all flows just ge= t 10?=0A= =0A= RB -=0A= =0A= For IW in the Linux Kernel (checked in version 3.7.4), =0A= void tcp_init_sock(struct sock *sk)=0A= {=0A= ...............=0A= tp->snd_cwnd =3D TCP_INIT_CWND;=0A= .................=0A= }=0A= And this is called during TCP initialization.=0A= =0A= RB -=0A= =0A= =0A= I agree that Ensemble Sharing could make sense for IW=85 however, thanks to= ECMP, there is of course no guarantee that different connections to the sa= me IP address really do traverse the same bottleneck. So an approach that u= ses e.g. IW1 for later-joining connections to the same IP address may be do= ing the exact right thing or may be too conservative, depending on whether = ECMP is in place or not. Further, by applying this limitation only on later= connections to the same IP address, it may not kick in often enough.=0A= =0A= Alternatively, giving a different IW to flows depending on their size may b= e doing the right thing more or less often=85 either way it=92s heuristics = I guess. I think both options are worth considering. =0A= =0A= RB -=0A= =0A= I agree with this point. Ensemble Sharing gives some information about t= he network-state.=0A= =0A= RB-=0A= =0A= Generally, giving a large IW only to short flows does strike me as reasonab= le because long flows simply won=92t benefit much from it.=0A= =0A= RB -=0A= =0A= We observed the same --- large flows do not achieve better benefit from = a larger IW.=0A= =0A= RB -=0A= =0A= =0A= My point in my previous email was only that no additional harm comes from l= etting the application tell the transport layer a desired IW (or maybe rath= er flow size, to allow transport to do the calculation), provided that an u= pper limit is imposed by the transport.=0A= =0A= RB -=0A= =0A= We also set an upper limit for IW explicitly inside Transport layer.=0A= =0A= RB -=0A= =0A= Cheers,=0A= Michael=0A= From nobody Tue Oct 21 13:55:37 2014 Return-Path: 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 EB27A1A6FF9 for ; Tue, 21 Oct 2014 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PPuAfwBDzJOd for ; Tue, 21 Oct 2014 13:55:34 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090CE1A6FF2 for ; Tue, 21 Oct 2014 13:55:33 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9LKtWcA008114; Tue, 21 Oct 2014 15:55:32 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <5446BD67.5030701@isi.edu> Date: Tue, 21 Oct 2014 15:55:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8366E48E-8AE4-424F-A9DB-972D5A37CC5C@weston.borman.com> References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> <54469C30.9070906@isi.edu> <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> <5446BD67.5030701@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7r29lSetL1Yh0bjHe-hic4l7fDA Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:55:36 -0000 > On Oct 21, 2014, at 3:09 PM, Joe Touch wrote: > On 10/21/2014 11:50 AM, David Borman wrote: >>=20 >>> On Oct 21, 2014, at 12:47 PM, Joe Touch wrote: > ... >>> You're thus proposing NEW requirements on option negotiation, and = that >>> ought to be clear in your document as well as considered in = comparison >>> to all existing and pending options. >>=20 >> What new requirements?=20 >=20 > That options be negotiated exclusively by appearance in the SYN in = each > direction. You're reading things that aren=E2=80=99t there. There is no one = mechanism for enabling use of TCP options. Each option defines for itself how it is to be used, including any enablement. For many existing options, = enablement is defined as the option being present in both a packet sent and = received with the SYN bit. Examples include Window Scale, Timestamps, and SACK = Permitted. That is nothing new, and is not a requirement for any other TCP option. ... >>> But it has to include *anything* that the client might want to ACK. >>=20 >> No it doesn=E2=80=99t. It would only include options that it would = still >> like to be enabled, but weren=E2=80=99t included in the inbound SYN. = Why >> on earth would it offer up to enable options it doesn=E2=80=99t want = to use? >=20 > It has to send all the options that might be coming in the client's > SYN/ACK. It has to read minds or be exhaustive. ... Absolutely not. In the 4WHS, for options that are only enabled by their presence in the SYN exchange, the servers SYN/ACK can contain additional options to = allow the client to agree to enable them by including them in it=E2=80=99s = SYN/ACK. That=E2=80=99s it. End of story. If the initial SYN didn=E2=80=99t = include Timestamps but SYN/ACK from the server did include Timestamps, then if SYN/ACK from the client includes Timestamps, Timestamps are enabled. The server doesn=E2=80=99t have to know anything about what additional options the = client might or might not like to enable, it only has to know what additional options *it* would like to enable. -David From nobody Tue Oct 21 13:57:17 2014 Return-Path: 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 A07511A701E for ; Tue, 21 Oct 2014 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.287 X-Spam-Level: *** X-Spam-Status: No, score=3.287 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 f0ITIckbvmBI for ; Tue, 21 Oct 2014 13:57:07 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FE31A700A for ; Tue, 21 Oct 2014 13:57:06 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so2382634wgh.9 for ; Tue, 21 Oct 2014 13:57:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ODIa6TIdqn9VxYNTPNBoUow+ORZibRyCjdfcw1BWM3w=; b=YAwFq3hAJTA+Mig07S/Cw+8kXse8qw91RWtijMJA0ibjoc/nyz2QnuNElEKc2Jcj65 Qd8wuVTsib1pFYGwT0eq+3SVDHMY9eKyIHapg+2iqFu18kiM7nRi4zK6TCpMeOQAOrfa zjzijSdfJJAeq8c+goaLO4fbV/Fuexn7PtaOB8rvgtmgtBwzUt6EyHdy0jz1SOS1RK+l 9qDPct4rnb8Shhcz2/KGewWNyvrX8kuBN/ysczf9FZ9uqP8CaiZzNz1TLDy/EL73jyVB 21M2Jw+c4gNnHkglYYnwzNvZ5r+RWGfDsTb+mEPKCQEOcgH4zJnEBbi+dsvuIRjE2Hov zobw== X-Gm-Message-State: ALoCoQmvZIROpb9CnmJ6/O13FFBV9xlbS1+KvVqxuq5S4YDX+1bCqlul7GZNXmkYKZR2HwfIIQmo X-Received: by 10.194.119.164 with SMTP id kv4mr47753015wjb.86.1413925025037; Tue, 21 Oct 2014 13:57:05 -0700 (PDT) Received: from virgo.local ([2a02:810d:740:32b4:6a05:caff:fe03:ab31]) by mx.google.com with ESMTPSA id w13sm16571012wjq.29.2014.10.21.13.57.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 13:57:04 -0700 (PDT) Date: Tue, 21 Oct 2014 22:57:01 +0200 From: Hagen Paul Pfeifer To: Michael Welzl Message-ID: <20141021205701.GA6629@virgo.local> References: <> <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BPIYGDGKlMUO9r5YwKASGc4_4CI Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:57:10 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michael Welzl | 2014-10-21 21:05:47 [+0200]: >> Question: what is the right IW for a given application? -> >> it is not application specific - it is link specific! > >Here I=E2=80=99m not so sure, unless we go for extremes of course, as in y= our IW50 >example. Generally I do see the point of Runa above, in trying to let short >flows finish fast and get out of the network, it=E2=80=99s a double benefi= t somehow. I also see Runa's point and I know that in 95% a user/programmer will setsockopt() IW to the wrong value - because he simple has no idea about the link. I don't consider IW50 as an extreme I already saw CDNs with a IW of 2= 0. So there is room left for more crazy values ;-) Furthermore, the "get packets quickly out of the pipe" argument will show i= n a different light when considered in a sensor network. If we have a valid information basis (TCP cache) the finish fast approach may work - but we mu= st make sure that the pipe is in principle capable for the short IWx burst. IWx results in bursts and some middle boxes are still not equipped for this (bufferbloat guys: yes, this world exist ;). >Interesting; while RFC 2140 is absolutely on my radar (we do some quite >closely related work in RMCAT), I forgot that it talks about IW. Can you >provide more detail about what is implemented in Linux for the IW there - I >thought by default none of this is happening for IW in Linux, all flows ju= st >get 10? IW is not cache driven in Linux - I don't wanted to claim this. But there is absolutely no restriction to design and implement an algorithm to do that! Joe's I-D may be a starting point (using packet loss indications, use a timeout after which the cached information is threated as outdated, ...). Similar to th RTT subsystem. >I agree that Ensemble Sharing could make sense for IW=E2=80=A6 however, th= anks to >ECMP, there is of course no guarantee that different connections to the sa= me >IP address really do traverse the same bottleneck. So an approach that uses >e.g. IW1 for later-joining connections to the same IP address may be doing >the exact right thing or may be too conservative, depending on whether ECMP >is in place or not. Further, by applying this limitation only on later >connections to the same IP address, it may not kick in often enough. To some degree: yes. On the other the shorter the time difference between flows the more likely the same path characteristics are still valid. Sure, cache timeouts should make sure that the information is outdated after a wh= ile - no doubt. >Alternatively, giving a different IW to flows depending on their size may = be >doing the right thing more or less often=E2=80=A6 either way it=E2=80=99s = heuristics I guess. >I think both options are worth considering. Generally, giving a large IW o= nly >to short flows does strike me as reasonable because long flows simply won= =E2=80=99t >benefit much from it. Probably - I must think about this. >My point in my previous email was only that no additional harm comes from >letting the application tell the transport layer a desired IW (or maybe >rather flow size, to allow transport to do the calculation), provided that= an >upper limit is imposed by the transport. Ok, got it. But then a setsockopt("SHORT_LIVED_FLOW") will be adequate too, right!? Setting the IW is really complicated from a programmer point of vie= w, even a network guru may choose the wrong value. I believe that this logic should be implemented and controlled in the Kernel. Anyway, I understand the application argument and it may provide - combined with the cached IW - a better behavior. Hagen --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRGyJ0ACgkQSiKNRZg1DCIargCghySXP0+ShY9C16YhFSQbFGjQ qGYAoIcZiDvvGhvWp8ip8Je8G9Mf0iUf =Vbhr -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From nobody Tue Oct 21 14:03:16 2014 Return-Path: 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 050B61A7009 for ; Tue, 21 Oct 2014 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 J0NBUhyUrIR2 for ; Tue, 21 Oct 2014 14:03:14 -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 9225E1A70FD for ; Tue, 21 Oct 2014 14:03:14 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9LL2pE1009104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 14:02:51 -0700 (PDT) Message-ID: <5446C9FB.7050006@isi.edu> Date: Tue, 21 Oct 2014 14:02:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> <54469C30.9070906@isi.edu> <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> <5446BD67.5030701@isi.edu> <8366E48E-8AE4-424F-A9DB-972D5A37CC5C@weston.borman.com> In-Reply-To: <8366E48E-8AE4-424F-A9DB-972D5A37CC5C@weston.borman.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/aDU_WfMB84ez8m1VkPgWcIeDeJU Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:03:16 -0000 On 10/21/2014 1:55 PM, David Borman wrote: > >> On Oct 21, 2014, at 3:09 PM, Joe Touch wrote: >> On 10/21/2014 11:50 AM, David Borman wrote: >>> >>>> On Oct 21, 2014, at 12:47 PM, Joe Touch wrote: >> ... >>>> You're thus proposing NEW requirements on option negotiation, and that >>>> ought to be clear in your document as well as considered in comparison >>>> to all existing and pending options. >>> >>> What new requirements? >> >> That options be negotiated exclusively by appearance in the SYN in each >> direction. > > You're reading things that aren’t there. There is no one mechanism for > enabling use of TCP options. That is my primary point. > Each option defines for itself how it is > to be used, including any enablement. For many existing options, enablement > is defined as the option being present in both a packet sent and received > with the SYN bit. Examples include Window Scale, Timestamps, and SACK Permitted. > > That is nothing new, and is not a requirement for any other TCP option. 4WHS won't work when options are not defined as being enabled by the option being present in both SYN segments of a 3WHS. > ... >>>> But it has to include *anything* that the client might want to ACK. >>> >>> No it doesn’t. It would only include options that it would still >>> like to be enabled, but weren’t included in the inbound SYN. Why >>> on earth would it offer up to enable options it doesn’t want to use? >> >> It has to send all the options that might be coming in the client's >> SYN/ACK. It has to read minds or be exhaustive. > ... > > Absolutely not. > > In the 4WHS, for options that are only enabled by their presence in the > SYN exchange, the servers SYN/ACK can contain additional options to allow > the client to agree to enable them by including them in it’s SYN/ACK. > That’s it. End of story. Again: #1 Client sends SYN with A, B -> #2 <- Server sends SYN/ACK with what? it can send A,B what else? #3 Client sends SYN/ACK with X,Y-> #4 <- server, never having seen X or Y MUST have had to send X AND Y in its SYN/ACK If all options are enabled by occurring in a SYN in both directions, we have to also note that #2 is the only SYN(ACK) the server sends. #2 SYN/ACK has to anticipate the options sent in #3 client SYN/ACK. How exactly does it do that? Doesn't it have to send ANY option that MIGHT be arriving in the client SYN/ACK - but it has to do that BEFORE the client sends it. Joe From nobody Tue Oct 21 14:46:44 2014 Return-Path: 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 712111A87B2 for ; Tue, 21 Oct 2014 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PYbspvL5OZfE for ; Tue, 21 Oct 2014 14:46:41 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801951A87B1 for ; Tue, 21 Oct 2014 14:46:41 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9LLkcIE008307; Tue, 21 Oct 2014 16:46:40 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <5446C9FB.7050006@isi.edu> Date: Tue, 21 Oct 2014 16:46:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <044EDEDD-3CC6-4B34-AFC5-857A87E04CB7@weston.borman.com> References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> <54469C30.9070906@isi.edu> <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> <5446BD67.5030701@isi.edu> <8366E48E-8AE4-424F-A9DB-972D5A37CC5C@weston.borman.com> <5446C9FB.7050006@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/q68luVweA7QQJkufUrJzmSktqZs Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:46:43 -0000 > On Oct 21, 2014, at 4:02 PM, Joe Touch wrote: > On 10/21/2014 1:55 PM, David Borman wrote: ... >> Each option defines for itself how it is >> to be used, including any enablement. For many existing options, = enablement >> is defined as the option being present in both a packet sent and = received >> with the SYN bit. Examples include Window Scale, Timestamps, and = SACK Permitted. >>=20 >> That is nothing new, and is not a requirement for any other TCP = option. >=20 > 4WHS won't work when options are not defined as being enabled by the > option being present in both SYN segments of a 3WHS. Options that don=E2=80=99t have the limitation that they have to be = exchanged in the initial SYN exchange probably aren=E2=80=99t affected by the lack = of option space in the initial SYN. The only options that don=E2=80=99t work with the second-chance = enablement that the 4WHS allows are those options that are unidirectional from the client, for example the CC option in T/TCP. ... > #1 Client sends SYN with A, B -> >=20 > #2 <- Server sends SYN/ACK > with what? it can send A,B > what else? >=20 > #3 Client sends SYN/ACK with X,Y-> >=20 > #4 <- server, never having seen X or Y > MUST have had to send X AND Y in > its SYN/ACK >=20 > If all options are enabled by occurring in a SYN in both directions, = we > have to also note that #2 is the only SYN(ACK) the server sends. >=20 > #2 SYN/ACK has to anticipate the options sent in #3 client SYN/ACK. And that=E2=80=99s where I disagree. The server is *not* trying to = anticipate what the *client* might send in the #3 SYN/ACK. The additional options in #2 server SYN/ACK are options that the *server* would like to enable that weren=E2=80=99t present in the #1 client SYN. The client can then = agree to enable some, all or none of them with the #3 SYN/ACK. If one uses your offer/confirm terminology, then #1 offers one set of options. #2 confirms some, all or none of those options, and also offers a second set of options. #3 confirms some, all or none of the second set of options. > How exactly does it do that? Doesn't it have to send ANY option that > MIGHT be arriving in the client SYN/ACK - but it has to do that BEFORE > the client sends it. The server doesn=E2=80=99t know or care what the client couldn=E2=80=99t = put into the initial SYN. It only knows what options were missing from the initial SYN that it would like to have enabled, and that=E2=80=99s what = it adds to the #2 SYN/ACK. -David From nobody Tue Oct 21 16:42:27 2014 Return-Path: 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 587991A883B for ; Tue, 21 Oct 2014 16:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 m2l_xWbLDG3z for ; Tue, 21 Oct 2014 16:42:25 -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 025231A8839 for ; Tue, 21 Oct 2014 16:42:24 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9LNg6iX015102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 16:42:06 -0700 (PDT) Message-ID: <5446EF4D.3090108@isi.edu> Date: Tue, 21 Oct 2014 16:42:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544047E3.8080900@isi.edu> <6A5AD7CB-EA2B-4FCD-B162-4D2929BC7B85@weston.borman.com> <544156C7.5040906@isi.edu> <21EB0FC2-EDF7-41CB-A0B5-A632FA78C7E9@weston.borman.com> <54419853.7040705@isi.edu> <08B20814-7C96-469F-AE0D-1B3E7C964322@weston.borman.com> <5441A65F.3080508@isi.edu> <544593A4.2090108@isi.edu> <96F21A43-3505-4A89-A976-10AF531C32C2@weston.borman.com> <54469C30.9070906@isi.edu> <2F22DAD4-109C-4BF7-9B59-51BBE503F5BC@weston.borman.com> <5446BD67.5030701@isi.edu> <8366E48E-8AE4-424F-A9DB-972D5A37CC5C@weston.borman.com> <5446C9FB.7050006@isi.edu> <044EDEDD-3CC6-4B34-AFC5-857A87E04CB7@weston.borman.com> In-Reply-To: <044EDEDD-3CC6-4B34-AFC5-857A87E04CB7@weston.borman.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/puTGrmNl3nZyfjeNza-Gxk8cxmE Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:42:26 -0000 On 10/21/2014 2:46 PM, David Borman wrote: ... > ... >> #1 Client sends SYN with A, B -> >> >> #2 <- Server sends SYN/ACK >> with what? it can send A,B >> what else? >> >> #3 Client sends SYN/ACK with X,Y-> >> >> #4 <- server, never having seen X or Y >> MUST have had to send X AND Y in >> its SYN/ACK >> >> If all options are enabled by occurring in a SYN in both directions, we >> have to also note that #2 is the only SYN(ACK) the server sends. >> >> #2 SYN/ACK has to anticipate the options sent in #3 client SYN/ACK. > > And that’s where I disagree. The server is *not* trying to anticipate > what the *client* might send in the #3 SYN/ACK. The additional options > in #2 server SYN/ACK are options that the *server* would like to enable > that weren’t present in the #1 client SYN. The client can then agree > to enable some, all or none of them with the #3 SYN/ACK. In that case, what happens with X,Y? They can't be confirmed in #2 because the server doesn't know they're desired yet, but the server might support them *IF* the client wants them, but might not have turned them on if it were to have initiated the connection. E.g., what if the server supports both TCP-MD5 and TCP-AO, but the client supports only one of those and it didn't fit in the #1 SYN? The server can't know which one to put in the #2 SYN/ACK but it's also prohibited from putting in both. However, if it doesn't put in either one, then neither MD5 nor AO will be successfully negotiated as active on the connection. Joe From nobody Tue Oct 21 17:00:25 2014 Return-Path: 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 EEE0D1A8843 for ; Tue, 21 Oct 2014 17:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 9V8oTIlgEdbr for ; Tue, 21 Oct 2014 17:00:22 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B221A883D for ; Tue, 21 Oct 2014 17:00:22 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9M000Q4015767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 17:00:00 -0700 (PDT) Message-ID: <5446F37F.7020007@isi.edu> Date: Tue, 21 Oct 2014 16:59:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hagen Paul Pfeifer , Runa Barik References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> In-Reply-To: <20141021192331.GB4851@virgo.local> Content-Type: text/plain; charset=windows-1252 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/j3C4LxMQX7NNQMP1JoXVDcZAZwY Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 00:00:24 -0000 A few points on this thread: - 2140 includes both ensemble and temporal sharing ensemble happens only when you have a concurrent set of connections, at which point you subtract from the window of the current ones to give to the new one temporal includes going back to the same place - subnet or specific IP - and can involve aging the window - we had a project here to look at whether the window could be predicted based on past behavior (e.g., time-based patterns, either time-of-day, day-of-week, etc.): http://www.isi.edu/aln/ The conclusion was that such patterns were not evident (at least when we did the experiment). - IW cannot be determined at the time of the connection per se The only way to do so would be to send IW segments into the net and see if they get there, which isn't so much a probe as just using that value as the initial window anyway. I continue to believe that IW can be adapted over loooong periods of time using information on past connections as network behavior evolves as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is definitely needed. Joe From nobody Tue Oct 21 18:31:18 2014 Return-Path: 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 BF3D71A8935 for ; Tue, 21 Oct 2014 18:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 t-W0zWMcSxCp for ; Tue, 21 Oct 2014 18:31:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8F01A1A43 for ; Tue, 21 Oct 2014 18:31:15 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9M1UgeS021476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 18:30:42 -0700 (PDT) Message-ID: <544708C1.7020006@isi.edu> Date: Tue, 21 Oct 2014 18:30:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=utf-8 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/nmMgcWGeF53eEHn2yrHIc2mXyaU Subject: [tcpm] simultaneous open with different options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 01:31:16 -0000 Hi, all, One of the questions that has kept coming up regarding SYN option extension has to do with options that differ during simultaneous open. IMO, it'd be useful to understand what happens in the current case before assuming we can solve this case for extensions. Here's the scenario host A host B SYN w/X -> <- SYN w/Y What happens next? AFAICT, it depends on a few things: - whether host A supports Y - whether host B supports X I.e., let's say that: host A supports Y host B does NOT support X in that case, the next step would be: host A host B SYN/ACK w/XY -> <- SYN/ACK w/- I.e., A supports both X and Y, and B supports neither. At this point, the final ACK is critical to the completion of the exchange, because it's where A finds out that neither option should be used: ACK w/- -> <- ACK w/- (these ACKs happen if both sides agree to skip the options they requested. if not, then they drop the connection and send a RST) Is there any agreement on this point? Joe From nobody Tue Oct 21 18:35:22 2014 Return-Path: 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 E01F41A8965 for ; Tue, 21 Oct 2014 18:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 zpCxmjGKMwMN for ; Tue, 21 Oct 2014 18:35:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8BD1A893A for ; Tue, 21 Oct 2014 18:35:18 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s9M1Yjlf022517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Oct 2014 18:34:45 -0700 (PDT) Message-ID: <544709B5.3030605@isi.edu> Date: Tue, 21 Oct 2014 18:34:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=utf-8 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/IBxSC3PaTePDGV-j_NHZTivyUEk Subject: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 01:35:20 -0000 Hi, all, Another key issue that has arisen in the discussion of option processing is whether options can be enabled during a SYN/ACK. I think that Dave Borman and I agree, but want to hear from others: Can an option be enabled on the SYN/ACK? E.g.: host A host B SYN w/X -> <- SYN/ACK w/X,Y What does A do here? i) always send ACK w/X ii) send ACK w/X,Y if it supports Y or just ACK w/X if not iii) send ACK w/- AFAICT, Dave and I agree that the answer is (i). Does anyone else agree? A key aspect of this question is whether the options in the ACK have any utility, or whether the SYN, SYN/ACK exchange is the only exchange that matters for option negotiation. Joe From nobody Tue Oct 21 20:54:29 2014 Return-Path: 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 901FF1A8A7F for ; Tue, 21 Oct 2014 20:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 t_f4ToUIPLWC for ; Tue, 21 Oct 2014 20:54:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768F51A8A7C for ; Tue, 21 Oct 2014 20:54:25 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 03390278216 for ; Wed, 22 Oct 2014 12:54:22 +0900 (JST) Received: by mail-wi0-f176.google.com with SMTP id hi2so188946wib.15 for ; Tue, 21 Oct 2014 20:54:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.205 with SMTP id t13mr46271179wjq.55.1413950060617; Tue, 21 Oct 2014 20:54:20 -0700 (PDT) Received: by 10.194.3.82 with HTTP; Tue, 21 Oct 2014 20:54:20 -0700 (PDT) In-Reply-To: <544709B5.3030605@isi.edu> References: <544709B5.3030605@isi.edu> Date: Tue, 21 Oct 2014 20:54:20 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=047d7ba9737e17e5ed0505fae75b Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/E02hkBejnRLsBTOH-LlEL26hJCw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 03:54:27 -0000 --047d7ba9737e17e5ed0505fae75b Content-Type: text/plain; charset=UTF-8 (as an individual of course..) I'm wondering if all negotiations need to be negotiated. For a option like window scale, I believe it has to be negotiated. I also believe it should be included in the third ACK so that we can be robust against the case where the option in SYN/ACK has been removed. (although it's not a perfect protection) However, I'm not very sure if we should include MSS option in the third ACK. I'm thinking that there might be two different types of options. One requires negotiation. The other is used for informational, something like: "BTW, here's my info. you can use it for what ever you want." So, my preference for now is it depends on each option. Please let me know if I overlook something. Thanks, -- Yoshi On Tue, Oct 21, 2014 at 6:34 PM, Joe Touch wrote: > Hi, all, > > Another key issue that has arisen in the discussion of option processing > is whether options can be enabled during a SYN/ACK. > > I think that Dave Borman and I agree, but want to hear from others: > > Can an option be enabled on the SYN/ACK? > > E.g.: > > host A host B > > SYN w/X -> > > <- SYN/ACK w/X,Y > > > What does A do here? > > i) always send ACK w/X > > ii) send ACK w/X,Y if it supports Y > or just ACK w/X if not > > iii) send ACK w/- > > AFAICT, Dave and I agree that the answer is (i). Does anyone else agree? > > A key aspect of this question is whether the options in the ACK have any > utility, or whether the SYN, SYN/ACK exchange is the only exchange that > matters for option negotiation. > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --047d7ba9737e17e5ed0505fae75b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(as an individual of course..)

I'm wondering if all negotiations need to be negotiated. For a optio= n like window scale, I believe it has to be negotiated.
I also be= lieve it should be included in the third ACK so that we can be robust again= st the case where the option in SYN/ACK has been removed. (although it'= s not a perfect protection)
However, I'm not very sure if we = should include MSS option in the third ACK.=C2=A0
I'm thi= nking that there might be two different types of options. One requires nego= tiation.=C2=A0
The other is used for informational, something lik= e: "BTW, here's my info. you can use it for what ever you want.&qu= ot;

So, my preference for now is it depends on eac= h option. Please let me know if I overlook something.

<= div>Thanks,
--
Yoshi


On Tue, Oct 21, 2014 at 6:34 PM= , Joe Touch <touch@isi.edu> wrote:
Hi, all,

Another key issue that has arisen in the discussion of option processing is whether options can be enabled during a SYN/ACK.

I think that Dave Borman and I agree, but want to hear from others:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Can an option be enabled on the SYN/ACK?

E.g.:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 host A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 host B

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SYN w/X ->

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <- SYN/ACK w/X,Y


What does A do here?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 i) always send ACK w/X

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ii) send ACK w/X,Y if it supports Y
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or just ACK w/X if = not

=C2=A0 =C2=A0 =C2=A0 =C2=A0 iii) send ACK w/-

AFAICT, Dave and I agree that the answer is (i). Does anyone else agree?
A key aspect of this question is whether the options in the ACK have any utility, or whether the SYN, SYN/ACK exchange is the only exchange that
matters for option negotiation.

Joe
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--047d7ba9737e17e5ed0505fae75b-- From nobody Tue Oct 21 21:34:34 2014 Return-Path: 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 805E21A8A90 for ; Tue, 21 Oct 2014 21:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 seesWyCO6phS for ; Tue, 21 Oct 2014 21:34:30 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EBF1A8A8D for ; Tue, 21 Oct 2014 21:34:29 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5AF7527819E for ; Wed, 22 Oct 2014 13:34:28 +0900 (JST) Received: by mail-qc0-f181.google.com with SMTP id r5so2063275qcx.40 for ; Tue, 21 Oct 2014 21:34:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.61.7 with SMTP id r7mr53052964qah.9.1413952466688; Tue, 21 Oct 2014 21:34:26 -0700 (PDT) Received: by 10.96.195.106 with HTTP; Tue, 21 Oct 2014 21:34:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Oct 2014 21:34:26 -0700 Message-ID: From: Yoshifumi Nishida To: David Borman Content-Type: multipart/alternative; boundary=001a11c3d40281a2630505fb76bd Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/U622DABEeHUdnA9K1xT3L7TyrAY Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP Four-Way Handshake X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 04:34:32 -0000 --001a11c3d40281a2630505fb76bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, (as an individual of course..) I personally like this idea from the following reasons. 1: use SYN-ACK to initiate feature negotiation (as discussed in the previous thread) 2: it can expand SYN options space to 80 octets without overriding DO field. It might be more middlebox friendly. 3: we might be able to re-design syn cookie solution that can address the previous issues. 4: even if an option in SYN/ACK has been removed by middleboxes, it can reliably find this situation. 5: in mptcp, initiating subflow requires 4 packet exchanges. With 4-way handshake mechanism, we might be able to do this with non-mptcp-specific way. 6: similar to 5, it might be useful some secure negotiations where we don't want to put something that requires computations in SYN, but want to perform some cryptic algorithms in later packet exchanges. (as one of co-chairs..) When you submit new version, please include -tcpm- in the draft's name so that we can track it easily. Regards, -- Yoshi On Tue, Oct 14, 2014 at 2:44 PM, David Borman wrote= : > Hi, > > I=E2=80=99ve just posted draft-borman-tcp4way-00.txt, which describes a 4= -Way TCP > handshake that is intended to allow the TCP EDO option to be used during > the initial SYN exchange. This was mentioned during the TCPM WG at the > last IETF meeting. Please see the draft for more details. > > -David Borman > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11c3d40281a2630505fb76bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

(as an individual of course..= )
I personally like this idea from the following reasons.

1: use SYN-ACK to initiate feature negotiation (as discus= sed in the previous thread)

2: it can expand SYN o= ptions space to 80 octets without overriding DO field. It might be more mid= dlebox friendly.

3: we might be able to re-design = syn cookie solution that can address the previous issues.

4: even if an option in SYN/ACK has been removed by middleboxes, it= can reliably find this situation.

5: in mptcp, in= itiating subflow requires 4 packet exchanges. With 4-way handshake mechanis= m, we might be able to do this with non-mptcp-specific way.=C2=A0

6: similar to 5, it might be useful some secure negotiation= s where we don't want to put something that requires computations in SY= N, but want to perform some cryptic algorithms in later packet exchanges.


(as one of co-chairs..)
When you submit new version, please include -tcpm- in the draf= t's name so that we can track it easily.

Regar= ds,
--
Yoshi



On Tue, Oct 14, 201= 4 at 2:44 PM, David Borman <dab@weston.borman.com> wrote= :
Hi,

I=E2=80=99ve just posted draft-borman-tcp4way-00.txt, which describes a 4-W= ay TCP handshake that is intended to allow the TCP EDO option to be used du= ring the initial SYN exchange.=C2=A0 This was mentioned during the TCPM WG = at the last IETF meeting.=C2=A0 Please see the draft for more details.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -David Borman
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--001a11c3d40281a2630505fb76bd-- From nobody Tue Oct 21 21:44:00 2014 Return-Path: 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 5BD491A8A97 for ; Tue, 21 Oct 2014 21:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wZFnOxVPMtue for ; Tue, 21 Oct 2014 21:43:56 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id BC8B71A8A8D for ; Tue, 21 Oct 2014 21:43:55 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1Xgnlq-0004Ka-00; Wed, 22 Oct 2014 00:43:38 -0400 From: Tim Shepard To: Joe Touch In-reply-to: Your message of Tue, 21 Oct 2014 18:34:45 -0700. <544709B5.3030605@isi.edu> Date: Wed, 22 Oct 2014 00:43:38 -0400 Message-Id: Sender: Tim Shepard Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Iv1_sPXlCk_EInUpXuFP2RF-bpE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 04:43:58 -0000 I'm not so sure that it makes sense to try and definitively give answers to your questions for future TCP options we haven't even invented yet. It's not clear to me that there's any value in deciding things now that would preclude doing something useful in the future that might be contrary to some decision we might make now. It's not like there's generic option-negotiation code in any stack implementation (that I'm aware of) where code was written to negotiate an option on or off where the author of that code has no clue what the option is or is unable to know what its semantics are. So I would expect (hope) that someone implementing a new TCP option would be able to do the right thing for that particular sort of option. Yes, allowing options to show up for the first time on the 2nd packet (of the 3 or 4 WHS) is new and we don't have stacks that do that now, so maybe we need to think some things through to make sure the right things happen. But it is not obvious to me that we can do so for any and all options (past and future) in a generic way that would be the right thing for all (future) options. And yes, the potential interactions between options might get more complicated. But again, I'm not sure we can make any good decisions without getting specific about which particular options we are talking about. And it's probably easier to figure out what the right thing to do would be in the case of specific options. I guess we should think carefully about what a stack should do if it sees an option that it doesn't understand. Today, if an option that you don't understand shows up on a SYN, you just ignore it. And I think we would pretty much have to say that if a new option shows up on a SYN/ACK that you don't understand, just ignore it. (RST in that case, if deployed, would preclude being able to extend how some future option gets negotiated.) Imagine that you ran out of option space on the initial SYN and were unable to include all the options you would have liked to. But at least one of the options you included on that initial SYN implies that you are modern enough to cope with additional options appearing for the first time on the SYN/ACK. Say that the window scale was one of the options ommitted from the initial SYN due to lack of space. The responding host may now include the window scale option on the SYN/ACK packet. In this case, since we're not sure that the initial host even implements window scaling, the SYN/ACK packet's window will be an unscaled value. If the initiating host includes a window scale option on the packet that carries the ACK of the SYN/ACK, then window scale has been turned on (and that packet carries a scaled window). If the ACK of the SYN/ACK does not include a window scale option (and window scale option was not present on the SYN), then proceed with no window scaling. Did I get that one right? (If not, we can probably figure out what the right thing to do is.) All of this more modern mechanism would only be active if there was *some* option on the initial SYN that implied extendend option negotiation is allowed. And window scale seems like it is exactly the sort of option whose utility is not damaged (much at all) by delaying its negotiation by half a round trip time. There may (someday, if not today) be other such options. Oh, I guess it doesn't work so well if the server is not modern enough to initiate the negotiation of that option on the second half of the first round trip. Then you wind up without the option turned on. So maybe the initiator needs a hint of the servers capabilities. But if we were trying to add a window scale option after we had succeeded in extending the option space with an option that is carried on the SYN (perhaps without any extra option space there) and then additional option space being available on the SYN/ACK and all subsequent packets), then we could have done window scale this way, and things would be OK. If going forward we ensure that any stack that implements new options (that won't fit today in the room remaining in TCP option space) allow for this sort of option negotiation starting with the SYN/ACK (where there can somehow be more space for options), then we can deploy those options in the SYN/ACK (until we run out of MTU) or even later (if we can get the later option negotiation explicitly acknowledged after the SYNs have already been acknowledged). -Tim Shepard shep@alum.mit.edu From nobody Wed Oct 22 02:13:33 2014 Return-Path: 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 E52941A88D4 for ; Wed, 22 Oct 2014 02:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tmRjwIgfnKYH for ; Wed, 22 Oct 2014 02:13:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B6C1A0390 for ; Wed, 22 Oct 2014 02:13:29 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9M9DQJo021773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 05:13:27 -0400 Received: from [10.36.6.236] (vpn1-6-236.ams2.redhat.com [10.36.6.236]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9M9DNWs005585 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 05:13:25 -0400 Message-ID: <54477533.8080202@redhat.com> Date: Wed, 22 Oct 2014 11:13:23 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: <> <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> In-Reply-To: <20141021205701.GA6629@virgo.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rC0MavMy_onLqY8-dxfEmhAdu_8 Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 09:13:32 -0000 On 10/21/2014 10:57 PM, Hagen Paul Pfeifer wrote: > * Michael Welzl | 2014-10-21 21:05:47 [+0200]: > >>> Question: what is the right IW for a given application? -> >>> it is not application specific - it is link specific! >> >> Here I’m not so sure, unless we go for extremes of course, as in your IW50 >> example. Generally I do see the point of Runa above, in trying to let short >> flows finish fast and get out of the network, it’s a double benefit somehow. > > I also see Runa's point and I know that in 95% a user/programmer will > setsockopt() IW to the wrong value - because he simple has no idea about the > link. I don't consider IW50 as an extreme I already saw CDNs with a IW of 20. > So there is room left for more crazy values ;-) You probably have seen this article already: http://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ > Furthermore, the "get packets quickly out of the pipe" argument will show in a > different light when considered in a sensor network. If we have a valid > information basis (TCP cache) the finish fast approach may work - but we must > make sure that the pipe is in principle capable for the short IWx burst. IWx > results in bursts and some middle boxes are still not equipped for this > (bufferbloat guys: yes, this world exist ;). > >> Interesting; while RFC 2140 is absolutely on my radar (we do some quite >> closely related work in RMCAT), I forgot that it talks about IW. Can you >> provide more detail about what is implemented in Linux for the IW there - I >> thought by default none of this is happening for IW in Linux, all flows just >> get 10? The default is 10, but you can have individual IWx settings on a per-route basis. See the implementation in tcp_init_cwnd(). From nobody Wed Oct 22 02:58:26 2014 Return-Path: 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 B4CF01A8F49 for ; Wed, 22 Oct 2014 02:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 brH6Ed2e5WJG for ; Wed, 22 Oct 2014 02:58:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66561A038E for ; Wed, 22 Oct 2014 02:58:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU86579; Wed, 22 Oct 2014 09:58:19 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Oct 2014 10:58:04 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 22 Oct 2014 17:57:57 +0800 From: "Huangyihong (Rachel)" To: Hagen Paul Pfeifer , Michael Welzl Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JremrgmuTy1lke6ElwLaFnR9pw6BACAgAAO5YCAAFHTgIAAHxSAgAEpTkA= Date: Wed, 22 Oct 2014 09:57:56 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com> References: <> <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> In-Reply-To: <20141021205701.GA6629@virgo.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sXubBRHnw0wDGYpNwsYZATe_Igo Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 09:58:23 -0000 SGkgSGFnZW4sIE1pY2hlYWwsIFJ1bmEsIEpvZSwgYW5kIGFsbCwNCg0KVGhhbmtzIGZvciB5b3Vy IGRpc2N1c3Npb24gb24gdGhpcyBkcmFmdC4gV2UgYmFyZWx5IGNhdGNoIHVwIHdpdGggeW91ciBn dXlzXl4uIFdlJ3JlIG5ldyB0byB0aGUgdHJhbnNwb3J0IGFyZWEsIGFuZCB2ZXJ5IGhhcHB5IHRv IHNlZSBzbyBtYW55IGJyaWxsaWFudCBjb21tZW50cyBmcm9tIGFsbCBvZiB5b3UuIFRoZXkncmUg aGlnaGx5IGFwcHJlY2lhdGVkLg0KDQpUaGUgbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRo YXQgd2UgdGhpbmsgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBtYXkgaGF2ZSB0aGVpciBkaWZmZXJl bnQgcmVxdWlyZW1lbnRzIGZvciBJVyB0byBhY2hpZXZlIGJlc3QgcGVyZm9ybWFuY2UuIEFuZCBt YXliZSBkaWZmZXJlbnQgZmxvd3MgZm9yIG9uZSBhcHBsaWNhdGlvbiBtYXkgaGF2ZSBkaWZmZXJl bnQgcmVxdWlyZW1lbnRzIChlLmcuLCBzaG9ydCBmbG93cyBtZW50aW9uZWQgYnkgUnVuYSkuIEN1 cnJlbnQgZ2xvYmFsIElXIHBhcmFtZXRlciBtYXkgbm90IHdlbGwgc2F0aXNmeSBzdWNoIHJlcXVp cmVtZW50cy4gU28gd2UgYnJpbmcgdXAgaXQgZm9yIGRpc2N1c3Npb246IGNvbmZpZ3VyZSBJVyBk eW5hbWljYWxseSBieSBBUEkuIEhvd2V2ZXIsIHdlIGFyZSBub3Qgc3VnZ2VzdGluZyB0aGF0IHVz ZXJzIGltcGxlbWVudCBpdCB3aXRoIGV4YWdnZXJhdGVkIHZhbHVlcy4gV2UgdGhpbmsgZHluYW1p Y2FsbHkgc2V0dGluZyBJVyBpbiBhIHNhZmUgcmFuZ2Ugd291bGQgYmUgbm8gaGFybS4gVGhhdCBp cyB0byBzYXkgdGhlcmUgbXVzdCBoYXZlIGEgTUFYIElXIHRvIHJlc3RyaWN0IHRoZSBJVyB2YWx1 ZSBpbiBhbiBhcHByb3ByaWF0ZSByYW5nZSwgZS5nLiwgY3VycmVudCBJVz0xMCwgbWF5YmUgbGFy Z2VyIGluIHRoZSBmdXR1cmUuDQoNClRoZSBpZGVhIE1pY2hhZWwgbWVudGlvbmVkIHRoYXQgdXNp bmcgZmxvdyBzaXplIGluc3RlYWQgb2YgSVcgYXMgaW5wdXQgdG8gdGhlIEFQSSBzZWVtcyBnb29k IHRvIG1lLiBCdXQgc29tZSBhbGdvcml0aG1zIG11c3QgYmUgZmlndXJlZCBvdXQgaW4gdGhlIHRy YW5zcG9ydCBsYXllciB0byBjb252ZXJ0IGFwcGxpY2F0aW9ucyBwYXJhbWV0ZXJzIGxpa2UgZmxv dyBzaXplIHRvIElXLiBJdCBhbHNvIG1heSBiZSBhIHZlcnkgaGFyZCB3b3JrLg0KDQpBbnl3YXks IHdlJ3JlIGp1c3QgYXQgdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoaXMgd29yay4gQW5kIHdlIGRp ZG4ndCBkbyBhIGxvdCBvZiBleHBlcmltZW50cy4gQnV0IHdlIHdpbGwuIA0KDQpCUiwNCkppYW5q aWUgJiBSYWNoZWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0Y3Bt IFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFnZW4gUGF1bCBQ ZmVpZmVyDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyMiwgMjAxNCA0OjU3IEFNDQo+IFRv OiBNaWNoYWVsIFdlbHpsDQo+IENjOiB0Y3BtQGlldGYub3JnOyBKb2UgVG91Y2gNCj4gU3ViamVj dDogUmU6IFt0Y3BtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LXlvdS10 Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMC50eHQNCj4gDQo+ICogTWljaGFl bCBXZWx6bCB8IDIwMTQtMTAtMjEgMjE6MDU6NDcgWyswMjAwXToNCj4gDQo+ID4+IFF1ZXN0aW9u OiB3aGF0IGlzIHRoZSByaWdodCBJVyBmb3IgYSBnaXZlbiBhcHBsaWNhdGlvbj8gLT4gaXQgaXMg bm90DQo+ID4+IGFwcGxpY2F0aW9uIHNwZWNpZmljIC0gaXQgaXMgbGluayBzcGVjaWZpYyENCj4g Pg0KPiA+SGVyZSBJ4oCZbSBub3Qgc28gc3VyZSwgdW5sZXNzIHdlIGdvIGZvciBleHRyZW1lcyBv ZiBjb3Vyc2UsIGFzIGluIHlvdXINCj4gPklXNTAgZXhhbXBsZS4gR2VuZXJhbGx5IEkgZG8gc2Vl IHRoZSBwb2ludCBvZiBSdW5hIGFib3ZlLCBpbiB0cnlpbmcgdG8NCj4gPmxldCBzaG9ydCBmbG93 cyBmaW5pc2ggZmFzdCBhbmQgZ2V0IG91dCBvZiB0aGUgbmV0d29yaywgaXTigJlzIGEgZG91Ymxl IGJlbmVmaXQNCj4gc29tZWhvdy4NCj4gDQo+IEkgYWxzbyBzZWUgUnVuYSdzIHBvaW50IGFuZCBJ IGtub3cgdGhhdCBpbiA5NSUgYSB1c2VyL3Byb2dyYW1tZXIgd2lsbA0KPiBzZXRzb2Nrb3B0KCkg SVcgdG8gdGhlIHdyb25nIHZhbHVlIC0gYmVjYXVzZSBoZSBzaW1wbGUgaGFzIG5vIGlkZWEgYWJv dXQgdGhlDQo+IGxpbmsuIEkgZG9uJ3QgY29uc2lkZXIgSVc1MCBhcyBhbiBleHRyZW1lIEkgYWxy ZWFkeSBzYXcgQ0ROcyB3aXRoIGEgSVcgb2YgMjAuDQo+IFNvIHRoZXJlIGlzIHJvb20gbGVmdCBm b3IgbW9yZSBjcmF6eSB2YWx1ZXMgOy0pDQo+IA0KPiBGdXJ0aGVybW9yZSwgdGhlICJnZXQgcGFj a2V0cyBxdWlja2x5IG91dCBvZiB0aGUgcGlwZSIgYXJndW1lbnQgd2lsbCBzaG93IGluIGENCj4g ZGlmZmVyZW50IGxpZ2h0IHdoZW4gY29uc2lkZXJlZCBpbiBhIHNlbnNvciBuZXR3b3JrLiBJZiB3 ZSBoYXZlIGEgdmFsaWQNCj4gaW5mb3JtYXRpb24gYmFzaXMgKFRDUCBjYWNoZSkgdGhlIGZpbmlz aCBmYXN0IGFwcHJvYWNoIG1heSB3b3JrIC0gYnV0IHdlIG11c3QNCj4gbWFrZSBzdXJlIHRoYXQg dGhlIHBpcGUgaXMgaW4gcHJpbmNpcGxlIGNhcGFibGUgZm9yIHRoZSBzaG9ydCBJV3ggYnVyc3Qu IElXeA0KPiByZXN1bHRzIGluIGJ1cnN0cyBhbmQgc29tZSBtaWRkbGUgYm94ZXMgYXJlIHN0aWxs IG5vdCBlcXVpcHBlZCBmb3IgdGhpcw0KPiAoYnVmZmVyYmxvYXQgZ3V5czogeWVzLCB0aGlzIHdv cmxkIGV4aXN0IDspLg0KPiANCj4gPkludGVyZXN0aW5nOyB3aGlsZSBSRkMgMjE0MCBpcyBhYnNv bHV0ZWx5IG9uIG15IHJhZGFyICh3ZSBkbyBzb21lIHF1aXRlDQo+ID5jbG9zZWx5IHJlbGF0ZWQg d29yayBpbiBSTUNBVCksIEkgZm9yZ290IHRoYXQgaXQgdGFsa3MgYWJvdXQgSVcuIENhbg0KPiA+ eW91IHByb3ZpZGUgbW9yZSBkZXRhaWwgYWJvdXQgd2hhdCBpcyBpbXBsZW1lbnRlZCBpbiBMaW51 eCBmb3IgdGhlIElXDQo+ID50aGVyZSAtIEkgdGhvdWdodCBieSBkZWZhdWx0IG5vbmUgb2YgdGhp cyBpcyBoYXBwZW5pbmcgZm9yIElXIGluIExpbnV4LA0KPiA+YWxsIGZsb3dzIGp1c3QgZ2V0IDEw Pw0KPiANCj4gSVcgaXMgbm90IGNhY2hlIGRyaXZlbiBpbiBMaW51eCAtIEkgZG9uJ3Qgd2FudGVk IHRvIGNsYWltIHRoaXMuIEJ1dCB0aGVyZSBpcw0KPiBhYnNvbHV0ZWx5IG5vIHJlc3RyaWN0aW9u IHRvIGRlc2lnbiBhbmQgaW1wbGVtZW50IGFuIGFsZ29yaXRobSB0byBkbyB0aGF0IQ0KPiBKb2Un cyBJLUQgbWF5IGJlIGEgc3RhcnRpbmcgcG9pbnQgKHVzaW5nIHBhY2tldCBsb3NzIGluZGljYXRp b25zLCB1c2UgYSB0aW1lb3V0DQo+IGFmdGVyIHdoaWNoIHRoZSBjYWNoZWQgaW5mb3JtYXRpb24g aXMgdGhyZWF0ZWQgYXMgb3V0ZGF0ZWQsIC4uLikuDQo+IFNpbWlsYXIgdG8gdGggUlRUIHN1YnN5 c3RlbS4NCj4gDQo+ID5JIGFncmVlIHRoYXQgRW5zZW1ibGUgU2hhcmluZyBjb3VsZCBtYWtlIHNl bnNlIGZvciBJV+KApiBob3dldmVyLCB0aGFua3MNCj4gPnRvIEVDTVAsIHRoZXJlIGlzIG9mIGNv dXJzZSBubyBndWFyYW50ZWUgdGhhdCBkaWZmZXJlbnQgY29ubmVjdGlvbnMgdG8NCj4gPnRoZSBz YW1lIElQIGFkZHJlc3MgcmVhbGx5IGRvIHRyYXZlcnNlIHRoZSBzYW1lIGJvdHRsZW5lY2suIFNv IGFuDQo+ID5hcHByb2FjaCB0aGF0IHVzZXMgZS5nLiBJVzEgZm9yIGxhdGVyLWpvaW5pbmcgY29u bmVjdGlvbnMgdG8gdGhlIHNhbWUNCj4gPklQIGFkZHJlc3MgbWF5IGJlIGRvaW5nIHRoZSBleGFj dCByaWdodCB0aGluZyBvciBtYXkgYmUgdG9vDQo+ID5jb25zZXJ2YXRpdmUsIGRlcGVuZGluZyBv biB3aGV0aGVyIEVDTVAgaXMgaW4gcGxhY2Ugb3Igbm90LiBGdXJ0aGVyLCBieQ0KPiA+YXBwbHlp bmcgdGhpcyBsaW1pdGF0aW9uIG9ubHkgb24gbGF0ZXIgY29ubmVjdGlvbnMgdG8gdGhlIHNhbWUg SVAgYWRkcmVzcywgaXQNCj4gbWF5IG5vdCBraWNrIGluIG9mdGVuIGVub3VnaC4NCj4gDQo+IFRv IHNvbWUgZGVncmVlOiB5ZXMuIE9uIHRoZSBvdGhlciB0aGUgc2hvcnRlciB0aGUgdGltZSBkaWZm ZXJlbmNlIGJldHdlZW4NCj4gZmxvd3MgdGhlIG1vcmUgbGlrZWx5IHRoZSBzYW1lIHBhdGggY2hh cmFjdGVyaXN0aWNzIGFyZSBzdGlsbCB2YWxpZC4gU3VyZSwgY2FjaGUNCj4gdGltZW91dHMgc2hv dWxkIG1ha2Ugc3VyZSB0aGF0IHRoZSBpbmZvcm1hdGlvbiBpcyBvdXRkYXRlZCBhZnRlciBhIHdo aWxlDQo+IC0gbm8gZG91YnQuDQo+IA0KPiA+QWx0ZXJuYXRpdmVseSwgZ2l2aW5nIGEgZGlmZmVy ZW50IElXIHRvIGZsb3dzIGRlcGVuZGluZyBvbiB0aGVpciBzaXplDQo+ID5tYXkgYmUgZG9pbmcg dGhlIHJpZ2h0IHRoaW5nIG1vcmUgb3IgbGVzcyBvZnRlbuKApiBlaXRoZXIgd2F5IGl04oCZcyBo ZXVyaXN0aWNzIEkNCj4gZ3Vlc3MuDQo+ID5JIHRoaW5rIGJvdGggb3B0aW9ucyBhcmUgd29ydGgg Y29uc2lkZXJpbmcuIEdlbmVyYWxseSwgZ2l2aW5nIGEgbGFyZ2UNCj4gPklXIG9ubHkgdG8gc2hv cnQgZmxvd3MgZG9lcyBzdHJpa2UgbWUgYXMgcmVhc29uYWJsZSBiZWNhdXNlIGxvbmcgZmxvd3MN Cj4gPnNpbXBseSB3b27igJl0IGJlbmVmaXQgbXVjaCBmcm9tIGl0Lg0KPiANCj4gUHJvYmFibHkg LSBJIG11c3QgdGhpbmsgYWJvdXQgdGhpcy4NCj4gDQo+ID5NeSBwb2ludCBpbiBteSBwcmV2aW91 cyBlbWFpbCB3YXMgb25seSB0aGF0IG5vIGFkZGl0aW9uYWwgaGFybSBjb21lcw0KPiA+ZnJvbSBs ZXR0aW5nIHRoZSBhcHBsaWNhdGlvbiB0ZWxsIHRoZSB0cmFuc3BvcnQgbGF5ZXIgYSBkZXNpcmVk IElXIChvcg0KPiA+bWF5YmUgcmF0aGVyIGZsb3cgc2l6ZSwgdG8gYWxsb3cgdHJhbnNwb3J0IHRv IGRvIHRoZSBjYWxjdWxhdGlvbiksDQo+ID5wcm92aWRlZCB0aGF0IGFuIHVwcGVyIGxpbWl0IGlz IGltcG9zZWQgYnkgdGhlIHRyYW5zcG9ydC4NCj4gDQo+IE9rLCBnb3QgaXQuIEJ1dCB0aGVuIGEg c2V0c29ja29wdCgiU0hPUlRfTElWRURfRkxPVyIpIHdpbGwgYmUgYWRlcXVhdGUgdG9vLA0KPiBy aWdodCE/IFNldHRpbmcgdGhlIElXIGlzIHJlYWxseSBjb21wbGljYXRlZCBmcm9tIGEgcHJvZ3Jh bW1lciBwb2ludCBvZiB2aWV3LA0KPiBldmVuIGEgbmV0d29yayBndXJ1IG1heSBjaG9vc2UgdGhl IHdyb25nIHZhbHVlLiBJIGJlbGlldmUgdGhhdCB0aGlzIGxvZ2ljDQo+IHNob3VsZCBiZSBpbXBs ZW1lbnRlZCBhbmQgY29udHJvbGxlZCBpbiB0aGUgS2VybmVsLg0KPiANCj4gQW55d2F5LCBJIHVu ZGVyc3RhbmQgdGhlIGFwcGxpY2F0aW9uIGFyZ3VtZW50IGFuZCBpdCBtYXkgcHJvdmlkZSAtIGNv bWJpbmVkDQo+IHdpdGggdGhlIGNhY2hlZCBJVyAtIGEgYmV0dGVyIGJlaGF2aW9yLg0KPiANCj4g SGFnZW4NCg0K From runabk@ulrik.uio.no Wed Oct 22 05:03:20 2014 Return-Path: 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 9B3B01A900A for ; Wed, 22 Oct 2014 05:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.669, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 XydeJi5ifABn for ; Wed, 22 Oct 2014 05:03:18 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [129.240.10.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E171A8AFA for ; Wed, 22 Oct 2014 05:03:18 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgudJ-0006U7-3v for tcpm@ietfa.amsl.com; Wed, 22 Oct 2014 14:03:17 +0200 Received: from w3prod-wm03.uio.no ([129.240.4.40] helo=webmail.uio.no) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user runabk (Exim 4.80) (envelope-from ) id 1XgudI-0006uJ-Lp for tcpm@ietfa.amsl.com; Wed, 22 Oct 2014 14:03:17 +0200 Received: from 1x-193-157-207-0.uio.no ([193.157.207.0]) by webmail.uio.no with HTTP (HTTP/1.1 POST); Wed, 22 Oct 2014 14:03:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Oct 2014 14:03:16 +0200 From: runabk To: In-Reply-To: <20141022120251.2B87C1A90B3@ietfa.amsl.com> References: <20141022120251.2B87C1A90B3@ietfa.amsl.com> Message-ID: <9dd8141b4db24f821ed7b64da31410fd@ulrik.uio.no> X-Sender: runabk@ulrik.uio.no User-Agent: Roundcube Webmail/hz/2m6f.frs/uio-2 X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 7 sum msgs/h 2 total rcpts 124 max rcpts/h 8 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AC776D6DD869779290E6C1A286ED35CF412F68FB X-UiO-SPAM-Test: remote_host: 129.240.4.40 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1477002 max/h 477 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XQYZjc6Wd5kj4VGIZ4wgkwkXuBA Subject: Re: [tcpm] =?utf-8?q?Confirm=3A_tcpm=40ietfa=2Eamsl=2Ecom=3AVEec6wwKS?= =?utf-8?q?jJ0=3AR4I3VNm2W3ETIC=5FdZuWXBc1u-7qG7KNugeXGtg?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:04:37 -0000 On 2014-10-22 14:02, tcpm@ietfa.amsl.com wrote: > Confirmation of list posting -- confirmation ID: VEec6wwKSjJ0 > > The ietf.org mailing-list server has received a list posting from > runabk@ulrik.uio.no to tcpm@ietfa.amsl.com with the subject > 'Re: [tcpm] New Version Notification for > draft-you-tcpm-configuring-tcp-initial-window-00.txt' > > As the sender address isn't subscribed to the list, and has not been > confirmed earlier, we have to request a confirmation of the address. > To confirm the address, send a message to tcpm@ietfa.amsl.com, > with the same subject line as this message. > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form. The reply's additional "Re:" is ok.) > > If you do not wish your posting to the list to go through, simply > disregard this message. Questions to postmaster@ietf.org. From nobody Wed Oct 22 05:12:54 2014 Return-Path: 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 EC4511A903D for ; Wed, 22 Oct 2014 05:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 c01shvj2EOts for ; Wed, 22 Oct 2014 05:12:50 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8954C1A8F42 for ; Wed, 22 Oct 2014 05:12:50 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XgumX-00084h-5o; Wed, 22 Oct 2014 14:12:49 +0200 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XgumW-0002uN-LA; Wed, 22 Oct 2014 14:12:49 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 22 Oct 2014 14:12:48 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Wed, 22 Oct 2014 14:12:47 +0200 From: Runa Barik To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAB6PQD//+tvgIAATT6AgAC0xACAADk6qw== Date: Wed, 22 Oct 2014 12:12:47 +0000 Message-ID: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu>,<5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> In-Reply-To: <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 4 sum rcpts/h 11 sum msgs/h 4 total rcpts 128 max rcpts/h 10 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 54A51831ECFD4A1C85115FD9187754D87D275D33 X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 67 total 350344 max/h 460 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZB4Uq24YPpVqTFLZUVgPn6J5e-Y Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:12:53 -0000 Hi all,=0A= =0A= On 2014-10-22 01:59, Joe Touch wrote:=0A= > A few points on this thread:=0A= >=0A= > - 2140 includes both ensemble and temporal sharing=0A= > ensemble happens only when you have a concurrent=0A= > set of connections, at which point you subtract from=0A= > the window of the current ones to give to the new one=0A= >=0A= > temporal includes going back to the same place - subnet=0A= > or specific IP - and can involve aging the window=0A= >=0A= > - we had a project here to look at whether the window could be=0A= > predicted=0A= > based on past behavior (e.g., time-based patterns, either time-of-day,=0A= > day-of-week, etc.):=0A= > http://www.isi.edu/aln/=0A= > The conclusion was that such patterns were not evident (at least when=0A= > we=0A= > did the experiment).=0A= >=0A= =0A= I agree with this points.=0A= =0A= > - IW cannot be determined at the time of the connection per se=0A= > The only way to do so would be to send IW segments into the net and=0A= > see=0A= > if they get there, which isn't so much a probe as just using that=0A= > value=0A= > as the initial window anyway.=0A= >=0A= > I continue to believe that IW can be adapted over loooong periods of=0A= > time using information on past connections as network behavior evolves=0A= > as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is=0A= > definitely needed.=0A= >=0A= =0A= In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the=0A= connections at=0A= a particular instance start with nearly same IW value --- a single=0A= constant window for all flows.=0A= My point is, why not to take a look on flow characteristics. I played=0A= with a lot of simulations and experiments.=0A= In my simulations in ns2, I considered a combination of flow types=0A= based on sizes --- large flows from Pareto Distribution, and small flows=0A= from Exponential Distribution. And we observed, large flows having a=0A= small IW, and even randomly choosing a large IW for small flows gives=0A= better performance than all the flows with IW10; and we considered my=0A= network conditions --- multiple bottlenecks, underload, overload,=0A= varying base RTT, Large delay path, and etc. I also tested with CAIDA=0A= dataset in my experiments in a testbed network. A constant IW may not be=0A= suitable.=0A= Somewhere it is IW10 (currently set inside the Linux kernel), IW7=0A= (checked by Youjianjie).=0A= > Joe=0A= =0A= - Runa Barik=0A= From nobody Wed Oct 22 05:15:24 2014 Return-Path: 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 027A21A8AFE for ; Wed, 22 Oct 2014 05:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 2YDvoBjgGU6u for ; Wed, 22 Oct 2014 05:15:19 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74271A8F49 for ; Wed, 22 Oct 2014 05:15:18 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xguov-0000A4-G6; Wed, 22 Oct 2014 14:15:17 +0200 Received: from mail-ex12.exprod.uio.no ([129.240.120.74]) by mail-mx4.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Xguou-0008Ds-Q2; Wed, 22 Oct 2014 14:15:17 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex12.exprod.uio.no (2001:700:100:120::74) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 22 Oct 2014 14:15:16 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Wed, 22 Oct 2014 14:15:15 +0200 From: Runa Barik To: "Huangyihong (Rachel)" Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAArM9SAADWEgIAAHxSAgADaMACAAERjAIAAAxTr Date: Wed, 22 Oct 2014 12:15:14 +0000 Message-ID: <45750c362d3b4297a5ffd659e83fcec2@mail-ex12.exprod.uio.no> References: <> <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com>, In-Reply-To: Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 5 sum rcpts/h 15 sum msgs/h 5 total rcpts 132 max rcpts/h 14 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0E43DF8C05E4700260297B50CCABAB0FB347A0F2 X-UiO-SPAM-Test: remote_host: 129.240.120.74 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 85 total 322842 max/h 451 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5RXRgdwj71u8ZKYPtBf8VOdM-bE Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:15:21 -0000 Hi all,=0A= =0A= On 2014-10-22 11:57, Huangyihong (Rachel) wrote:=0A= > Hi Hagen, Micheal, Runa, Joe, and all,=0A= >=0A= > Thanks for your discussion on this draft. We barely catch up with=0A= > your guys^^. We're new to the transport area, and very happy to see so=0A= > many brilliant comments from all of you. They're highly appreciated.=0A= >=0A= > The motivation of this draft is that we think different applications=0A= > may have their different requirements for IW to achieve best=0A= > performance.=0A= =0A= That's really a nice idea.=0A= =0A= > And maybe different flows for one application may have=0A= > different requirements (e.g., short flows mentioned by Runa).=0A= =0A= This is what I worked during my master thesis. And we came with a=0A= simple function based on flow-sizes --- the larger the flow-size is, the=0A= smaller the IW should be. This function works better than a single constant= IW for all flows.=0A= =0A= =0A= > Current=0A= > global IW parameter may not well satisfy such requirements. So we=0A= > bring up it for discussion: configure IW dynamically by API. However,=0A= > we are not suggesting that users implement it with exaggerated values.=0A= > We think dynamically setting IW in a safe range would be no harm. That=0A= > is to say there must have a MAX IW to restrict the IW value in an=0A= > appropriate range, e.g., current IW=3D10, maybe larger in the future.=0A= =0A= We implemented the IW function we proposed in LCN'13 inside Linux=0A= kernel, version 3.7.4. However, we implemented in user space. I think it i= s hard to=0A= implement inside kernel space. We also set a MAX IW.=0A= =0A= >=0A= > The idea Michael mentioned that using flow size instead of IW as=0A= > input to the API seems good to me. But some algorithms must be figured=0A= > out in the transport layer to convert applications parameters like=0A= > flow size to IW. It also may be a very hard work.=0A= >=0A= =0A= =0A= > Anyway, we're just at the very beginning of this work. And we didn't=0A= > do a lot of experiments. But we will.=0A= =0A= We had lots of simulations, and experiments in real testbed networks.=0A= And they are accepted by WWIC'12, LCN'13, NoF'14, etc.=0A= =0A= >=0A= > BR,=0A= > Jianjie & Rachel=0A= >=0A= =0A= Regards,=0A= - Runa=0A= =0A= =0A= >> -----Original Message-----=0A= >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Hagen Paul=0A= >> Pfeifer=0A= >> Sent: Wednesday, October 22, 2014 4:57 AM=0A= >> To: Michael Welzl=0A= >> Cc: tcpm@ietf.org; Joe Touch=0A= >> Subject: Re: [tcpm] New Version Notification for=0A= >> draft-you-tcpm-configuring-tcp-initial-window-00.txt=0A= >>=0A= >> * Michael Welzl | 2014-10-21 21:05:47 [+0200]:=0A= >>=0A= >>>> Question: what is the right IW for a given application? -> it is=0A= >>>> not=0A= >>>> application specific - it is link specific!=0A= >>>=0A= >>> Here I=92m not so sure, unless we go for extremes of course, as in=0A= >>> your=0A= >>> IW50 example. Generally I do see the point of Runa above, in trying=0A= >>> to=0A= >>> let short flows finish fast and get out of the network, it=92s a=0A= >>> double benefit=0A= >> somehow.=0A= >>=0A= >> I also see Runa's point and I know that in 95% a user/programmer will=0A= >> setsockopt() IW to the wrong value - because he simple has no idea=0A= >> about the=0A= >> link. I don't consider IW50 as an extreme I already saw CDNs with a=0A= >> IW of 20.=0A= >> So there is room left for more crazy values ;-)=0A= >>=0A= >> Furthermore, the "get packets quickly out of the pipe" argument will=0A= >> show in a=0A= >> different light when considered in a sensor network. If we have a=0A= >> valid=0A= >> information basis (TCP cache) the finish fast approach may work - but=0A= >> we must=0A= >> make sure that the pipe is in principle capable for the short IWx=0A= >> burst. IWx=0A= >> results in bursts and some middle boxes are still not equipped for=0A= >> this=0A= >> (bufferbloat guys: yes, this world exist ;).=0A= >>=0A= >>> Interesting; while RFC 2140 is absolutely on my radar (we do some=0A= >>> quite=0A= >>> closely related work in RMCAT), I forgot that it talks about IW. Can=0A= >>> you provide more detail about what is implemented in Linux for the=0A= >>> IW=0A= >>> there - I thought by default none of this is happening for IW in=0A= >>> Linux,=0A= >>> all flows just get 10?=0A= >>=0A= >> IW is not cache driven in Linux - I don't wanted to claim this. But=0A= >> there is=0A= >> absolutely no restriction to design and implement an algorithm to do=0A= >> that!=0A= >> Joe's I-D may be a starting point (using packet loss indications, use=0A= >> a timeout=0A= >> after which the cached information is threated as outdated, ...).=0A= >> Similar to th RTT subsystem.=0A= >>=0A= >>> I agree that Ensemble Sharing could make sense for IW=85 however,=0A= >>> thanks=0A= >>> to ECMP, there is of course no guarantee that different connections=0A= >>> to=0A= >>> the same IP address really do traverse the same bottleneck. So an=0A= >>> approach that uses e.g. IW1 for later-joining connections to the=0A= >>> same=0A= >>> IP address may be doing the exact right thing or may be too=0A= >>> conservative, depending on whether ECMP is in place or not. Further,=0A= >>> by=0A= >>> applying this limitation only on later connections to the same IP=0A= >>> address, it=0A= >> may not kick in often enough.=0A= >>=0A= >> To some degree: yes. On the other the shorter the time difference=0A= >> between=0A= >> flows the more likely the same path characteristics are still valid.=0A= >> Sure, cache=0A= >> timeouts should make sure that the information is outdated after a=0A= >> while=0A= >> - no doubt.=0A= >>=0A= >>> Alternatively, giving a different IW to flows depending on their=0A= >>> size=0A= >>> may be doing the right thing more or less often=85 either way it=92s=0A= >>> heuristics I=0A= >> guess.=0A= >>> I think both options are worth considering. Generally, giving a=0A= >>> large=0A= >>> IW only to short flows does strike me as reasonable because long=0A= >>> flows=0A= >>> simply won=92t benefit much from it.=0A= >>=0A= >> Probably - I must think about this.=0A= >>=0A= >>> My point in my previous email was only that no additional harm comes=0A= >>> from letting the application tell the transport layer a desired IW=0A= >>> (or=0A= >>> maybe rather flow size, to allow transport to do the calculation),=0A= >>> provided that an upper limit is imposed by the transport.=0A= >>=0A= >> Ok, got it. But then a setsockopt("SHORT_LIVED_FLOW") will be=0A= >> adequate too,=0A= >> right!? Setting the IW is really complicated from a programmer point=0A= >> of view,=0A= >> even a network guru may choose the wrong value. I believe that this=0A= >> logic=0A= >> should be implemented and controlled in the Kernel.=0A= >>=0A= >> Anyway, I understand the application argument and it may provide -=0A= >> combined=0A= >> with the cached IW - a better behavior.=0A= >>=0A= >> Hagen=0A= >=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Wed Oct 22 05:35:55 2014 Return-Path: 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 80CA61A8F42 for ; Wed, 22 Oct 2014 05:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 HpadydiWpYjS for ; Wed, 22 Oct 2014 05:35:52 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B61F1A90A0 for ; Wed, 22 Oct 2014 05:35:48 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xgv8l-0003gr-14; Wed, 22 Oct 2014 14:35:47 +0200 Received: from mail-ex12.exprod.uio.no ([129.240.120.74]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Xgv8j-0001lg-Pi; Wed, 22 Oct 2014 14:35:46 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex12.exprod.uio.no (2001:700:100:120::74) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 22 Oct 2014 14:35:44 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Wed, 22 Oct 2014 14:35:44 +0200 From: Runa Barik To: "Huangyihong (Rachel)" Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAArM9SAADWEgIAAHxSAgADaMACAAERjAIAAAxTrgAAFpn8= Date: Wed, 22 Oct 2014 12:35:44 +0000 Message-ID: References: <> <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com>, , <45750c362d3b4297a5ffd659e83fcec2@mail-ex12.exprod.uio.no> In-Reply-To: <45750c362d3b4297a5ffd659e83fcec2@mail-ex12.exprod.uio.no> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 6 sum rcpts/h 18 sum msgs/h 6 total rcpts 135 max rcpts/h 17 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 328C98AEEF72F485781564DF7174AD5CDB19F621 X-UiO-SPAM-Test: remote_host: 129.240.120.74 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 197 total 322954 max/h 451 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Lw1AXMmoqMQdcTc75IXYc7RZBNw Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 12:35:54 -0000 Hi all,=0A= =0A= A typo.=0A= ________________________________________=0A= From: tcpm on behalf of Runa Barik =0A= Sent: Wednesday, October 22, 2014 2:15 PM=0A= To: Huangyihong (Rachel)=0A= Cc: tcpm@ietf.org; Michael Welzl; Joe Touch=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= Hi all,=0A= =0A= On 2014-10-22 11:57, Huangyihong (Rachel) wrote:=0A= > Hi Hagen, Micheal, Runa, Joe, and all,=0A= >=0A= > Thanks for your discussion on this draft. We barely catch up with=0A= > your guys^^. We're new to the transport area, and very happy to see so=0A= > many brilliant comments from all of you. They're highly appreciated.=0A= >=0A= > The motivation of this draft is that we think different applications=0A= > may have their different requirements for IW to achieve best=0A= > performance.=0A= =0A= That's really a nice idea.=0A= =0A= > And maybe different flows for one application may have=0A= > different requirements (e.g., short flows mentioned by Runa).=0A= =0A= This is what I worked during my master thesis. And we came with a=0A= simple function based on flow-sizes --- the larger the flow-size is, the=0A= smaller the IW should be. This function works better than a single constant= IW for all flows.=0A= =0A= =0A= > Current=0A= > global IW parameter may not well satisfy such requirements. So we=0A= > bring up it for discussion: configure IW dynamically by API. However,=0A= > we are not suggesting that users implement it with exaggerated values.=0A= > We think dynamically setting IW in a safe range would be no harm. That=0A= > is to say there must have a MAX IW to restrict the IW value in an=0A= > appropriate range, e.g., current IW=3D10, maybe larger in the future.=0A= =0A= We implemented the IW function we proposed in LCN'13 inside Linux=0A= kernel, version 3.7.4. However, we implemented in user space. I think it i= s *not* hard to=0A= implement inside kernel space. We also set a MAX IW.=0A= =0A= >=0A= > The idea Michael mentioned that using flow size instead of IW as=0A= > input to the API seems good to me. But some algorithms must be figured=0A= > out in the transport layer to convert applications parameters like=0A= > flow size to IW. It also may be a very hard work.=0A= >=0A= =0A= =0A= > Anyway, we're just at the very beginning of this work. And we didn't=0A= > do a lot of experiments. But we will.=0A= =0A= We had lots of simulations, and experiments in real testbed networks.=0A= And they are accepted by WWIC'12, LCN'13, NoF'14, etc.=0A= =0A= >=0A= > BR,=0A= > Jianjie & Rachel=0A= >=0A= =0A= Regards,=0A= - Runa=0A= =0A= =0A= >> -----Original Message-----=0A= >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Hagen Paul=0A= >> Pfeifer=0A= >> Sent: Wednesday, October 22, 2014 4:57 AM=0A= >> To: Michael Welzl=0A= >> Cc: tcpm@ietf.org; Joe Touch=0A= >> Subject: Re: [tcpm] New Version Notification for=0A= >> draft-you-tcpm-configuring-tcp-initial-window-00.txt=0A= >>=0A= >> * Michael Welzl | 2014-10-21 21:05:47 [+0200]:=0A= >>=0A= >>>> Question: what is the right IW for a given application? -> it is=0A= >>>> not=0A= >>>> application specific - it is link specific!=0A= >>>=0A= >>> Here I=92m not so sure, unless we go for extremes of course, as in=0A= >>> your=0A= >>> IW50 example. Generally I do see the point of Runa above, in trying=0A= >>> to=0A= >>> let short flows finish fast and get out of the network, it=92s a=0A= >>> double benefit=0A= >> somehow.=0A= >>=0A= >> I also see Runa's point and I know that in 95% a user/programmer will=0A= >> setsockopt() IW to the wrong value - because he simple has no idea=0A= >> about the=0A= >> link. I don't consider IW50 as an extreme I already saw CDNs with a=0A= >> IW of 20.=0A= >> So there is room left for more crazy values ;-)=0A= >>=0A= >> Furthermore, the "get packets quickly out of the pipe" argument will=0A= >> show in a=0A= >> different light when considered in a sensor network. If we have a=0A= >> valid=0A= >> information basis (TCP cache) the finish fast approach may work - but=0A= >> we must=0A= >> make sure that the pipe is in principle capable for the short IWx=0A= >> burst. IWx=0A= >> results in bursts and some middle boxes are still not equipped for=0A= >> this=0A= >> (bufferbloat guys: yes, this world exist ;).=0A= >>=0A= >>> Interesting; while RFC 2140 is absolutely on my radar (we do some=0A= >>> quite=0A= >>> closely related work in RMCAT), I forgot that it talks about IW. Can=0A= >>> you provide more detail about what is implemented in Linux for the=0A= >>> IW=0A= >>> there - I thought by default none of this is happening for IW in=0A= >>> Linux,=0A= >>> all flows just get 10?=0A= >>=0A= >> IW is not cache driven in Linux - I don't wanted to claim this. But=0A= >> there is=0A= >> absolutely no restriction to design and implement an algorithm to do=0A= >> that!=0A= >> Joe's I-D may be a starting point (using packet loss indications, use=0A= >> a timeout=0A= >> after which the cached information is threated as outdated, ...).=0A= >> Similar to th RTT subsystem.=0A= >>=0A= >>> I agree that Ensemble Sharing could make sense for IW=85 however,=0A= >>> thanks=0A= >>> to ECMP, there is of course no guarantee that different connections=0A= >>> to=0A= >>> the same IP address really do traverse the same bottleneck. So an=0A= >>> approach that uses e.g. IW1 for later-joining connections to the=0A= >>> same=0A= >>> IP address may be doing the exact right thing or may be too=0A= >>> conservative, depending on whether ECMP is in place or not. Further,=0A= >>> by=0A= >>> applying this limitation only on later connections to the same IP=0A= >>> address, it=0A= >> may not kick in often enough.=0A= >>=0A= >> To some degree: yes. On the other the shorter the time difference=0A= >> between=0A= >> flows the more likely the same path characteristics are still valid.=0A= >> Sure, cache=0A= >> timeouts should make sure that the information is outdated after a=0A= >> while=0A= >> - no doubt.=0A= >>=0A= >>> Alternatively, giving a different IW to flows depending on their=0A= >>> size=0A= >>> may be doing the right thing more or less often=85 either way it=92s=0A= >>> heuristics I=0A= >> guess.=0A= >>> I think both options are worth considering. Generally, giving a=0A= >>> large=0A= >>> IW only to short flows does strike me as reasonable because long=0A= >>> flows=0A= >>> simply won=92t benefit much from it.=0A= >>=0A= >> Probably - I must think about this.=0A= >>=0A= >>> My point in my previous email was only that no additional harm comes=0A= >>> from letting the application tell the transport layer a desired IW=0A= >>> (or=0A= >>> maybe rather flow size, to allow transport to do the calculation),=0A= >>> provided that an upper limit is imposed by the transport.=0A= >>=0A= >> Ok, got it. But then a setsockopt("SHORT_LIVED_FLOW") will be=0A= >> adequate too,=0A= >> right!? Setting the IW is really complicated from a programmer point=0A= >> of view,=0A= >> even a network guru may choose the wrong value. I believe that this=0A= >> logic=0A= >> should be implemented and controlled in the Kernel.=0A= >>=0A= >> Anyway, I understand the application argument and it may provide -=0A= >> combined=0A= >> with the cached IW - a better behavior.=0A= >>=0A= >> Hagen=0A= >=0A= > _______________________________________________=0A= > tcpm mailing list=0A= > tcpm@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tcpm=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Wed Oct 22 06:59:50 2014 Return-Path: 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 CCBED1AC3AD for ; Wed, 22 Oct 2014 06:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ld-XvK4nA2Ws for ; Wed, 22 Oct 2014 06:59:47 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044351AC3C3 for ; Wed, 22 Oct 2014 06:59:41 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so2915291lbi.36 for ; Wed, 22 Oct 2014 06:59:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PB1Z0qVdLVNl/bPEAa0Mq8lxusEO2aB3y7kgNl/bwAE=; b=KUfEYNVMcP3vS7x3t2rBZg453umnmHLGyuUXIJEerbDYDMzmQslIkbF+m597DktGYY GqqbYnFRvlj/JylVssnRHOgtEAAu/dYhHB3dCj+4GAg5ZhAC3zIaw1y9GrM29PRN37gx g6LEbdNNLmXBjpBHlXO/GyvNVHaXQ7GWWAiSdVU6sv+iGETWRi+/s+t0DBFKP3qFcVqy pKoxfr0sLEilpQouH3DE8I0VViZVRfg0WjcTnaf274pfz9iJpEnk4NyxSRAS2pIq7c6/ Y3KIImy5i5lnc7x903uOmTmZokGXYQXU3q5tv1+f/bwLHGVguTXOGdOY21kyFEZWPXvs OFPg== X-Gm-Message-State: ALoCoQmYx3rd2UaPufi8Rjsoew32r2yx5GqnFGWfhovmQlTvazvS05kooWT+4aLhGWaVl9RihN1A MIME-Version: 1.0 X-Received: by 10.152.205.103 with SMTP id lf7mr41945267lac.2.1413986380294; Wed, 22 Oct 2014 06:59:40 -0700 (PDT) Received: by 10.25.21.207 with HTTP; Wed, 22 Oct 2014 06:59:40 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com> References: <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com> Date: Wed, 22 Oct 2014 15:59:40 +0200 Message-ID: From: Hagen Paul Pfeifer To: "Huangyihong (Rachel)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7lNmhi7nLSkw214-izI4-nNVRlQ Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:59:49 -0000 @runa: your mailer seems to send randomly email ... ;( On 22 October 2014 11:57, Huangyihong (Rachel) wr= ote: > The motivation of this draft is that we think different applications may = have their different requirements for IW to achieve best performance. And m= aybe different flows for one application may have different requirements (e= .g., short flows mentioned by Runa). Current global IW parameter may not we= ll satisfy such requirements. So we bring up it for discussion: configure I= W dynamically by API. However, we are not suggesting that users implement i= t with exaggerated values. We think dynamically setting IW in a safe range = would be no harm. That is to say there must have a MAX IW to restrict the I= W value in an appropriate range, e.g., current IW=3D10, maybe larger in the= future. Hey all let me go one step back: what application will benefit from this effort? - Bulk data applications? - Interactive, chatty applications? Not really, only short lived flows with a specific amount of data. What is specific? Well 10 * MSS (a window) is handled currently. At RTT 2 we have a window of 20. One iteration later 40. That boils down to applications with a data amount in the range of 15k to 30k, mind you. Below 15k IW10 is fine, larger than 30k and slow start will kick in quickly (or in other words, after some amount of data it is rather a bulk data application, an elephant). What application is this? HTTP/1? What else? Don't get me wrong, the effort is probably worth - but to see a real use case may help. Hagen From nobody Wed Oct 22 08:36:51 2014 Return-Path: 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 2E7EE1ACD5C for ; Wed, 22 Oct 2014 08:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 E1g6vX4r19Er for ; Wed, 22 Oct 2014 08:36:48 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E3E571ACD4B for ; Wed, 22 Oct 2014 08:36:47 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id AA5DCC94C5; Wed, 22 Oct 2014 11:36:45 -0400 (EDT) Date: Wed, 22 Oct 2014 11:36:45 -0400 From: John Leslie To: Pasi Sarolahti Message-ID: <20141022153645.GC525@verdi> References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Lj9qXhcCZuFHgdsCufGmcjwyqJY Cc: tcpm@ietf.org Subject: Re: [tcpm] Adopting draft-zimmermann-tcpm-undeployed? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:36:50 -0000 Pasi Sarolahti wrote: > > Yes, I think we should be able to take this through tcpm fairly quickly, > but according to the normal procedure. So the plan would be that unless > anyone objects within next couple of weeks, we will adopt this as TCPM > document, and will start a WGLC soon after. (This is not to discourage > further comments, so please take a look and send comments as usual ? > although currently there is not much text to comment on? :-) >... The draft proposes quite a number of status changes: ] ] The RFC Editor is requested to change the status of the following ] RFCs to Historic [RFC2026]: ] ] o [RFC0675] on "Specification of Internet Transmission Control ] Program" ] ] o [RFC0721] on "Out-of-Band Control Signals in a Host-to-Host ] Protocol" These seem _very_ Historic... ] o [RFC0879] on "TCP Maximum Segment Size and Related Topics" This one seems to have been replaced by RFC 6691. ] o [RFC1078] on "TCP port service Multiplexer (TCPMUX)" This 1988 document seems pretty Historic. ] o [RFC6013] on "TCP Cookie Transactions" This 2011 document defined an Experimental use of option 254. IMHO it deserves a separate writeup, either explaining the experiment results or clearly stating the results are unknown. (Three years "should" be long enough for an Experiment; but we have so many cases that have dragged on even longer.) ] The RFC Editor is requested to change the status of the following ] RFCs to Informational [RFC2026]: All of these are currently Status "UNKNOWN". I'm not clear on why we want to upgrade them to "Informational". They seem to me to be closer to "Historic"... ] o [RFC0813] on "Window and Acknowledgement Strategy in TCP" 1982, Status UNKNOWN... ] o [RFC0814] on "Name, addresses, ports, and routes" 1982, Status UNKNOWN... ] o [RFC0816] on "Fault Isolation and Recovery 1982, Status UNKNOWN... ] o [RFC0817] on "Modularity and efficiency in protocol ] implementation" 1982, Status UNKNOWN... ] o [RFC0872] on "TCP-on-a-LAN" 1982, Status UNKNOWN... ] o [RFC0896] on "Congestion Control in IP/TCP Internetworks" 1984, Status UNKNOWN... ] o [RFC0964] on "Some problems with the specification of the Military ] Standard Transmission Control Protocol" 1985, Status UNKNOWN... -- John Leslie From nobody Wed Oct 22 11:48:56 2014 Return-Path: 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 EE22C1ACEF0 for ; Wed, 22 Oct 2014 11:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ASu1px_3PybN for ; Wed, 22 Oct 2014 11:48:44 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C851ACFE8 for ; Wed, 22 Oct 2014 11:48:12 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9MIm9MH021306; Wed, 22 Oct 2014 13:48:10 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: Date: Wed, 22 Oct 2014 13:48:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Shepard X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/H4P1NwG7ngEwgKkqAIbjfVWqYtA Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 18:48:48 -0000 > On Oct 21, 2014, at 11:43 PM, Tim Shepard wrote: >=20 > I'm not so sure that it makes sense to try and definitively give > answers to your questions for future TCP options we haven't even > invented yet. It's not clear to me that there's any value in > deciding things now that would preclude doing something useful in the > future that might be contrary to some decision we might make now. >=20 > It's not like there's generic option-negotiation code in any stack > implementation (that I'm aware of) where code was written to negotiate > an option on or off where the author of that code has no clue what the > option is or is unable to know what its semantics are. >=20 > So I would expect (hope) that someone implementing a new TCP option > would be able to do the right thing for that particular sort of > option. Yes, the point of the Four-Way handshake is to provide a framework that can be used in the future to get past the limitation of the option space in the initial SYN of the Three-Way handshake. >=20 > Yes, allowing options to show up for the first time on the 2nd packet > (of the 3 or 4 WHS) is new and we don't have stacks that do that now, > so maybe we need to think some things through to make sure the right > things happen. Actually it isn=E2=80=99t new. RFC 1072 originally defined the Window = Scale, Echo and SACK Permitted options as being put into any packet that contained the SYN bit. It wasn=E2=80=99t until RFC 1323 that we added = the optimization that there wasn=E2=80=99t any point in putting these = options into the SYN/ACK if they weren=E2=80=99t received in the SYN, because they = wouldn=E2=80=99t be enabled anyway (replacing Echo with Timestamps). If implementations forget what they sent in the SYN and rely on what is in the SYN/ACK to determine which options are enabled, then that=E2=80=99= s a bug in the implementation. With a Three-Way handshake, even if the SYN/ACK contains a Window Scale option and the initial SYN didn=E2=80=99t contain the Window Scale option, it must not be enabled on either side. >=20 > But it is not obvious to me that we can do so for any and all options > (past and future) in a generic way that would be the right thing for > all (future) options. At the generic level, there shouldn=E2=80=99t be any problem with = putting options into the SYN/ACK that weren=E2=80=99t received in the SYN, = RFC1122 already states that any unknown options must be silently ignored. >=20 > And yes, the potential interactions between options might get more > complicated. But again, I'm not sure we can make any good decisions > without getting specific about which particular options we are talking > about. And it's probably easier to figure out what the right thing to > do would be in the case of specific options. Yep, I totally agree. The best we can do is provide a framework, and then the individual options need to be defined how they can operate in that framework. >=20 > I guess we should think carefully about what a stack should do if it > sees an option that it doesn't understand. Today, if an option that > you don't understand shows up on a SYN, you just ignore it. And I > think we would pretty much have to say that if a new option shows up > on a SYN/ACK that you don't understand, just ignore it. (RST in that > case, if deployed, would preclude being able to extend how some future > option gets negotiated.) That=E2=80=99s what RFC 1122 says. Any unknown options are silently = ignored. > Imagine that you ran out of option space on the initial SYN and were > unable to include all the options you would have liked to. But at > least one of the options you included on that initial SYN implies that > you are modern enough to cope with additional options appearing for > the first time on the SYN/ACK. Say that the window scale was one of > the options ommitted from the initial SYN due to lack of space. The > responding host may now include the window scale option on the SYN/ACK > packet. In this case, since we're not sure that the initial host even > implements window scaling, the SYN/ACK packet's window will be an > unscaled value. If the initiating host includes a window scale > option on the packet that carries the ACK of the SYN/ACK, then window > scale has been turned on (and that packet carries a scaled window). > If the ACK of the SYN/ACK does not include a window scale option (and > window scale option was not present on the SYN), then proceed with no > window scaling. >=20 > Did I get that one right? (If not, we can probably figure out what > the right thing to do is.) Not quite. With the Three-Way handshake, if the SYN/ACK has a Window scale and the initial SYN didn=E2=80=99t have it, then the Window Scale is ignored and not enabled. It=E2=80=99s the Four-Way handshake that allows it to still be enabled, by the client then including the Window scale in its SYN/ACK. It=E2=80=99s the addition of another packet from the client with the SYN bit set that allows it to fit nicely with the existing RFC7323 style option enablement (enabled by sending and receiving the option in a packet with the SYN bit set). >=20 > All of this more modern mechanism would only be active if there was > *some* option on the initial SYN that implied extendend option > negotiation is allowed. That=E2=80=99s what the 4WAY bit (or 4WAY option) is for. >=20 > And window scale seems like it is exactly the sort of option whose > utility is not damaged (much at all) by delaying its negotiation by > half a round trip time. There may (someday, if not today) be other > such options. >=20 > Oh, I guess it doesn't work so well if the server is not modern enough > to initiate the negotiation of that option on the second half of the > first round trip. Then you wind up without the option turned on. > So maybe the initiator needs a hint of the servers capabilities. >=20 > But if we were trying to add a window scale option after we had > succeeded in extending the option space with an option that is carried > on the SYN (perhaps without any extra option space there) and then > additional option space being available on the SYN/ACK and all > subsequent packets), then we could have done window scale this way, > and things would be OK. The more expensive route is for the client to send a SYN, and if it gets back a SYN/ACK that indicates EDO support, restart the Three-Way handshake by sending a SYN making use of the EDO option. The downside of this is that it adds an entire RTT to connection establishment, the Four-Way handshake tries to find middle ground between that and the Three-Way handshake. >=20 > If going forward we ensure that any stack that implements new options > (that won't fit today in the room remaining in TCP option space) allow > for this sort of option negotiation starting with the SYN/ACK (where > there can somehow be more space for options), then we can deploy those > options in the SYN/ACK (until we run out of MTU) or even later (if we > can get the later option negotiation explicitly acknowledged after the > SYNs have already been acknowledged). Yes, we put a stake in the ground saying that all new TCP options must require that implementations also support Four-Way handshake and EDO. -David >=20 >=20 > -Tim Shepard > shep@alum.mit.edu >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Oct 22 15:32:35 2014 Return-Path: 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 085DC1A7007 for ; Wed, 22 Oct 2014 15:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 K0rIBfZRlHZB for ; Wed, 22 Oct 2014 15:32:31 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3321A1B3A for ; Wed, 22 Oct 2014 15:32:30 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xh4SD-0006pi-4N; Thu, 23 Oct 2014 00:32:29 +0200 Received: from mail-ex03.exprod.uio.no ([129.240.52.6]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Xh4SC-0006g1-JK; Thu, 23 Oct 2014 00:32:29 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex03.exprod.uio.no (2001:700:100:52::6) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 23 Oct 2014 00:32:26 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Thu, 23 Oct 2014 00:32:26 +0200 From: Runa Barik To: Hagen Paul Pfeifer , "Huangyihong (Rachel)" Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAArM9SAADWEgIAAHxSAgADaMACAAEOKAIAAq6Em Date: Wed, 22 Oct 2014 22:32:25 +0000 Message-ID: <5c1d9b43527d45d7b34f70f4f357b065@mail-ex12.exprod.uio.no> References: <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com>, In-Reply-To: Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 141 max rcpts/h 17 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2102CAA65890404CCCF97FD16D0A837E91723406 X-UiO-SPAM-Test: remote_host: 129.240.52.6 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 10 total 385391 max/h 1182 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NItoCZhfgQeBqBHy0bB6grY9MsM Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 22:32:34 -0000 Hi Hagen,=0A= =0A= In line.=0A= ________________________________________=0A= From: tcpm on behalf of Hagen Paul Pfeifer =0A= Sent: Wednesday, October 22, 2014 3:59 PM=0A= To: Huangyihong (Rachel)=0A= Cc: tcpm@ietf.org; Michael Welzl; Joe Touch=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= @runa: your mailer seems to send randomly email ... ;(=0A= =0A= On 22 October 2014 11:57, Huangyihong (Rachel) wr= ote:=0A= =0A= > The motivation of this draft is that we think different applications may = have their different requirements for IW to achieve best performance. And m= aybe different flows for one application may have different requirements (e= .g., short flows mentioned by Runa). Current global IW parameter may not we= ll satisfy such requirements. So we bring up it for discussion: configure I= W dynamically by API. However, we are not suggesting that users implement i= t with exaggerated values. We think dynamically setting IW in a safe range = would be no harm. That is to say there must have a MAX IW to restrict the I= W value in an appropriate range, e.g., current IW=3D10, maybe larger in the= future.=0A= =0A= Hey all=0A= =0A= let me go one step back: what application will benefit from this effort?=0A= =0A= - Bulk data applications?=0A= - Interactive, chatty applications?=0A= =0A= RB -=0A= My view --- benefit not for bulk data applications. =0A= Because, the large flows adversely affect the small flows.=0A= The benefit is for small flows. In some cases, the size is not known in= advance; but,=0A= some heuristics can be applied.=0A= RB -=0A= =0A= Not really, only short lived flows with a specific amount of data.=0A= What is specific? Well 10 * MSS (a window) is handled currently. At=0A= RTT 2 we have a window of 20. One iteration later 40.=0A= =0A= =0A= That boils down to applications with a data amount in the range of 15k=0A= to 30k, mind you. Below 15k IW10 is fine, larger than 30k and slow=0A= start will kick in quickly (or in other words, after some amount of=0A= data it is rather a bulk data application, an elephant).=0A= =0A= What application is this? HTTP/1? What else? Don't get me wrong, the=0A= effort is probably worth - but to see a real use case may help.=0A= =0A= Hagen=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Thu Oct 23 01:12:07 2014 Return-Path: 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 7F2141A8907 for ; Thu, 23 Oct 2014 01:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BnYWhPfrNEkd for ; Thu, 23 Oct 2014 01:11:56 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CDB1A8913 for ; Thu, 23 Oct 2014 01:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,774,1406617200"; d="scan'208";a="162653530" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx11-out.netapp.com with ESMTP; 23 Oct 2014 01:11:10 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Oct 2014 01:10:30 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Thu, 23 Oct 2014 01:10:30 -0700 From: "Zimmermann, Alexander" To: John Leslie Thread-Topic: [tcpm] Adopting draft-zimmermann-tcpm-undeployed? Thread-Index: AQHP7TNmWGGqnTb11kSMZFeWJMVwn5w8tuqAgAEV1YA= Date: Thu, 23 Oct 2014 08:10:29 +0000 Message-ID: References: <24059_1413799841_5444DFA1_24059_161_1_FEF952E9-DC04-42BC-932A-D9E97BA1A193@netapp.com> <61E1E847-C0D4-489A-8448-BC6A1306A6EC@iki.fi> <06092CB9-19AE-4D57-98BD-27DA1014E763@netapp.com> <20141022153645.GC525@verdi> In-Reply-To: <20141022153645.GC525@verdi> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="utf-8" Content-ID: <26F255C772B10E488543693E68750E34@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/88GWyZsWWUN9MfP9OWE-4PMyWSg Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Adopting draft-zimmermann-tcpm-undeployed? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:12:00 -0000 SGkgSm9obiwNCg0KdGhhbmtzIHlvdSBmb3IgbG9va2luZyBpbnRvIHRoZSBkcmFmdC4NCkNvbW1l bnRzIGlubGluZS4NCg0KPiBBbSAyMi4xMC4yMDE0IHVtIDE3OjM2IHNjaHJpZWIgSm9obiBMZXNs aWUgPGpvaG5AamxjLm5ldD46DQo+IA0KPiBQYXNpIFNhcm9sYWh0aSA8cGFzaS5zYXJvbGFodGlA aWtpLmZpPiB3cm90ZToNCj4+IA0KPj4gWWVzLCBJIHRoaW5rIHdlIHNob3VsZCBiZSBhYmxlIHRv IHRha2UgdGhpcyB0aHJvdWdoIHRjcG0gZmFpcmx5IHF1aWNrbHksDQo+PiBidXQgYWNjb3JkaW5n IHRvIHRoZSBub3JtYWwgcHJvY2VkdXJlLiBTbyB0aGUgcGxhbiB3b3VsZCBiZSB0aGF0IHVubGVz cw0KPj4gYW55b25lIG9iamVjdHMgd2l0aGluIG5leHQgY291cGxlIG9mIHdlZWtzLCB3ZSB3aWxs IGFkb3B0IHRoaXMgYXMgVENQTQ0KPj4gZG9jdW1lbnQsIGFuZCB3aWxsIHN0YXJ0IGEgV0dMQyBz b29uIGFmdGVyLiAoVGhpcyBpcyBub3QgdG8gZGlzY291cmFnZQ0KPj4gZnVydGhlciBjb21tZW50 cywgc28gcGxlYXNlIHRha2UgYSBsb29rIGFuZCBzZW5kIGNvbW1lbnRzIGFzIHVzdWFsID8NCj4+ IGFsdGhvdWdoIGN1cnJlbnRseSB0aGVyZSBpcyBub3QgbXVjaCB0ZXh0IHRvIGNvbW1lbnQgb24/ IDotKQ0KPj4gLi4uDQo+IA0KPiAgIFRoZSBkcmFmdCBwcm9wb3NlcyBxdWl0ZSBhIG51bWJlciBv ZiBzdGF0dXMgY2hhbmdlczoNCj4gXSANCj4gXSAgICBUaGUgUkZDIEVkaXRvciBpcyByZXF1ZXN0 ZWQgdG8gY2hhbmdlIHRoZSBzdGF0dXMgb2YgdGhlIGZvbGxvd2luZw0KPiBdIFJGQ3MgdG8gSGlz dG9yaWMgW1JGQzIwMjZdOg0KPiBdIA0KPiBdIG8gIFtSRkMwNjc1XSBvbiAiU3BlY2lmaWNhdGlv biBvZiBJbnRlcm5ldCBUcmFuc21pc3Npb24gQ29udHJvbA0KPiBdICAgIFByb2dyYW0iDQo+IF0g DQo+IF0gbyAgW1JGQzA3MjFdIG9uICJPdXQtb2YtQmFuZCBDb250cm9sIFNpZ25hbHMgaW4gYSBI b3N0LXRvLUhvc3QNCj4gXSAgICBQcm90b2NvbCINCj4gDQo+ICAgVGhlc2Ugc2VlbSBfdmVyeV8g SGlzdG9yaWMuLi4NCj4gDQo+IF0gbyAgW1JGQzA4NzldIG9uICJUQ1AgTWF4aW11bSBTZWdtZW50 IFNpemUgYW5kIFJlbGF0ZWQgVG9waWNzIg0KPiANCj4gICBUaGlzIG9uZSBzZWVtcyB0byBoYXZl IGJlZW4gcmVwbGFjZWQgYnkgUkZDIDY2OTEuDQoNClllcywgcmlnaHQsIGJ1dCBSRkMgNjY5MSBv bmx5IHVwZGF0ZXMgUkZDIDg3OS4gSXQgZG9lc27igJl0IG9ic29sZXRlIGl0Lg0KDQo+IA0KPiBd IG8gIFtSRkMxMDc4XSBvbiAiVENQIHBvcnQgc2VydmljZSBNdWx0aXBsZXhlciAoVENQTVVYKSIN Cj4gDQo+ICAgVGhpcyAxOTg4IGRvY3VtZW50IHNlZW1zIHByZXR0eSBIaXN0b3JpYy4NCj4gDQo+ IF0gbyAgW1JGQzYwMTNdIG9uICJUQ1AgQ29va2llIFRyYW5zYWN0aW9ucyINCj4gDQo+ICAgVGhp cyAyMDExIGRvY3VtZW50IGRlZmluZWQgYW4gRXhwZXJpbWVudGFsIHVzZSBvZiBvcHRpb24gMjU0 LiBJTUhPDQo+IGl0IGRlc2VydmVzIGEgc2VwYXJhdGUgd3JpdGV1cCwgZWl0aGVyIGV4cGxhaW5p bmcgdGhlIGV4cGVyaW1lbnQgcmVzdWx0cw0KPiBvciBjbGVhcmx5IHN0YXRpbmcgdGhlIHJlc3Vs dHMgYXJlIHVua25vd24uDQoNCkl0IGRvZXNu4oCZdCBleGlzdCBhbnkgcmVzdWx0cyAoQUZBSUsp LiBUaGUgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIHdhcw0KdW5kZXIgTGludXgsIGJ1dCBDaHJp c3RvcGggUGFhc2NoIHJlbW92ZWQgdGhlIGNvZGUgYSB3aGlsZSBhZ28gZnJvbSB0aGUNCktlcm5l bC4gVG9kYXksIHcvIFRGTyBhbmQgRURPIHdlIGhhdmUgb3RoZXIgKGFuZCBiZXR0ZXIgc29sdXRp b25zKSBpbiBwbGFjZS4NCkkgZG9u4oCZdCBzZWUgdGhlIG5lZWQgZm9yIHNlcGFyYXRlIHdyaXRl dXAuIFdoeSB3ZSBjYW5ub3QgaW5jbHVkZSB0aGUgd3JpdGV1cA0KaW4gZHJhZnQtemltbWVybWFu bi10Y3BtLXVuZGVwbG95ZWQ/IEFub3RoZXIgcG9zc2liaWxpdHkgaXMgdGhhdCBFRE8NCm9ic29s ZXRlIFJGQzYwMTMuIEZpbmUgYnkgbWUuIEluIHRoYXQgY2FzZSBJIHB1c2ggdGhlIHdvcmsgdG8g Sm9lIDstKQ0KDQo+IA0KPiAgIChUaHJlZSB5ZWFycyAic2hvdWxkIiBiZSBsb25nIGVub3VnaCBm b3IgYW4gRXhwZXJpbWVudDsgYnV0IHdlIGhhdmUNCj4gc28gbWFueSBjYXNlcyB0aGF0IGhhdmUg ZHJhZ2dlZCBvbiBldmVuIGxvbmdlci4pDQo+IA0KPiBdIFRoZSBSRkMgRWRpdG9yIGlzIHJlcXVl c3RlZCB0byBjaGFuZ2UgdGhlIHN0YXR1cyBvZiB0aGUgZm9sbG93aW5nDQo+IF0gUkZDcyB0byBJ bmZvcm1hdGlvbmFsIFtSRkMyMDI2XToNCj4gDQo+ICAgIEFsbCBvZiB0aGVzZSBhcmUgY3VycmVu dGx5IFN0YXR1cyAiVU5LTk9XTiIuIEknbSBub3QgY2xlYXIgb24gd2h5DQo+IHdlIHdhbnQgdG8g dXBncmFkZSB0aGVtIHRvICJJbmZvcm1hdGlvbmFsIi4gVGhleSBzZWVtIHRvIG1lIHRvIGJlDQo+ IGNsb3NlciB0byDigJ5IaXN0b3JpYyIuLi4NCg0KVGhlIHJlYXNvbiBpcyB0aGF0IGJhc2NpYWxs eSB0aGUgYWxnb3JpdGhtcyBpbiBhbGwgdGhlc2UgUkZDcyBhcmUNCnRvZGF5IGluIHVzZS4gUkZD MDgxMyAtIFJGQzA4MTcgYXJlIHBhcnQgb2YgUkZDMTEyMi4NCg0KPiANCj4gXSBvICBbUkZDMDgx M10gb24gIldpbmRvdyBhbmQgQWNrbm93bGVkZ2VtZW50IFN0cmF0ZWd5IGluIFRDUCINCj4gDQo+ ICAgMTk4MiwgU3RhdHVzIFVOS05PV04uLi4NCj4gDQo+IF0gbyAgW1JGQzA4MTRdIG9uICJOYW1l LCBhZGRyZXNzZXMsIHBvcnRzLCBhbmQgcm91dGVzIg0KPiANCj4gICAxOTgyLCBTdGF0dXMgVU5L Tk9XTi4uLg0KPiANCj4gXSBvICBbUkZDMDgxNl0gb24gIkZhdWx0IElzb2xhdGlvbiBhbmQgUmVj b3ZlcnkNCj4gDQo+ICAgMTk4MiwgU3RhdHVzIFVOS05PV04uLi4NCj4gDQo+IF0gbyAgW1JGQzA4 MTddIG9uICJNb2R1bGFyaXR5IGFuZCBlZmZpY2llbmN5IGluIHByb3RvY29sDQo+IF0gICAgaW1w bGVtZW50YXRpb24iDQo+IA0KPiAgIDE5ODIsIFN0YXR1cyBVTktOT1dOLi4uDQo+IA0KPiBdIG8g IFtSRkMwODcyXSBvbiAiVENQLW9uLWEtTEFOIg0KPiANCj4gICAxOTgyLCBTdGF0dXMgVU5LTk9X Ti4uLg0KPiANCj4gXSBvICBbUkZDMDg5Nl0gb24gIkNvbmdlc3Rpb24gQ29udHJvbCBpbiBJUC9U Q1AgSW50ZXJuZXR3b3JrcyINCj4gDQo+ICAgMTk4NCwgU3RhdHVzIFVOS05PV04uLi4NCj4gDQo+ IF0gbyAgW1JGQzA5NjRdIG9uICJTb21lIHByb2JsZW1zIHdpdGggdGhlIHNwZWNpZmljYXRpb24g b2YgdGhlIE1pbGl0YXJ5DQo+IF0gICAgIFN0YW5kYXJkIFRyYW5zbWlzc2lvbiBDb250cm9sIFBy b3RvY29sIg0KPiANCj4gICAxOTg1LCBTdGF0dXMgVU5LTk9XTuKApg0KDQpJIG5lZWQgdG8gbG9v ayBpbiBSRkMgOTY0IGFnYWluLiBNYXliZSB3ZSBjYW4gb2Jzb2xldGUgdGhpcyBvbmUuDQoNCj4g DQo+IC0tDQo+IEpvaG4gTGVzbGllIDxqb2huQGpsYy5uZXQ+DQoNCg== From nobody Thu Oct 23 03:41:36 2014 Return-Path: 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 C7D2B1A8A72 for ; Thu, 23 Oct 2014 03:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N69MjK61g4DZ for ; Thu, 23 Oct 2014 03:41:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D8E1A89AE for ; Thu, 23 Oct 2014 03:41:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNY71187; Thu, 23 Oct 2014 10:41:28 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Oct 2014 11:41:25 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 23 Oct 2014 18:41:21 +0800 From: "Huangyihong (Rachel)" To: Hagen Paul Pfeifer Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JremrgmuTy1lke6ElwLaFnR9pw6BACAgAAO5YCAAFHTgIAAHxSAgAEpTkD///RsAIABzoyQ Date: Thu, 23 Oct 2014 10:41:20 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8624A492@nkgeml501-mbs.china.huawei.com> References: <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rVXb3HB4MQVzvNJCmms-iWlVUbo Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:41:34 -0000 SGkgSGFnZW4sDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpCUiwNClJhY2hlbA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhhZ2VuIFBhdWwgUGZlaWZlciBbbWFpbHRv OmhhZ2VuQGphdXUubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjIsIDIwMTQgMTA6 MDAgUE0NCj4gVG86IEh1YW5neWlob25nIChSYWNoZWwpDQo+IENjOiBNaWNoYWVsIFdlbHpsOyB0 Y3BtQGlldGYub3JnOyBKb2UgVG91Y2gNCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0 aWFsLXdpbmRvdy0wMC50eHQNCj4gDQo+IEBydW5hOiB5b3VyIG1haWxlciBzZWVtcyB0byBzZW5k IHJhbmRvbWx5IGVtYWlsIC4uLiA7KA0KPiANCj4gT24gMjIgT2N0b2JlciAyMDE0IDExOjU3LCBI dWFuZ3lpaG9uZyAoUmFjaGVsKSA8cmFjaGVsLmh1YW5nQGh1YXdlaS5jb20+DQo+IHdyb3RlOg0K PiANCj4gPiBUaGUgbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0IGlzIHRoYXQgd2UgdGhpbmsgZGlm ZmVyZW50IGFwcGxpY2F0aW9ucyBtYXkgaGF2ZQ0KPiB0aGVpciBkaWZmZXJlbnQgcmVxdWlyZW1l bnRzIGZvciBJVyB0byBhY2hpZXZlIGJlc3QgcGVyZm9ybWFuY2UuIEFuZCBtYXliZQ0KPiBkaWZm ZXJlbnQgZmxvd3MgZm9yIG9uZSBhcHBsaWNhdGlvbiBtYXkgaGF2ZSBkaWZmZXJlbnQgcmVxdWly ZW1lbnRzIChlLmcuLCBzaG9ydA0KPiBmbG93cyBtZW50aW9uZWQgYnkgUnVuYSkuIEN1cnJlbnQg Z2xvYmFsIElXIHBhcmFtZXRlciBtYXkgbm90IHdlbGwgc2F0aXNmeQ0KPiBzdWNoIHJlcXVpcmVt ZW50cy4gU28gd2UgYnJpbmcgdXAgaXQgZm9yIGRpc2N1c3Npb246IGNvbmZpZ3VyZSBJVyBkeW5h bWljYWxseQ0KPiBieSBBUEkuIEhvd2V2ZXIsIHdlIGFyZSBub3Qgc3VnZ2VzdGluZyB0aGF0IHVz ZXJzIGltcGxlbWVudCBpdCB3aXRoDQo+IGV4YWdnZXJhdGVkIHZhbHVlcy4gV2UgdGhpbmsgZHlu YW1pY2FsbHkgc2V0dGluZyBJVyBpbiBhIHNhZmUgcmFuZ2Ugd291bGQgYmUNCj4gbm8gaGFybS4g VGhhdCBpcyB0byBzYXkgdGhlcmUgbXVzdCBoYXZlIGEgTUFYIElXIHRvIHJlc3RyaWN0IHRoZSBJ VyB2YWx1ZSBpbiBhbg0KPiBhcHByb3ByaWF0ZSByYW5nZSwgZS5nLiwgY3VycmVudCBJVz0xMCwg bWF5YmUgbGFyZ2VyIGluIHRoZSBmdXR1cmUuDQo+IA0KPiBIZXkgYWxsDQo+IA0KPiBsZXQgbWUg Z28gb25lIHN0ZXAgYmFjazogd2hhdCBhcHBsaWNhdGlvbiB3aWxsIGJlbmVmaXQgZnJvbSB0aGlz IGVmZm9ydD8NCj4gDQo+IC0gQnVsayBkYXRhIGFwcGxpY2F0aW9ucz8NCj4gLSBJbnRlcmFjdGl2 ZSwgY2hhdHR5IGFwcGxpY2F0aW9ucz8NCg0KW1JhY2hlbF06IEZvciBzaG9ydCBsaXZlIGZsb3dz IGFwcGxpY2F0aW9ucyBsaWtlIExhcmdlIHdlYnNpdGVzLCBzb2NpYWwgbmV0d29ya2luZyBhcHBs aWNhdGlvbnMgYW5kIG9ubGluZSBzaG9wcGluZyBhcHBsaWNhdGlvbnMuDQoNCj4gDQo+IE5vdCBy ZWFsbHksIG9ubHkgc2hvcnQgbGl2ZWQgZmxvd3Mgd2l0aCBhIHNwZWNpZmljIGFtb3VudCBvZiBk YXRhLg0KPiBXaGF0IGlzIHNwZWNpZmljPyBXZWxsIDEwICogTVNTIChhIHdpbmRvdykgaXMgaGFu ZGxlZCBjdXJyZW50bHkuIEF0IFJUVCAyIHdlDQo+IGhhdmUgYSB3aW5kb3cgb2YgMjAuIE9uZSBp dGVyYXRpb24gbGF0ZXIgNDAuDQo+IA0KPiBUaGF0IGJvaWxzIGRvd24gdG8gYXBwbGljYXRpb25z IHdpdGggYSBkYXRhIGFtb3VudCBpbiB0aGUgcmFuZ2Ugb2YgMTVrIHRvIDMwaywNCj4gbWluZCB5 b3UuIEJlbG93IDE1ayBJVzEwIGlzIGZpbmUsIGxhcmdlciB0aGFuIDMwayBhbmQgc2xvdyBzdGFy dCB3aWxsIGtpY2sgaW4NCj4gcXVpY2tseSAob3IgaW4gb3RoZXIgd29yZHMsIGFmdGVyIHNvbWUg YW1vdW50IG9mIGRhdGEgaXQgaXMgcmF0aGVyIGEgYnVsayBkYXRhDQo+IGFwcGxpY2F0aW9uLCBh biBlbGVwaGFudCkuDQo+IA0KPiBXaGF0IGFwcGxpY2F0aW9uIGlzIHRoaXM/IEhUVFAvMT8gV2hh dCBlbHNlPyBEb24ndCBnZXQgbWUgd3JvbmcsIHRoZSBlZmZvcnQgaXMNCj4gcHJvYmFibHkgd29y dGggLSBidXQgdG8gc2VlIGEgcmVhbCB1c2UgY2FzZSBtYXkgaGVscC4NCg0KW1JhY2hlbF06IFll cy4gTW9zdGx5IGZvciBIVFRQIGJ1dCBub3QgbGltaXRlZCB0by4gVGhlIG9ubGluZSBzaG9wcGlu ZyB3ZWJzaXRlIFRhb2JhbywgcHJvZHVjZWQgYnkgQWxpYmFiYSwgaXMgdXNpbmcgSVc9NyB0byBn ZXQgYmVzdCBwZXJmb3JtYW5jZS4gQW5kIGl0IHdpbGwgYmUgYmV0dGVyIHRoYXQgSVcgb2YgdGhl c2Ugc2hvcnQgZmxvd3MgY291bGQgYmUgZnVydGhlciByZWR1Y2VkIHRvIGF2b2lkIGNvbmdlc3Rp b24gd2hlbiB0aGUgbmV0d29yayBiZWNvbWVzIGJ1c3kgb24gIkRvdWJsZS0xMSIgc2hvcHBpbmcg ZmVzdGl2YWwgb2YgVGFvYmFvLg0KDQo+IA0KPiBIYWdlbg0K From nobody Thu Oct 23 03:43:45 2014 Return-Path: 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 72B471A8A72 for ; Thu, 23 Oct 2014 03:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 vQGANegRBaLb for ; Thu, 23 Oct 2014 03:43:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2284A1A89AE for ; Thu, 23 Oct 2014 03:43:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKV95412; Thu, 23 Oct 2014 10:43:35 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Oct 2014 11:43:34 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 23 Oct 2014 18:43:31 +0800 From: "Huangyihong (Rachel)" To: Runa Barik Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JremrgmuTy1lke6ElwLaFnR9pw6BACAgAAO5YCAAFHTgIAAHxSAgAEpTkD//9O+AIAAA4AAgAAFuwCAAfiQoA== Date: Thu, 23 Oct 2014 10:43:30 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8624A4A0@nkgeml501-mbs.china.huawei.com> References: <> <8FDE12E9-FE9C-4D8A-8B74-C2481B73EC06@ifi.uio.no> <20141021205701.GA6629@virgo.local> <51E6A56BD6A85142B9D172C87FC3ABBB86249F66@nkgeml501-mbs.china.huawei.com>, , <45750c362d3b4297a5ffd659e83fcec2@mail-ex12.exprod.uio.no> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/OD3HGFyvVIB4YLfq5_E7NYvWZqo Cc: "tcpm@ietf.org" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:43:40 -0000 Hi Runa, Great. We can cooperate on this work^^. BR, Rachel > -----Original Message----- > From: Runa Barik [mailto:runabk@ifi.uio.no] > Sent: Wednesday, October 22, 2014 8:36 PM > To: Huangyihong (Rachel) > Cc: tcpm@ietf.org; Michael Welzl; Joe Touch > Subject: RE: [tcpm] New Version Notification for > draft-you-tcpm-configuring-tcp-initial-window-00.txt >=20 > Hi all, >=20 > A typo. > ________________________________________ > From: tcpm on behalf of Runa Barik > > Sent: Wednesday, October 22, 2014 2:15 PM > To: Huangyihong (Rachel) > Cc: tcpm@ietf.org; Michael Welzl; Joe Touch > Subject: Re: [tcpm] New Version Notification for > draft-you-tcpm-configuring-tcp-initial-window-00.txt >=20 > Hi all, >=20 > On 2014-10-22 11:57, Huangyihong (Rachel) wrote: > > Hi Hagen, Micheal, Runa, Joe, and all, > > > > Thanks for your discussion on this draft. We barely catch up with your > > guys^^. We're new to the transport area, and very happy to see so many > > brilliant comments from all of you. They're highly appreciated. > > > > The motivation of this draft is that we think different applications > > may have their different requirements for IW to achieve best > > performance. >=20 > That's really a nice idea. >=20 > > And maybe different flows for one application may have different > > requirements (e.g., short flows mentioned by Runa). >=20 > This is what I worked during my master thesis. And we came with a simpl= e > function based on flow-sizes --- the larger the flow-size is, the smaller= the IW > should be. This function works better than a single constant IW for all f= lows. >=20 >=20 > > Current > > global IW parameter may not well satisfy such requirements. So we > > bring up it for discussion: configure IW dynamically by API. However, > > we are not suggesting that users implement it with exaggerated values. > > We think dynamically setting IW in a safe range would be no harm. That > > is to say there must have a MAX IW to restrict the IW value in an > > appropriate range, e.g., current IW=3D10, maybe larger in the future. >=20 > We implemented the IW function we proposed in LCN'13 inside Linux kernel, > version 3.7.4. However, we implemented in user space. I think it is *not= * > hard to implement inside kernel space. We also set a MAX IW. >=20 > > > > The idea Michael mentioned that using flow size instead of IW as input > > to the API seems good to me. But some algorithms must be figured out > > in the transport layer to convert applications parameters like flow > > size to IW. It also may be a very hard work. > > >=20 >=20 > > Anyway, we're just at the very beginning of this work. And we didn't > > do a lot of experiments. But we will. >=20 > We had lots of simulations, and experiments in real testbed networks. > And they are accepted by WWIC'12, LCN'13, NoF'14, etc. >=20 > > > > BR, > > Jianjie & Rachel > > >=20 > Regards, > - Runa >=20 >=20 > >> -----Original Message----- > >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Hagen Paul > >> Pfeifer > >> Sent: Wednesday, October 22, 2014 4:57 AM > >> To: Michael Welzl > >> Cc: tcpm@ietf.org; Joe Touch > >> Subject: Re: [tcpm] New Version Notification for > >> draft-you-tcpm-configuring-tcp-initial-window-00.txt > >> > >> * Michael Welzl | 2014-10-21 21:05:47 [+0200]: > >> > >>>> Question: what is the right IW for a given application? -> it is > >>>> not application specific - it is link specific! > >>> > >>> Here I'm not so sure, unless we go for extremes of course, as in > >>> your > >>> IW50 example. Generally I do see the point of Runa above, in trying > >>> to let short flows finish fast and get out of the network, it's a > >>> double benefit > >> somehow. > >> > >> I also see Runa's point and I know that in 95% a user/programmer will > >> setsockopt() IW to the wrong value - because he simple has no idea > >> about the link. I don't consider IW50 as an extreme I already saw > >> CDNs with a IW of 20. > >> So there is room left for more crazy values ;-) > >> > >> Furthermore, the "get packets quickly out of the pipe" argument will > >> show in a different light when considered in a sensor network. If we > >> have a valid information basis (TCP cache) the finish fast approach > >> may work - but we must make sure that the pipe is in principle > >> capable for the short IWx burst. IWx results in bursts and some > >> middle boxes are still not equipped for this (bufferbloat guys: yes, > >> this world exist ;). > >> > >>> Interesting; while RFC 2140 is absolutely on my radar (we do some > >>> quite closely related work in RMCAT), I forgot that it talks about > >>> IW. Can you provide more detail about what is implemented in Linux > >>> for the IW there - I thought by default none of this is happening > >>> for IW in Linux, all flows just get 10? > >> > >> IW is not cache driven in Linux - I don't wanted to claim this. But > >> there is absolutely no restriction to design and implement an > >> algorithm to do that! > >> Joe's I-D may be a starting point (using packet loss indications, use > >> a timeout after which the cached information is threated as outdated, > >> ...). > >> Similar to th RTT subsystem. > >> > >>> I agree that Ensemble Sharing could make sense for IW... however, > >>> thanks to ECMP, there is of course no guarantee that different > >>> connections to the same IP address really do traverse the same > >>> bottleneck. So an approach that uses e.g. IW1 for later-joining > >>> connections to the same IP address may be doing the exact right > >>> thing or may be too conservative, depending on whether ECMP is in > >>> place or not. Further, by applying this limitation only on later > >>> connections to the same IP address, it > >> may not kick in often enough. > >> > >> To some degree: yes. On the other the shorter the time difference > >> between flows the more likely the same path characteristics are still > >> valid. > >> Sure, cache > >> timeouts should make sure that the information is outdated after a > >> while > >> - no doubt. > >> > >>> Alternatively, giving a different IW to flows depending on their > >>> size may be doing the right thing more or less often... either way > >>> it's heuristics I > >> guess. > >>> I think both options are worth considering. Generally, giving a > >>> large IW only to short flows does strike me as reasonable because > >>> long flows simply won't benefit much from it. > >> > >> Probably - I must think about this. > >> > >>> My point in my previous email was only that no additional harm comes > >>> from letting the application tell the transport layer a desired IW > >>> (or maybe rather flow size, to allow transport to do the > >>> calculation), provided that an upper limit is imposed by the > >>> transport. > >> > >> Ok, got it. But then a setsockopt("SHORT_LIVED_FLOW") will be > >> adequate too, right!? Setting the IW is really complicated from a > >> programmer point of view, even a network guru may choose the wrong > >> value. I believe that this logic should be implemented and controlled > >> in the Kernel. > >> > >> Anyway, I understand the application argument and it may provide - > >> combined with the cached IW - a better behavior. > >> > >> Hagen > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Oct 23 07:39:23 2014 Return-Path: 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 B06481A90F5 for ; Thu, 23 Oct 2014 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 rw7bpkSJ1FWI for ; Thu, 23 Oct 2014 07:39:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19ACC1A899D for ; Thu, 23 Oct 2014 07:39:18 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-50.lsanca.dsl-w.verizon.net [71.103.148.50]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9NEcYDj014182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2014 07:38:43 -0700 (PDT) Message-ID: <544912EA.70404@isi.edu> Date: Thu, 23 Oct 2014 07:38:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: runabk References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> In-Reply-To: <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> Content-Type: text/plain; charset=UTF-8 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/SPRaM4CTwJc94VmSp-JCkY1aa58 Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 14:39:19 -0000 On 10/22/2014 1:46 AM, runabk wrote: > Hi all, > > On 2014-10-22 01:59, Joe Touch wrote: ... >> - IW cannot be determined at the time of the connection per se >> The only way to do so would be to send IW segments into the net and see >> if they get there, which isn't so much a probe as just using that value >> as the initial window anyway. >> >> I continue to believe that IW can be adapted over loooong periods of >> time using information on past connections as network behavior evolves >> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is >> definitely needed. >> > > In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the > connections at a particular instance start with nearly same IW value > --- a single constant window for all flows. I had been assuming 2140-style grouping of information based on network interface, destination IP address, destination subnet, etc. > My point is, why not to take a look on flow characteristics. I played > with a lot of simulations and experiments. > In my simulations in ns2, I considered a combination of flow types based > on sizes --- large flows from Pareto Distribution, and small flows from > Exponential Distribution. And we observed, large flows having a small > IW, and even randomly choosing a large IW for small flows gives better > performance than all the flows with IW10; Large flows are not as affected by IW effects because IW applies only during transients that are presumably rare (startup, restart after idle, etc.) The problem with your observation is that it fails to consider the "tragedy of the commons". Capacity is a common network resource, and your increase of IW for short flows causes them to consume that resource before feedback corrects it in ways that are not generally considered "fair". I.e., it's been known for a long time that making IW large helps short flows and has no real impact on long flows. It's also been known that this is not necessarily how we want the network to behave. There's a balance between trying to complete a short flow quickly and having flows that are basically non-responsive to network congestion. We only recently increased IW to 10 based on the assumption that "a problem we haven't seen doesn't exist". ... > A constant IW may not be suitable. If you have 2140 in place, you might have the information useful to set an appropriate IW on a per-connection basis. However, setting that value solely based on the length of the connection is (IMO) inappropriate. Joe From nobody Thu Oct 23 09:01:57 2014 Return-Path: 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 7132D1ACD49 for ; Thu, 23 Oct 2014 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 h2k80UlHWnsr for ; Thu, 23 Oct 2014 09:01:52 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825261ACD52 for ; Thu, 23 Oct 2014 09:01:52 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XhKpi-0000M8-VL; Thu, 23 Oct 2014 18:01:50 +0200 Received: from mail-ex01.exprod.uio.no ([129.240.52.4]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XhKpc-0005C0-Uj; Thu, 23 Oct 2014 18:01:50 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex01.exprod.uio.no (2001:700:100:52::4) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 23 Oct 2014 18:01:44 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Thu, 23 Oct 2014 18:01:44 +0200 From: Runa Barik To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAB6PQD//+tvgIAATT6AgACTPQCAAfSRAIAALhnR Date: Thu, 23 Oct 2014 16:01:43 +0000 Message-ID: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no>,<544912EA.70404@isi.edu> In-Reply-To: <544912EA.70404@isi.edu> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 148 max rcpts/h 17 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AC04B564E61356D47245E2F228DF6825EEBB6B61 X-UiO-SPAM-Test: remote_host: 129.240.52.4 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 353764 max/h 460 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/X46PRf3vzB_InlOHkCYqbbRmWU0 Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 16:01:55 -0000 Hi J. Touch,=0A= =0A= Comments inline.=0A= ________________________________________=0A= From: Joe Touch =0A= Sent: Thursday, October 23, 2014 4:38 PM=0A= To: Runa Barik=0A= Cc: Hagen Paul Pfeifer; Michael Welzl; tcpm@ietf.org=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= On 10/22/2014 1:46 AM, runabk wrote:=0A= > Hi all,=0A= >=0A= > On 2014-10-22 01:59, Joe Touch wrote:=0A= ...=0A= >> - IW cannot be determined at the time of the connection per se=0A= >> The only way to do so would be to send IW segments into the net and see= =0A= >> if they get there, which isn't so much a probe as just using that value= =0A= >> as the initial window anyway.=0A= >>=0A= >> I continue to believe that IW can be adapted over loooong periods of=0A= >> time using information on past connections as network behavior evolves= =0A= >> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is=0A= >> definitely needed.=0A= >>=0A= >=0A= > In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the=0A= > connections at a particular instance start with nearly same IW value=0A= > --- a single constant window for all flows.=0A= =0A= I had been assuming 2140-style grouping of information based on network=0A= interface, destination IP address, destination subnet, etc.=0A= =0A= > My point is, why not to take a look on flow characteristics. I played=0A= > with a lot of simulations and experiments.=0A= > In my simulations in ns2, I considered a combination of flow types based= =0A= > on sizes --- large flows from Pareto Distribution, and small flows from= =0A= > Exponential Distribution. And we observed, large flows having a small=0A= > IW, and even randomly choosing a large IW for small flows gives better=0A= > performance than all the flows with IW10;=0A= =0A= Large flows are not as affected by IW effects because IW applies only=0A= during transients that are presumably rare (startup, restart after idle,=0A= etc.)=0A= =0A= The problem with your observation is that it fails to consider the=0A= "tragedy of the commons". Capacity is a common network resource, and=0A= your increase of IW for short flows causes them to consume that resource=0A= before feedback corrects it in ways that are not generally considered=0A= "fair".=0A= =0A= RB -=0A= =0A= I agree with the above points. But consider the scenarios,=0A= (1) All flows start with say IW10; (2) The large flows start with=0A= IW as per rfc 3390, and small flows with IW10. Scenario (2) shows better= =0A= performance than scenario (1) in various network conditions. In scenario = (1),=0A= we observed large flows are affecting small flows more. However, in scena= rio (2), this negative=0A= effect on small flow is reduced . This motivates IW as a function. I agre= e with rfc 2140 =0A= that a past experience will help predicting a better value.=0A= =0A= RB -=0A= =0A= I.e., it's been known for a long time that making IW large helps short=0A= flows and has no real impact on long flows. It's also been known that=0A= this is not necessarily how we want the network to behave.=0A= =0A= RB -=0A= Consider a grass field and animals: goat and cow. If same amount of gra= ss will=0A= be given to both cow and goat, then cow will remain hungry later and goa= t will=0A= waste the grass. However, if cow and goat will get the amount they need, = probably=0A= no wastage, and no hungriness. That is my point, different applications m= ay need=0A= different values of IW for their best service requirements.=0A= =0A= RB -=0A= =0A= =0A= There's a balance between trying to complete a short flow quickly and=0A= having flows that are basically non-responsive to network congestion. We=0A= only recently increased IW to 10 based on the assumption that "a problem=0A= we haven't seen doesn't exist".=0A= =0A= ...=0A= > A constant IW may not be suitable.=0A= =0A= If you have 2140 in place, you might have the information useful to set=0A= an appropriate IW on a per-connection basis. However, setting that value=0A= solely based on the length of the connection is (IMO) inappropriate.=0A= =0A= Joe=0A= =0A= Regards,=0A= - Runa= From nobody Thu Oct 23 09:42:39 2014 Return-Path: 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 95BD41A9130 for ; Thu, 23 Oct 2014 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 dU0MCsBucLoF for ; Thu, 23 Oct 2014 09:42:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9849A1A90DE for ; Thu, 23 Oct 2014 09:42:36 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9NGfUS3010688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2014 09:41:33 -0700 (PDT) Message-ID: <54492FBA.7040002@isi.edu> Date: Thu, 23 Oct 2014 09:41:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Runa Barik References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no>, <544912EA.70404@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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/Izf2v56iK8XHzGjQTkuYd85-9vs Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 16:42:37 -0000 On 10/23/2014 9:01 AM, Runa Barik wrote: > consider the scenarios, > (1) All flows start with say IW10; (2) The large flows start with > IW as per rfc 3390, and small flows with IW10. Scenario (2) shows better > performance than scenario (1) in various network conditions. In scenario (1), > we observed large flows are affecting small flows more. However, in scenario (2), this negative > effect on small flow is reduced . Can you clarify what you saw? In particular, what does "shows better performance" mean? a) short flows complete more quickly b) all flows complete more quickly c) overall network loss is reduced These are competing goals. Joe From nobody Thu Oct 23 10:10:21 2014 Return-Path: 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 A44FD1ACD9E for ; Thu, 23 Oct 2014 10:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 JLF1QKBI62up for ; Thu, 23 Oct 2014 10:10:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6701ACD9A for ; Thu, 23 Oct 2014 10:10:17 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9NHA1KN019328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2014 10:10:01 -0700 (PDT) Message-ID: <54493668.8090301@isi.edu> Date: Thu, 23 Oct 2014 10:10:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <544709B5.3030605@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 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/6ppG3q9wIiPCkWDXYzGN8SX5GYY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 17:10:18 -0000 On 10/21/2014 8:54 PM, Yoshifumi Nishida wrote: > (as an individual of course..) > > I'm wondering if all negotiations need to be negotiated. The ones specified in RFC793 do not. All others need to be negotiated *if* you care that the other end supports it. That negotiation can happen at any point in the connection, but if it doesn't happen during the opening handshake then the option needs to be specified with its own 3WHS mechanism that can operate independently of segment loss and retransmission (which, IMO, is a bad idea). Some are confirmed in both directions (such as TS and WS), but others may need to have a "response" to a specific "request". Finally, there are options that aren't as much negotiated as they are either supported or not, e.g., MD5 and AO. There's no handshake. If the option is required on that connection and isn't present, segments are ignored anyway. I.e., a taxonomy should include, at a minimum: - always supported end-of-list NOP MSS - supported if enabled in both directions during the 3WHS TS, WS - request/response TFO, MPTCP, SACK - supported if enabled throughout the connection MD5, AO Joe From nobody Thu Oct 23 10:25:41 2014 Return-Path: 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 63E041ACD46 for ; Thu, 23 Oct 2014 10:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7lXd9VlTIXHQ for ; Thu, 23 Oct 2014 10:25:37 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A17A1A923E for ; Thu, 23 Oct 2014 10:25:37 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XhM8m-0001nX-1J; Thu, 23 Oct 2014 19:25:36 +0200 Received: from mail-ex12.exprod.uio.no ([129.240.120.74]) by mail-mx6.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1XhM8l-0008UP-M1; Thu, 23 Oct 2014 19:25:35 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex12.exprod.uio.no (2001:700:100:120::74) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 23 Oct 2014 19:25:34 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Thu, 23 Oct 2014 19:25:34 +0200 From: Runa Barik To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAB6PQD//+tvgIAATT6AgACTPQCAAfSRAIAALhnR///0QACAAC0B/A== Date: Thu, 23 Oct 2014 17:25:33 +0000 Message-ID: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no>,<544912EA.70404@isi.edu> , <54492FBA.7040002@isi.edu> In-Reply-To: <54492FBA.7040002@isi.edu> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 10 sum msgs/h 2 total rcpts 154 max rcpts/h 17 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8DC1B349A70163F5B5FF00C2BECAE1FC7A6B9223 X-UiO-SPAM-Test: remote_host: 129.240.120.74 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 31 total 326397 max/h 451 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/t_ft-5ED0XiqD6VPX54zPHyRIAc Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 17:25:39 -0000 Hi J. Touch,=0A= =0A= Comments inline.=0A= ________________________________________=0A= From: Joe Touch =0A= Sent: Thursday, October 23, 2014 6:41 PM=0A= To: Runa Barik=0A= Cc: Hagen Paul Pfeifer; Michael Welzl; tcpm@ietf.org=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= On 10/23/2014 9:01 AM, Runa Barik wrote:=0A= > consider the scenarios,=0A= > (1) All flows start with say IW10; (2) The large flows start with=0A= > IW as per rfc 3390, and small flows with IW10. Scenario (2) shows bette= r=0A= > performance than scenario (1) in various network conditions. In scenari= o (1),=0A= > we observed large flows are affecting small flows more. However, in sce= nario (2), this negative=0A= > effect on small flow is reduced .=0A= =0A= Can you clarify what you saw?=0A= =0A= In particular, what does "shows better performance" mean?=0A= =0A= a) short flows complete more quickly=0A= =0A= b) all flows complete more quickly=0A= =0A= c) overall network loss is reduced=0A= =0A= These are competing goals.=0A= =0A= BR -=0A= =0A= Both small and large flow complete quickly, and also =0A= reduced loss (retransmission rate, number of TO).=0A= =0A= Can you please have a look at the experimental results in this linked paper= , =0A= https://sites.google.com/site/dinild/papers/tcp-iw-lcn-2013.pdf?attredirec= ts=3D0, for more detail?=0A= =0A= BR -=0A= =0A= Joe=0A= =0A= Regards,=0A= - Runa= From nobody Thu Oct 23 12:19:19 2014 Return-Path: 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 0E78D1ACE4A for ; Thu, 23 Oct 2014 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 FkPzHODrJSr7 for ; Thu, 23 Oct 2014 12:19:09 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9D91A03C7 for ; Thu, 23 Oct 2014 12:19:05 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 805AAC94C0; Thu, 23 Oct 2014 15:19:02 -0400 (EDT) Date: Thu, 23 Oct 2014 15:19:02 -0400 From: John Leslie To: Joe Touch Message-ID: <20141023191902.GD525@verdi> References: <544709B5.3030605@isi.edu> <54493668.8090301@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54493668.8090301@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sAU47QaDr4gTyDuq_WD0M4uSXTI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:19:12 -0000 Joe Touch wrote: > On 10/21/2014 8:54 PM, Yoshifumi Nishida wrote: >> >> I'm wondering if all negotiations need to be negotiated. > > The ones specified in RFC793 do not. (Of course!) > All others need to be negotiated *if* you care that the other end > supports it. Quite true. But note that it's easy to imagine options where one endpoint _doesn't_ care if the other endpoint supports it. In fact, I expect to shortly submit a draft where this is the case. An endpoint sending it announces its own support for it; but unless the other endpoint also sends it, the first endpoint won't know whether it has been acted on in any way. > That negotiation can happen at any point in the connection, Currently, most options _are_ noted in the originating SYN, for several different reasons. First, the SYN and SYN-ACK are the only place in a TCP connection that you know the options won't be quietly dropped due to congestion. Also, there is a belief that TCP stacks are likely to fail to process options after the initial handshake unless they were negotiated during the SYN - SYN-ACK. (I am not aware of much evidence either way on that.) > but if it doesn't happen during the opening handshake then the option > needs to be specified with its own 3WHS mechanism that can operate > independently of segment loss and retransmission (which, IMO, is a bad > idea). I don't agree it's a "bad" idea, but it surely is more complicated. Please note, however, that a 3-way HandShake isn't the only way to synchronize sender's and receiver's views of an option being enabled. (It is usually the best, but not the only...) > Some are confirmed in both directions (such as TS and WS), but others > may need to have a "response" to a specific "request". That indeed is common; and it becomes complicated because either the request or the response can get dropped. > Finally, there are options that aren't as much negotiated as they are > either supported or not, e.g., MD5 and AO. There's no handshake. If the > option is required on that connection and isn't present, segments are > ignored anyway. True. And, IMHO, this is a rather important case. > I.e., a taxonomy should include, at a minimum: > > - always supported > end-of-list > NOP > MSS > > - supported if enabled in both directions during the 3WHS > TS, WS > > - request/response > TFO, MPTCP, SACK > > - supported if enabled throughout the connection > MD5, AO I'm hesitant to make statements like this: Each option should be defined to detail its rules; and we can never hope to cover the entire range of possible rules. Nonetheless, Joe is correct, so far as this goes. -- John Leslie From nobody Thu Oct 23 12:36:56 2014 Return-Path: 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 61BD91ACFD7 for ; Thu, 23 Oct 2014 12:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 EPuE8QRESyHS for ; Thu, 23 Oct 2014 12:36:46 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D711B1ACFCD for ; Thu, 23 Oct 2014 12:36:45 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9NJahYb010584; Thu, 23 Oct 2014 14:36:44 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <54493668.8090301@isi.edu> Date: Thu, 23 Oct 2014 14:36:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544709B5.3030605@isi.edu> <54493668.8090301@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XEXR1qlOoLLdopuU4jmlSTjgUmE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:36:54 -0000 > On Oct 23, 2014, at 12:10 PM, Joe Touch wrote: >=20 >=20 >=20 > On 10/21/2014 8:54 PM, Yoshifumi Nishida wrote: >> (as an individual of course..) >>=20 >> I'm wondering if all negotiations need to be negotiated.=20 >=20 > The ones specified in RFC793 do not. >=20 > All others need to be negotiated *if* you care that the other end > supports it. That negotiation can happen at any point in the = connection, > but if it doesn't happen during the opening handshake then the option > needs to be specified with its own 3WHS mechanism that can operate > independently of segment loss and retransmission (which, IMO, is a bad > idea). >=20 > Some are confirmed in both directions (such as TS and WS), but others > may need to have a "response" to a specific "request=E2=80=9D. Despite the muddled wording in RFC7323, it is the sending and receiving of the option in a packet with the SYN bit set that enables it. In the simultaneous open case, if you send and then receive , the option is enabled at that point. So the TSopt in the crossing packets is there because the option has already been enabled, not to enable it. But if for some reason the didn=E2=80=99t have TSopt, TSopt would still be enabled. Also with the simultaneous open case, TSopt can still be enabled even if one of the sides omitted it in its (and thus the other side omits it in its ): <-> <-> In this case TSopt is still enabled, because it was sent and received in a packet with the SYN bit. The left side enables it when it sends the , the right side enables it when it receives the . Though it shouldn=E2=80=99t happen, for completeness sake, this exchange = would also enable TSopt: <-> <-> All this also applies to WS. >=20 > Finally, there are options that aren't as much negotiated as they are > either supported or not, e.g., MD5 and AO. There's no handshake. If = the > option is required on that connection and isn't present, segments are > ignored anyway. >=20 > I.e., a taxonomy should include, at a minimum: >=20 > - always supported > end-of-list > NOP > MSS >=20 > - supported if enabled in both directions during the 3WHS > TS, WS >=20 > - request/response > TFO, MPTCP, SACK SACK isn=E2=80=99t request/response. If you receive SACK-Permitted in a = SYN packet, then SACK is enabled for output and you can send SACK in = non- packets. Thus it can be enabled in one direction only. >=20 > - supported if enabled throughout the connection > MD5, AO >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Oct 23 12:53:59 2014 Return-Path: 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 C50E71ACF00 for ; Thu, 23 Oct 2014 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 2lebuGo1nsG0 for ; Thu, 23 Oct 2014 12:53:55 -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 EC5BF1A0013 for ; Thu, 23 Oct 2014 12:53:54 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9NJrbS9018911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2014 12:53:38 -0700 (PDT) Message-ID: <54495CC1.10406@isi.edu> Date: Thu, 23 Oct 2014 12:53:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Borman References: <544709B5.3030605@isi.edu> <54493668.8090301@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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/jrOcqrN1SzRj3zLtVK07lpHSo7I Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:53:56 -0000 On 10/23/2014 12:36 PM, David Borman wrote: > >> On Oct 23, 2014, at 12:10 PM, Joe Touch wrote: >> >> >> >> On 10/21/2014 8:54 PM, Yoshifumi Nishida wrote: >>> (as an individual of course..) >>> >>> I'm wondering if all negotiations need to be negotiated. >> >> The ones specified in RFC793 do not. >> >> All others need to be negotiated *if* you care that the other end >> supports it. That negotiation can happen at any point in the connection, >> but if it doesn't happen during the opening handshake then the option >> needs to be specified with its own 3WHS mechanism that can operate >> independently of segment loss and retransmission (which, IMO, is a bad >> idea). >> >> Some are confirmed in both directions (such as TS and WS), but others >> may need to have a "response" to a specific "requestâ€. > > Despite the muddled wording in RFC7323, it is the sending and receiving > of the option in a packet with the SYN bit set that enables it. That enables the options in 7323, which are not all options. > In the simultaneous open case, if you send and then receive > , the option is enabled at that point. >From page 12 of RFC7323: Once TSopt has been successfully negotiated, that is both and contain TSopt, I.e., TS is not strictly enabled until both the SYN and SYN/ACK contain TS. I appreciate that I'm arguing with the author of that option, but it is the document that specifies the option, not the author's intent. Further, the only case it would matter is simultaneous open when both party sets TS in the SYNs and one decides to not set it in the SYN/ACK, which shouldn't happen anyway. > So the TSopt in the > crossing packets is there because the option has already > been enabled, not to enable it. But if for some reason the > didn’t have TSopt, TSopt would still be enabled. IMO, RFC7323 is clear in stating the opposite. Again, there are other reasons why this case shouldn't happen anyway. > Also with the simultaneous open case, TSopt can still be enabled even > if one of the sides omitted it in its (and thus the other side > omits it in its ): > > <-> > <-> > > In this case TSopt is still enabled, because it was sent and received > in a packet with the SYN bit. The left side enables it when it sends > the , the right side enables it when it receives the > . For similar reasons, I disagree. In this case, the left side should not send TS in the SYN/ACK anyway if it didn't send it in the SYN, IMO, so I don't think it should happen anyway either. > Though it shouldn’t happen, for completeness sake, this exchange would > also enable TSopt: > <-> > <-> > > All this also applies to WS. WS doesn't have the caveat that TS has, so I could imagine compliant implementations behaving differently in this case. >> Finally, there are options that aren't as much negotiated as they are >> either supported or not, e.g., MD5 and AO. There's no handshake. If the >> option is required on that connection and isn't present, segments are >> ignored anyway. >> >> I.e., a taxonomy should include, at a minimum: >> >> - always supported >> end-of-list >> NOP >> MSS >> >> - supported if enabled in both directions during the 3WHS >> TS, WS >> >> - request/response >> TFO, MPTCP, SACK > > SACK isn’t request/response. If you receive SACK-Permitted in a SYN > packet, then SACK is enabled for output and you can send SACK in non- > packets. Thus it can be enabled in one direction only. Oh - yes. That's a new case: - indicate support SACK i.e., unidirectional indication of a feature to be used in the reverse direction. Joe From nobody Thu Oct 23 13:45:06 2014 Return-Path: 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 270931AD3C5 for ; Thu, 23 Oct 2014 13:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 4vVnAVmbv7CG for ; Thu, 23 Oct 2014 13:45:02 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811751AD35E for ; Thu, 23 Oct 2014 13:45:01 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9NKixCv011071; Thu, 23 Oct 2014 15:44:59 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <54495CC1.10406@isi.edu> Date: Thu, 23 Oct 2014 15:44:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D91B13B-D03A-48AB-87B0-1F1D00DE2F10@weston.borman.com> References: <544709B5.3030605@isi.edu> <54493668.8090301@isi.edu> <54495CC1.10406@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ikaWFSDUE6HQBQq4mwGGV5rQXHc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 20:45:04 -0000 > On Oct 23, 2014, at 2:53 PM, Joe Touch wrote: > On 10/23/2014 12:36 PM, David Borman wrote: ... >> In the simultaneous open case, if you send and then = receive >> , the option is enabled at that point. >=20 >> =46rom page 12 of RFC7323: > Once TSopt has been successfully negotiated, that is both and > contain TSopt, >=20 > I.e., TS is not strictly enabled until both the SYN and SYN/ACK = contain TS. >=20 > I appreciate that I'm arguing with the author of that option, but it = is > the document that specifies the option, not the author's intent. > Further, the only case it would matter is simultaneous open when both > party sets TS in the SYNs and one decides to not set it in the = SYN/ACK, > which shouldn't happen anyway. >=20 >> So the TSopt in the >> crossing packets is there because the option has = already >> been enabled, not to enable it. But if for some reason the >> didn=E2=80=99t have TSopt, TSopt would still be enabled. >=20 > IMO, RFC7323 is clear in stating the opposite. Again, there are other > reasons why this case shouldn't happen anyway. RFC7323 is too explicit in its documentation of the optimization that during the normal 3WHS, if you don=E2=80=99t receive the option in the = , there is no point putting it into the because it won=E2=80=99t = be enabled anyway. That was always just an optimization from RFC 1072 which had the options being put in all SYN packets. It is the sending and receiving of the option in a SYN packet that enables the option, a SYN packet being one with the SYN bit set, so either a or a packet. >=20 >> Also with the simultaneous open case, TSopt can still be enabled even >> if one of the sides omitted it in its (and thus the other side >> omits it in its ): >>=20 >> <-> >> <-> >>=20 >> In this case TSopt is still enabled, because it was sent and received >> in a packet with the SYN bit. The left side enables it when it sends >> the , the right side enables it when it receives the >> . >=20 > For similar reasons, I disagree. In this case, the left side should = not > send TS in the SYN/ACK anyway if it didn't send it in the SYN, IMO, so = I > don't think it should happen anyway either. RFC7323 doesn=E2=80=99t say that. To quote another part in the same = section you quoted: A TCP MAY send the TSopt in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and MAY send a TSopt in only if it received a TSopt in the initial segment for the connection. The left side received so it can send , and the option is enabled. RFC7323 is missing the clear distinction that it is the sending and receiving of the TS/WS in packets with the SYN bit set that enable that option, irregardless of whether or not the packet has the ACK bit set. The wording in RFC7323 is the specific case of this for the 3WHS, e.g., the from the client and from the server are the only two packets with the SYN bit set. -David= From nobody Thu Oct 23 14:15:48 2014 Return-Path: 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 41B541A1AA5 for ; Thu, 23 Oct 2014 14:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 rXPHlVfrqUJc for ; Thu, 23 Oct 2014 14:15:45 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B03A11A1A22 for ; Thu, 23 Oct 2014 14:15:45 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BB504C94C4; Thu, 23 Oct 2014 17:15:41 -0400 (EDT) Date: Thu, 23 Oct 2014 17:15:41 -0400 From: John Leslie To: tcpm@ietf.org Message-ID: <20141023211541.GE525@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RUlds_QFV82SNJHfx060mAbofDQ Subject: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 21:15:47 -0000 ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 23 Oct 2014 13:28:51 -0700 From: internet-drafts@ietf.org Subject: New Version Notification for draft-leslie-tcpm-checksum-option-00.txt To: "John Leslie" , John Leslie A new version of I-D, draft-leslie-tcpm-checksum-option-00.txt has been successfully submitted by John Leslie and posted to the IETF repository. Name: draft-leslie-tcpm-checksum-option Revision: 00 Title: Checksum Option for TCP Document date: 2014-10-23 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-leslie-tcpm-checksum-option-00.txt Status: https://datatracker.ietf.org/doc/draft-leslie-tcpm-checksum-option/ Htmlized: http://tools.ietf.org/html/draft-leslie-tcpm-checksum-option-00 Abstract: There are a number of situations in TCP where middleboxes are known to change TCP-layer data; and it would be helpful for endpoints to detect such changes. TCP-Checksum is a TCP option to pass checksums over particular fields from sender to receiver, which can detect such changes by legacy middleboxes. This document also sets a rule for future middleboxes which insist upon modifying these checksums. ----- End forwarded message ----- This defines a way to request and/or pass checksums within TCP packets for diagnostic purposes and to verify integrity. I know Joe dislikes diagnostic tools ;^) but I'll be happy to work with him to add a way to send byte-count, which he _has_ agreed could make sense. Of course, the option name should change in that case... -- John Leslie From nobody Thu Oct 23 14:34:32 2014 Return-Path: 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 AEE721A1A9A for ; Thu, 23 Oct 2014 14:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 e4nHFSkJFH7U for ; Thu, 23 Oct 2014 14:34:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B5E1A0861 for ; Thu, 23 Oct 2014 14:34:29 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9NLXo81020985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2014 14:33:50 -0700 (PDT) Message-ID: <5449743E.60300@isi.edu> Date: Thu, 23 Oct 2014 14:33:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Leslie , tcpm@ietf.org References: <20141023211541.GE525@verdi> In-Reply-To: <20141023211541.GE525@verdi> Content-Type: text/plain; charset=windows-1252 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/IEbQfXvGAwwwK3t-jf2QtTgNxNM Subject: Re: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 21:34:30 -0000 On 10/23/2014 2:15 PM, John Leslie wrote: ... > I know Joe dislikes diagnostic tools ;^) but I'll be happy to work > with him to add a way to send byte-count, which he _has_ agreed could > make sense. Of course, the option name should change in that case... I actually don't hate such tools, as long as we build them for that purpose. This is a fine example, though I also think it's useful to just have a payload length option because checksums touch all the data which can be costly both computationally and from a memory access perspective. Joe From nobody Thu Oct 23 15:05:48 2014 Return-Path: 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 0AC7C1A1BDA for ; Thu, 23 Oct 2014 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 3WP4cjls-FYP for ; Thu, 23 Oct 2014 15:05:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A9B1A1A1C05 for ; Thu, 23 Oct 2014 15:05:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id A321CC94C0; Thu, 23 Oct 2014 18:05:37 -0400 (EDT) Date: Thu, 23 Oct 2014 18:05:37 -0400 From: John Leslie To: Joe Touch Message-ID: <20141023220537.GF525@verdi> References: <20141023211541.GE525@verdi> <5449743E.60300@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5449743E.60300@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nwkHviiqM8RfdmjRMd2gfE9kqiA Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:05:45 -0000 Joe Touch wrote: > ... >> I know Joe dislikes diagnostic tools ;^) but I'll be happy to work >> with him to add a way to send byte-count, which he _has_ agreed could >> make sense. Of course, the option name should change in that case... > > I actually don't hate such tools, as long as we build them for that > purpose. This is a fine example, though I also think it's useful to just > have a payload length option because checksums touch all the data which > can be costly both computationally and from a memory access perspective. Checksums certainly can be expensive for middleboxes; but IMHO the expense for endpoints _usually_ becomes small in comparison to the round-trip-time. Obviously, YMMV. I'm happy to add simple byte-count; but I'm not sure where to add it. One particular issue is how big the count can grow. Right now, we're thinking less than 256 bytes of options, but that obviously might grow to 65536 -- and I'm nervous to say that, with jumbograms, it might not someday exceed 65536... If we're sure it'll never need to exceed 65535, I'd be happy to drop the three- and four-octet formats, and we could have one bit for length vs. checksum. If we're not sure of that, we could change the "field-covered" bits to define whether we're talking checksum or byte-count; and I'm not too worried about running out of possibilities for "fields"... -- John Leslie From nobody Thu Oct 23 15:28:40 2014 Return-Path: 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 EB8C71A6F21 for ; Thu, 23 Oct 2014 15:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7QoKYSF9SODk for ; Thu, 23 Oct 2014 15:28:33 -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 4A5041AD54B for ; Thu, 23 Oct 2014 15:28:33 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9NMSECA005244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Oct 2014 15:28:15 -0700 (PDT) Message-ID: <544980FE.10307@isi.edu> Date: Thu, 23 Oct 2014 15:28:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Leslie References: <20141023211541.GE525@verdi> <5449743E.60300@isi.edu> <20141023220537.GF525@verdi> In-Reply-To: <20141023220537.GF525@verdi> Content-Type: text/plain; charset=windows-1252 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/BnyZCsbWhxu7W-2wYgK4q6viI_4 Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:28:38 -0000 On 10/23/2014 3:05 PM, John Leslie wrote: > Joe Touch wrote: >> ... >>> I know Joe dislikes diagnostic tools ;^) but I'll be happy to work >>> with him to add a way to send byte-count, which he _has_ agreed could >>> make sense. Of course, the option name should change in that case... >> >> I actually don't hate such tools, as long as we build them for that >> purpose. This is a fine example, though I also think it's useful to just >> have a payload length option because checksums touch all the data which >> can be costly both computationally and from a memory access perspective. > > Checksums certainly can be expensive for middleboxes; but IMHO the > expense for endpoints _usually_ becomes small in comparison to the > round-trip-time. Obviously, YMMV. > > I'm happy to add simple byte-count; but I'm not sure where to add it. > One particular issue is how big the count can grow. Right now, we're > thinking less than 256 bytes of options, but that obviously might grow > to 65536 -- and I'm nervous to say that, with jumbograms, it might not > someday exceed 65536... I'd say at least 1K because the length of options is probably easier to convey in units of 4-byte words, as DO is already encoded. Note that we might end up caring about the length of the user data (and whether it changes), not just the options. E.g., if the header has TCP-AO, you care whether the rest of the user data was split or not... Joe From nobody Thu Oct 23 19:06:04 2014 Return-Path: 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 EC35C1AD8F2 for ; Thu, 23 Oct 2014 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 ko4Ec8E175_m for ; Thu, 23 Oct 2014 19:05:55 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33B1AD8F6 for ; Thu, 23 Oct 2014 19:05:55 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s9O25rb4028247 for ; Thu, 23 Oct 2014 22:05:53 -0400 Received: (qmail 3659 invoked by uid 0); 24 Oct 2014 02:05:53 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 24 Oct 2014 02:05:53 -0000 Message-ID: <5449B3FA.1060601@mti-systems.com> Date: Thu, 23 Oct 2014 22:05:46 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , tcpm@ietf.org References: <20141023211541.GE525@verdi> In-Reply-To: <20141023211541.GE525@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5H8lqmf14hASMC4GoJHjR2c_9rM Subject: Re: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 02:05:57 -0000 On 10/23/2014 5:15 PM, John Leslie wrote: > > A new version of I-D, draft-leslie-tcpm-checksum-option-00.txt > has been successfully submitted by John Leslie and posted to the > IETF repository. > > Name: draft-leslie-tcpm-checksum-option Thanks for submitting this; I think it's interesting and useful for some of the issues being discussed currently, as noted in the draft. Here are some questions and suggestions: - Is the "request" mechanism really necessary? I think this is something you either send when doing risky things, or don't, but in any case, it's triggered by the sender. I think we would tie a dependency to do this into any other options that are presumed to be risky (e.g. EDO). - If the request mechanism is necessary, then do we really need to be able to dynamically request the other side to turn the different checksums on and off? I can't imagine logic doing that, but I might just be uncreative or unperceptive of the need. - In section 5, I was confused ... I had assumed that the 16-bit and longer values were computed using the sum of 16-bit or longer values (not 8-bit values), but the text here only talks about byte-wide inputs. -- Wes Eddy MTI Systems From nobody Fri Oct 24 00:58:03 2014 Return-Path: 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 95A561AD6C9 for ; Fri, 24 Oct 2014 00:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ur9SjbWI8p2A for ; Fri, 24 Oct 2014 00:58:00 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12251A88F0 for ; Fri, 24 Oct 2014 00:57:59 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XhZkz-0005Dc-R5; Fri, 24 Oct 2014 09:57:57 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XhZkz-0000Wu-9V; Fri, 24 Oct 2014 09:57:57 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <544912EA.70404@isi.edu> Date: Fri, 24 Oct 2014 09:57:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 6 sum msgs/h 3 total rcpts 21661 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D3B9726E0DDF25A04363895C1781F024AD4221F3 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 1 bait 0 mail/h: 3 total 6607 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6B4eDfAm1pVycaHa9YK8UDTtswU Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 07:58:02 -0000 Hi Joe, In line: On 23. okt. 2014, at 16:38, Joe Touch wrote: >=20 >=20 > On 10/22/2014 1:46 AM, runabk wrote: >> Hi all, >>=20 >> On 2014-10-22 01:59, Joe Touch wrote: > ... >>> - IW cannot be determined at the time of the connection per se >>> The only way to do so would be to send IW segments into the net and = see >>> if they get there, which isn't so much a probe as just using that = value >>> as the initial window anyway. >>>=20 >>> I continue to believe that IW can be adapted over loooong periods of >>> time using information on past connections as network behavior = evolves >>> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is >>> definitely needed. >>>=20 >>=20 >> In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the=20 >> connections at a particular instance start with nearly same IW value >> --- a single constant window for all flows. >=20 > I had been assuming 2140-style grouping of information based on = network > interface, destination IP address, destination subnet, etc. ...which I'm not sure would be a good idea here, see my previous = response to Hagen and also further below. >> My point is, why not to take a look on flow characteristics. I played >> with a lot of simulations and experiments. >> In my simulations in ns2, I considered a combination of flow types = based >> on sizes --- large flows from Pareto Distribution, and small flows = from >> Exponential Distribution. And we observed, large flows having a small >> IW, and even randomly choosing a large IW for small flows gives = better >> performance than all the flows with IW10; >=20 > Large flows are not as affected by IW effects because IW applies only > during transients that are presumably rare (startup, restart after = idle, > etc.) >=20 > The problem with your observation is that it fails to consider the > "tragedy of the commons". Capacity is a common network resource, and > your increase of IW for short flows causes them to consume that = resource > before feedback corrects it in ways that are not generally considered > "fair". So you're arguing that this work creates an incentive for applications = to make their flows shorter? Interesting. An application cheating the = system by splitting a large flow into small ones would have to weigh the = benefits of being able to use a larger IW against the cost of the = handshakes for closing and re-opening a connection, at least. Depending = on the IW calculation function in use, there can be corner cases where = such cheating might work, I think this should be addressed in the draft. > I.e., it's been known for a long time that making IW large helps short > flows and has no real impact on long flows. It's also been known that > this is not necessarily how we want the network to behave. >=20 > There's a balance between trying to complete a short flow quickly and > having flows that are basically non-responsive to network congestion. = We > only recently increased IW to 10 based on the assumption that "a = problem > we haven't seen doesn't exist". >=20 > ... >> A constant IW may not be suitable. >=20 > If you have 2140 in place, you might have the information useful to = set > an appropriate IW on a per-connection basis. However, setting that = value > solely based on the length of the connection is (IMO) inappropriate. So, I think it's the most appropriate thing that can be done, and RFC = 2140 can end up being less appropriate: 1) if you reduce IW on later connections to a host you're already = talking to (ensemble sharing) or have talked to before (temporal = sharing), ECMP may put you on a different path and you may end up being = too conservative. 2) if you ONLY apply 2140-style IW reduction, you may not be = conservative enough because all these first connections to various IP = addresses start with IW10 (which may not seem to matter if we think = about it from the perspective of a single web server, but certain web = pages open many *first* connections from many different IP addresses to = my browser, so then it's my access link that suffers). At the same time, using IW10 on large transfers is just useless. So I = think incorporating the flow length in the decision to only use a large = window when it can make sense is the best we can currently do. Cheers, Michael From nobody Fri Oct 24 01:18:07 2014 Return-Path: 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 E25751A88F1 for ; Fri, 24 Oct 2014 01:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 w8GvBOa8Yo9p for ; Fri, 24 Oct 2014 01:18:03 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F36901A88A9 for ; Fri, 24 Oct 2014 01:18:02 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id BC7AB2B444F; Fri, 24 Oct 2014 09:18:01 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Fri, 24 Oct 2014 09:18:01 +0100 Message-ID: In-Reply-To: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> Date: Fri, 24 Oct 2014 09:18:01 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dGGnQhmQQ4_hg5yIyKVT9onOQcE Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 08:18:06 -0000 I think this IW is not an appropriate parameter to present to the API, because the choice of value has a very significant impact on the robustness of the TCP service. An app can anyway decide to send less (defer sending a large volume of data straight away) - it is not in a place to decide the network path is safe to send more. Although if this were to be used as a part of the TCB sharing method (i.e. using cached network path state), that may be of value. Gorry > Hi Joe, > > In line: > > > On 23. okt. 2014, at 16:38, Joe Touch wrote: > >> >> >> On 10/22/2014 1:46 AM, runabk wrote: >>> Hi all, >>> >>> On 2014-10-22 01:59, Joe Touch wrote: >> ... >>>> - IW cannot be determined at the time of the connection per se >>>> The only way to do so would be to send IW segments into the net and >>>> see >>>> if they get there, which isn't so much a probe as just using that >>>> value >>>> as the initial window anyway. >>>> >>>> I continue to believe that IW can be adapted over loooong periods of >>>> time using information on past connections as network behavior evolves >>>> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is >>>> definitely needed. >>>> >>> >>> In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the >>> connections at a particular instance start with nearly same IW value >>> --- a single constant window for all flows. >> >> I had been assuming 2140-style grouping of information based on network >> interface, destination IP address, destination subnet, etc. > > ...which I'm not sure would be a good idea here, see my previous response > to Hagen and also further below. > > >>> My point is, why not to take a look on flow characteristics. I played >>> with a lot of simulations and experiments. >>> In my simulations in ns2, I considered a combination of flow types >>> based >>> on sizes --- large flows from Pareto Distribution, and small flows from >>> Exponential Distribution. And we observed, large flows having a small >>> IW, and even randomly choosing a large IW for small flows gives better >>> performance than all the flows with IW10; >> >> Large flows are not as affected by IW effects because IW applies only >> during transients that are presumably rare (startup, restart after idle, >> etc.) >> >> The problem with your observation is that it fails to consider the >> "tragedy of the commons". Capacity is a common network resource, and >> your increase of IW for short flows causes them to consume that resource >> before feedback corrects it in ways that are not generally considered >> "fair". > > So you're arguing that this work creates an incentive for applications to > make their flows shorter? Interesting. An application cheating the system > by splitting a large flow into small ones would have to weigh the benefits > of being able to use a larger IW against the cost of the handshakes for > closing and re-opening a connection, at least. Depending on the IW > calculation function in use, there can be corner cases where such cheating > might work, I think this should be addressed in the draft. > > >> I.e., it's been known for a long time that making IW large helps short >> flows and has no real impact on long flows. It's also been known that >> this is not necessarily how we want the network to behave. >> >> There's a balance between trying to complete a short flow quickly and >> having flows that are basically non-responsive to network congestion. We >> only recently increased IW to 10 based on the assumption that "a problem >> we haven't seen doesn't exist". >> >> ... >>> A constant IW may not be suitable. >> >> If you have 2140 in place, you might have the information useful to set >> an appropriate IW on a per-connection basis. However, setting that value >> solely based on the length of the connection is (IMO) inappropriate. > > So, I think it's the most appropriate thing that can be done, and RFC 2140 > can end up being less appropriate: > 1) if you reduce IW on later connections to a host you're already talking > to (ensemble sharing) or have talked to before (temporal sharing), ECMP > may put you on a different path and you may end up being too conservative. > 2) if you ONLY apply 2140-style IW reduction, you may not be conservative > enough because all these first connections to various IP addresses start > with IW10 (which may not seem to matter if we think about it from the > perspective of a single web server, but certain web pages open many > *first* connections from many different IP addresses to my browser, so > then it's my access link that suffers). > > At the same time, using IW10 on large transfers is just useless. So I > think incorporating the flow length in the decision to only use a large > window when it can make sense is the best we can currently do. > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Oct 24 02:18:21 2014 Return-Path: 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 AA3B41AD8F1 for ; Fri, 24 Oct 2014 02:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 nYrse9PtOCte for ; Fri, 24 Oct 2014 02:18:09 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66F31A19E5 for ; Fri, 24 Oct 2014 02:18:09 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xhb0Z-0003BS-Fn; Fri, 24 Oct 2014 11:18:07 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Xhb0Z-0003DC-0B; Fri, 24 Oct 2014 11:18:07 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Fri, 24 Oct 2014 11:18:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 21674 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2ADEC0260F0047D9BEC8A604DA0044AABBAE8E86 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 6614 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/C799nmorbpi3rsGkPupGPTQ6fqc Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:18:17 -0000 On 24. okt. 2014, at 10:18, = wrote: > I think this IW is not an appropriate parameter to present to the API, > because the choice of value has a very significant impact on the > robustness of the TCP service. Actually the proposal that some of us agreed on in emails would not = expose the IW but let an application provide the length of its transfer. = What the OS does with this information is then up to the OS. > An app can anyway decide to send less (defer sending a large volume = of > data straight away) - it is not in a place to decide the network path = is > safe to send more. My interest is not in saying "it's safe to send more" but in saying = "let's only use a large IW (capped by whatever the current agreement is = - i.e. if folks use IW10, then that number is 10) for flows that can = really benefit from it". It just seems so wrong to me to use IW10 on = *all* flows irrespective of their length when it's used at all. > Although if this were to be used as a part of the TCB > sharing method (i.e. using cached network path state), that may be of > value. I don't see how (see my email to Joe). Maybe only when the same 5-tuple = is used again? Cheers, Michael From nobody Fri Oct 24 02:54:53 2014 Return-Path: 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 116391A890C for ; Fri, 24 Oct 2014 02:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Z08i6bEMNcIg for ; Fri, 24 Oct 2014 02:54:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1680B1A87C8 for ; Fri, 24 Oct 2014 02:54:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNZ67321; Fri, 24 Oct 2014 09:54:46 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Oct 2014 10:54:45 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.88]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 17:54:41 +0800 From: Youjianjie To: Michael Welzl , Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JrPCtpAH0i/a0KxVyvz5Xdu55w6BAGAgABYtgCAAAz2gIAATT6AgAMON2qAAJv7gIAAopuQ Date: Fri, 24 Oct 2014 09:54:41 +0000 Message-ID: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UdEEL2RnI9wHY43_I-uGKDTAjJk Cc: "tcpm@ietf.org" Subject: [tcpm] =?gb2312?b?tPC4tDogIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm?= =?gb2312?b?b3IgZHJhZnQteW91LXRjcG0tY29uZmlndXJpbmctdGNwLWluaXRpYWwtd2lu?= =?gb2312?b?ZG93LTAwLnR4dA==?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:54:51 -0000 SGkgTWljaGFlbCwgSm9lLA0KDQpQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4uLg0KDQpC UiwNCkppYW5qaWUNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiB0Y3BtIFttYWls dG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIE1pY2hhZWwgV2VsemwNCj4gt6LLzcqxvOQ6 IDIwMTTE6jEw1MIyNMjVIDE1OjU4DQo+IMrVvP7IyzogSm9lIFRvdWNoDQo+ILOty806IHRjcG1A aWV0Zi5vcmcNCj4g1vfM4jogUmU6IFt0Y3BtXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y DQo+IGRyYWZ0LXlvdS10Y3BtLWNvbmZpZ3VyaW5nLXRjcC1pbml0aWFsLXdpbmRvdy0wMC50eHQN Cj4gDQo+IEhpIEpvZSwNCj4gDQo+IEluIGxpbmU6DQo+IA0KPiANCj4gT24gMjMuIG9rdC4gMjAx NCwgYXQgMTY6MzgsIEpvZSBUb3VjaCB3cm90ZToNCj4gDQo+ID4NCj4gPg0KPiA+IE9uIDEwLzIy LzIwMTQgMTo0NiBBTSwgcnVuYWJrIHdyb3RlOg0KPiA+PiBIaSBhbGwsDQo+ID4+DQo+ID4+IE9u IDIwMTQtMTAtMjIgMDE6NTksIEpvZSBUb3VjaCB3cm90ZToNCj4gPiAuLi4NCj4gPj4+IC0gSVcg Y2Fubm90IGJlIGRldGVybWluZWQgYXQgdGhlIHRpbWUgb2YgdGhlIGNvbm5lY3Rpb24gcGVyIHNl IFRoZQ0KPiA+Pj4gb25seSB3YXkgdG8gZG8gc28gd291bGQgYmUgdG8gc2VuZCBJVyBzZWdtZW50 cyBpbnRvIHRoZSBuZXQgYW5kIHNlZQ0KPiA+Pj4gaWYgdGhleSBnZXQgdGhlcmUsIHdoaWNoIGlz bid0IHNvIG11Y2ggYSBwcm9iZSBhcyBqdXN0IHVzaW5nIHRoYXQNCj4gPj4+IHZhbHVlIGFzIHRo ZSBpbml0aWFsIHdpbmRvdyBhbnl3YXkuDQo+ID4+Pg0KPiA+Pj4gSSBjb250aW51ZSB0byBiZWxp ZXZlIHRoYXQgSVcgY2FuIGJlIGFkYXB0ZWQgb3ZlciBsb29vb25nIHBlcmlvZHMgb2YNCj4gPj4+ IHRpbWUgdXNpbmcgaW5mb3JtYXRpb24gb24gcGFzdCBjb25uZWN0aW9ucyBhcyBuZXR3b3JrIGJl aGF2aW9yDQo+ID4+PiBldm9sdmVzIGFzIHBlciBkcmFmdC10b3VjaC10Y3BtLWF1dG9tYXRpYy1p dy0wMy50eHQsIGJ1dCBtb3JlDQo+ID4+PiBleHBlcmllbmNlIGlzIGRlZmluaXRlbHkgbmVlZGVk Lg0KPiA+Pj4NCj4gPj4NCj4gPj4gSW4gdGhlIGRyYWZ0IGBgZHJhZnQtdG91Y2gtdGNwbS1hdXRv bWF0aWMtaXctMDMudHh0IiwgQWxsIHRoZQ0KPiA+PiBjb25uZWN0aW9ucyBhdCBhIHBhcnRpY3Vs YXIgaW5zdGFuY2Ugc3RhcnQgd2l0aCBuZWFybHkgc2FtZSBJVyB2YWx1ZQ0KPiA+PiAtLS0gYSBz aW5nbGUgY29uc3RhbnQgd2luZG93IGZvciBhbGwgZmxvd3MuDQo+ID4NCj4gPiBJIGhhZCBiZWVu IGFzc3VtaW5nIDIxNDAtc3R5bGUgZ3JvdXBpbmcgb2YgaW5mb3JtYXRpb24gYmFzZWQgb24NCj4g PiBuZXR3b3JrIGludGVyZmFjZSwgZGVzdGluYXRpb24gSVAgYWRkcmVzcywgZGVzdGluYXRpb24g c3VibmV0LCBldGMuDQo+IA0KPiAuLi53aGljaCBJJ20gbm90IHN1cmUgd291bGQgYmUgYSBnb29k IGlkZWEgaGVyZSwgc2VlIG15IHByZXZpb3VzIHJlc3BvbnNlIHRvDQo+IEhhZ2VuIGFuZCBhbHNv IGZ1cnRoZXIgYmVsb3cuDQo+IA0KPiANCj4gPj4gTXkgcG9pbnQgaXMsIHdoeSBub3QgdG8gdGFr ZSBhIGxvb2sgb24gZmxvdyBjaGFyYWN0ZXJpc3RpY3MuIEkgcGxheWVkDQo+ID4+IHdpdGggYSBs b3Qgb2Ygc2ltdWxhdGlvbnMgYW5kIGV4cGVyaW1lbnRzLg0KPiA+PiBJbiBteSBzaW11bGF0aW9u cyBpbiBuczIsIEkgY29uc2lkZXJlZCBhIGNvbWJpbmF0aW9uIG9mIGZsb3cgdHlwZXMNCj4gPj4g YmFzZWQgb24gc2l6ZXMgLS0tIGxhcmdlIGZsb3dzIGZyb20gUGFyZXRvIERpc3RyaWJ1dGlvbiwg YW5kIHNtYWxsDQo+ID4+IGZsb3dzIGZyb20gRXhwb25lbnRpYWwgRGlzdHJpYnV0aW9uLiBBbmQg d2Ugb2JzZXJ2ZWQsIGxhcmdlIGZsb3dzDQo+ID4+IGhhdmluZyBhIHNtYWxsIElXLCBhbmQgZXZl biByYW5kb21seSBjaG9vc2luZyBhIGxhcmdlIElXIGZvciBzbWFsbA0KPiA+PiBmbG93cyBnaXZl cyBiZXR0ZXIgcGVyZm9ybWFuY2UgdGhhbiBhbGwgdGhlIGZsb3dzIHdpdGggSVcxMDsNCj4gPg0K PiA+IExhcmdlIGZsb3dzIGFyZSBub3QgYXMgYWZmZWN0ZWQgYnkgSVcgZWZmZWN0cyBiZWNhdXNl IElXIGFwcGxpZXMgb25seQ0KPiA+IGR1cmluZyB0cmFuc2llbnRzIHRoYXQgYXJlIHByZXN1bWFi bHkgcmFyZSAoc3RhcnR1cCwgcmVzdGFydCBhZnRlcg0KPiA+IGlkbGUsDQo+ID4gZXRjLikNCj4g Pg0KPiA+IFRoZSBwcm9ibGVtIHdpdGggeW91ciBvYnNlcnZhdGlvbiBpcyB0aGF0IGl0IGZhaWxz IHRvIGNvbnNpZGVyIHRoZQ0KPiA+ICJ0cmFnZWR5IG9mIHRoZSBjb21tb25zIi4gQ2FwYWNpdHkg aXMgYSBjb21tb24gbmV0d29yayByZXNvdXJjZSwgYW5kDQo+ID4geW91ciBpbmNyZWFzZSBvZiBJ VyBmb3Igc2hvcnQgZmxvd3MgY2F1c2VzIHRoZW0gdG8gY29uc3VtZSB0aGF0DQo+ID4gcmVzb3Vy Y2UgYmVmb3JlIGZlZWRiYWNrIGNvcnJlY3RzIGl0IGluIHdheXMgdGhhdCBhcmUgbm90IGdlbmVy YWxseQ0KPiA+IGNvbnNpZGVyZWQgImZhaXIiLg0KPiANCj4gU28geW91J3JlIGFyZ3VpbmcgdGhh dCB0aGlzIHdvcmsgY3JlYXRlcyBhbiBpbmNlbnRpdmUgZm9yIGFwcGxpY2F0aW9ucyB0byBtYWtl DQo+IHRoZWlyIGZsb3dzIHNob3J0ZXI/IEludGVyZXN0aW5nLiBBbiBhcHBsaWNhdGlvbiBjaGVh dGluZyB0aGUgc3lzdGVtIGJ5IHNwbGl0dGluZw0KPiBhIGxhcmdlIGZsb3cgaW50byBzbWFsbCBv bmVzIHdvdWxkIGhhdmUgdG8gd2VpZ2ggdGhlIGJlbmVmaXRzIG9mIGJlaW5nIGFibGUgdG8NCj4g dXNlIGEgbGFyZ2VyIElXIGFnYWluc3QgdGhlIGNvc3Qgb2YgdGhlIGhhbmRzaGFrZXMgZm9yIGNs b3NpbmcgYW5kIHJlLW9wZW5pbmcgYQ0KPiBjb25uZWN0aW9uLCBhdCBsZWFzdC4gRGVwZW5kaW5n IG9uIHRoZSBJVyBjYWxjdWxhdGlvbiBmdW5jdGlvbiBpbiB1c2UsIHRoZXJlIGNhbg0KPiBiZSBj b3JuZXIgY2FzZXMgd2hlcmUgc3VjaCBjaGVhdGluZyBtaWdodCB3b3JrLCBJIHRoaW5rIHRoaXMg c2hvdWxkIGJlDQo+IGFkZHJlc3NlZCBpbiB0aGUgZHJhZnQuDQo+IA0KDQoNCklmIHRoZSBhcHBs aWNhdGlvbnMgYXJlIG5vdCB0cnVzdGVkLCB0aGVuIHRoZSBzeXN0ZW0gY291bGQgYWRkIHNvbWUg Y29uc3RyYWludHMsIHN1Y2ggYXMgbWF4aW11bSBJVy4gVGhpcyB2YWx1ZSBjb3VsZCBiZSBjb25m aWd1cmVkIGJ5IHRoZSBzeXN0ZW0uIE1lYW53aGlsZSwgdGhlIElXIG9mIHRoZSByZWNlaXZlciBz aG91bGQgYWxzbyBiZSBjb25zaWRlcmVkLiBJZiB0aGUgYXBwbGljYXRpb24gYXJlIHRydXN0ZWQs IHRoZW4gdGhpcyBpcyBub3QgYW4gaXNzdWUuIFNoYWxsIHdlIGFkZCBzdWNoIGRlc2NyaXB0aW9u cyBpbiB0aGUgZHJhZnQ/DQoNCg0KPiA+IEkuZS4sIGl0J3MgYmVlbiBrbm93biBmb3IgYSBsb25n IHRpbWUgdGhhdCBtYWtpbmcgSVcgbGFyZ2UgaGVscHMgc2hvcnQNCj4gPiBmbG93cyBhbmQgaGFz IG5vIHJlYWwgaW1wYWN0IG9uIGxvbmcgZmxvd3MuIEl0J3MgYWxzbyBiZWVuIGtub3duIHRoYXQN Cj4gPiB0aGlzIGlzIG5vdCBuZWNlc3NhcmlseSBob3cgd2Ugd2FudCB0aGUgbmV0d29yayB0byBi ZWhhdmUuDQo+ID4NCj4gPiBUaGVyZSdzIGEgYmFsYW5jZSBiZXR3ZWVuIHRyeWluZyB0byBjb21w bGV0ZSBhIHNob3J0IGZsb3cgcXVpY2tseSBhbmQNCj4gPiBoYXZpbmcgZmxvd3MgdGhhdCBhcmUg YmFzaWNhbGx5IG5vbi1yZXNwb25zaXZlIHRvIG5ldHdvcmsgY29uZ2VzdGlvbi4NCj4gPiBXZSBv bmx5IHJlY2VudGx5IGluY3JlYXNlZCBJVyB0byAxMCBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0 aGF0ICJhDQo+ID4gcHJvYmxlbSB3ZSBoYXZlbid0IHNlZW4gZG9lc24ndCBleGlzdCIuDQo+ID4N Cj4gPiAuLi4NCj4gPj4gQSBjb25zdGFudCBJVyBtYXkgbm90IGJlIHN1aXRhYmxlLg0KPiA+DQo+ ID4gSWYgeW91IGhhdmUgMjE0MCBpbiBwbGFjZSwgeW91IG1pZ2h0IGhhdmUgdGhlIGluZm9ybWF0 aW9uIHVzZWZ1bCB0bw0KPiA+IHNldCBhbiBhcHByb3ByaWF0ZSBJVyBvbiBhIHBlci1jb25uZWN0 aW9uIGJhc2lzLiBIb3dldmVyLCBzZXR0aW5nIHRoYXQNCj4gPiB2YWx1ZSBzb2xlbHkgYmFzZWQg b24gdGhlIGxlbmd0aCBvZiB0aGUgY29ubmVjdGlvbiBpcyAoSU1PKSBpbmFwcHJvcHJpYXRlLg0K PiANCj4gU28sIEkgdGhpbmsgaXQncyB0aGUgbW9zdCBhcHByb3ByaWF0ZSB0aGluZyB0aGF0IGNh biBiZSBkb25lLCBhbmQgUkZDIDIxNDAgY2FuDQo+IGVuZCB1cCBiZWluZyBsZXNzIGFwcHJvcHJp YXRlOg0KPiAxKSBpZiB5b3UgcmVkdWNlIElXIG9uIGxhdGVyIGNvbm5lY3Rpb25zIHRvIGEgaG9z dCB5b3UncmUgYWxyZWFkeSB0YWxraW5nIHRvDQo+IChlbnNlbWJsZSBzaGFyaW5nKSBvciBoYXZl IHRhbGtlZCB0byBiZWZvcmUgKHRlbXBvcmFsIHNoYXJpbmcpLCBFQ01QIG1heSBwdXQNCj4geW91 IG9uIGEgZGlmZmVyZW50IHBhdGggYW5kIHlvdSBtYXkgZW5kIHVwIGJlaW5nIHRvbyBjb25zZXJ2 YXRpdmUuDQo+IDIpIGlmIHlvdSBPTkxZIGFwcGx5IDIxNDAtc3R5bGUgSVcgcmVkdWN0aW9uLCB5 b3UgbWF5IG5vdCBiZSBjb25zZXJ2YXRpdmUNCj4gZW5vdWdoIGJlY2F1c2UgYWxsIHRoZXNlIGZp cnN0IGNvbm5lY3Rpb25zIHRvIHZhcmlvdXMgSVAgYWRkcmVzc2VzIHN0YXJ0IHdpdGgNCj4gSVcx MCAgKHdoaWNoIG1heSBub3Qgc2VlbSB0byBtYXR0ZXIgaWYgd2UgdGhpbmsgYWJvdXQgaXQgZnJv bSB0aGUNCj4gcGVyc3BlY3RpdmUgb2YgYSBzaW5nbGUgd2ViIHNlcnZlciwgYnV0IGNlcnRhaW4g d2ViIHBhZ2VzIG9wZW4gbWFueSAqZmlyc3QqDQo+IGNvbm5lY3Rpb25zIGZyb20gbWFueSBkaWZm ZXJlbnQgSVAgYWRkcmVzc2VzIHRvIG15IGJyb3dzZXIsIHNvIHRoZW4gaXQncyBteQ0KPiBhY2Nl c3MgbGluayB0aGF0IHN1ZmZlcnMpLg0KPiANCj4gQXQgdGhlIHNhbWUgdGltZSwgdXNpbmcgSVcx MCBvbiBsYXJnZSB0cmFuc2ZlcnMgaXMganVzdCB1c2VsZXNzLiBTbyBJIHRoaW5rDQo+IGluY29y cG9yYXRpbmcgdGhlIGZsb3cgbGVuZ3RoIGluIHRoZSBkZWNpc2lvbiB0byBvbmx5IHVzZSBhIGxh cmdlIHdpbmRvdyB3aGVuIGl0DQo+IGNhbiBtYWtlIHNlbnNlIGlzIHRoZSBiZXN0IHdlIGNhbiBj dXJyZW50bHkgZG8uDQo+IA0KPiBDaGVlcnMsDQo+IE1pY2hhZWwNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0 DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90Y3BtDQo= From nobody Fri Oct 24 04:11:40 2014 Return-Path: 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 1B13A1A89B5 for ; Fri, 24 Oct 2014 04:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Q4koJmCDsC2M for ; Fri, 24 Oct 2014 04:11:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF121A8993 for ; Fri, 24 Oct 2014 04:11:34 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 4C8121B5D337E; Fri, 24 Oct 2014 11:11:31 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9OBBN6k008975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 13:11:31 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 13:11:26 +0200 From: "Scharf, Michael (Michael)" To: Michael Welzl , Gorry Fairhurst Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JrlQwXqnfP+VEK9XtW6PcZDjJw6aJaAgABYtgCAAAz2gIAATT6AgAKpoK2AAQCSgIAABZ6AgAAQyICAADuogA== Date: Fri, 24 Oct 2014 11:11:25 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JbJhypbVXQHmQYY-mjhVXMnieWc Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 11:11:38 -0000 > > I think this IW is not an appropriate parameter to present to the > API, > > because the choice of value has a very significant impact on the > > robustness of the TCP service. >=20 > Actually the proposal that some of us agreed on in emails would not > expose the IW but let an application provide the length of its > transfer. What the OS does with this information is then up to the OS. This idea has been out there for a while. For instance, see in http://www.i= kr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Section = 5.1.1 or specifically Section 5.1.1.3. This reference is probably not the f= irst time this kind of API was proposed, but out of my head I don't recall = other references. Based on my past work, I'd suggest to survey what applications can indeed p= rovide that sort of information. A while back I had a prototype with a Web = server for such an API, but it as far as I remember it really depends on th= e content and the server architecture whether that kind of information can = indeed be provided to the TCP stack. Until it is clear that this type of AP= I is indeed doable, this topic seems to me more research than engineering. Michael (obviously with chair hat off) From nobody Fri Oct 24 04:25:22 2014 Return-Path: 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 A86731A8A9A for ; Fri, 24 Oct 2014 04:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 mLuYGV-KHeUj for ; Fri, 24 Oct 2014 04:25:17 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65401A8A90 for ; Fri, 24 Oct 2014 04:25:17 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Xhczb-0004Uz-PN; Fri, 24 Oct 2014 13:25:15 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Xhczb-0004Tk-6b; Fri, 24 Oct 2014 13:25:15 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 24 Oct 2014 13:25:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 10 sum msgs/h 5 total rcpts 21683 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 88C2125E57D7FA1287F74983C0CCF0296E5D235A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 6620 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xw2ic7ukf0nKyOWEXAmjoxqCqdg Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 11:25:20 -0000 On 24. okt. 2014, at 13:11, Scharf, Michael (Michael) wrote: >>> I think this IW is not an appropriate parameter to present to the >> API, >>> because the choice of value has a very significant impact on the >>> robustness of the TCP service. >>=20 >> Actually the proposal that some of us agreed on in emails would not >> expose the IW but let an application provide the length of its >> transfer. What the OS does with this information is then up to the = OS. >=20 > This idea has been out there for a while. For instance, see in = http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112= .pdf Section 5.1.1 or specifically Section 5.1.1.3. This reference is = probably not the first time this kind of API was proposed, but out of my = head I don't recall other references. >=20 > Based on my past work, I'd suggest to survey what applications can = indeed provide that sort of information. A while back I had a prototype = with a Web server for such an API, but it as far as I remember it really = depends on the content and the server architecture whether that kind of = information can indeed be provided to the TCP stack. Until it is clear = that this type of API is indeed doable, this topic seems to me more = research than engineering. I actually don't get that: obviously you'd only apply it *when* an = application can specify a file length. For static files, web servers can = do that (no doubt that web servers don't provide only static content). = By "only apply" I mean: when an application doesn't specify anything, = you get the system default IW. Cheers, Michael From nobody Fri Oct 24 04:51:59 2014 Return-Path: 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 EBCF41A8A6E for ; Fri, 24 Oct 2014 04:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 hDwxU1RuR01e for ; Fri, 24 Oct 2014 04:51:54 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229701A8A96 for ; Fri, 24 Oct 2014 04:51:53 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so2460161lab.5 for ; Fri, 24 Oct 2014 04:51:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3PT34gUNzfXa3as2Krdm0MdXqiGRkldWvJE146hoQOc=; b=D4lpEOL82Or7Tz7nzdKvzAqQJANY1c39P621uJrmA7IqpqPb9+48MdklnIU6C1PYju r8M62hg9qbH26Wk5/QP0rg1eZw7RgFmig0g14q1BMiuQgnO6Olen+ShCGXVQzkY1/CyC px7HWfJuCKbGuRY9+8cgQVgXOxNkHgaBmL33TDN7p9F2f32PFWMBU3WotcFn1t7AjQ5B nrfB0QAAJCBAMj7fVJPUXS9cLPOseWvuZzX64R8XHwOsSd/pkdYWG1vVCe+HUL5ueRUw YMzBYk2RmySgjqs8tITiIhEJIDSHaTMuWGviAUD9gkh2ibn5ZwE19V/MNSnS+tyVb+ip xTuA== X-Gm-Message-State: ALoCoQk4ZmT7/iNiYahUCZifm0g7FE1WvV5/HW/3IWfOW+HtshSRihX+9gvYbGRNEWhkHE4watWT MIME-Version: 1.0 X-Received: by 10.112.11.133 with SMTP id q5mr3861186lbb.77.1414151512281; Fri, 24 Oct 2014 04:51:52 -0700 (PDT) Received: by 10.25.21.67 with HTTP; Fri, 24 Oct 2014 04:51:52 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> Date: Fri, 24 Oct 2014 13:51:52 +0200 Message-ID: From: Hagen Paul Pfeifer To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7PxYQO1nDyYLJYYyMIXLmi2IzT0 Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 11:51:56 -0000 On 24 October 2014 11:18, Michael Welzl wrote: > Actually the proposal that some of us agreed on in emails would not expose the IW but let an application provide the length of its transfer. What the OS does with this information is then up to the OS. +1, setting IW directly is far from being adequate for the user. The user can - similar to other kernel parameters - give an *hint* about application characteristics. It is up the the kernel to follow then or ignore then completely. This is a good design. Maybe "expected data length" is a good starting point. Hagen From nobody Fri Oct 24 05:03:41 2014 Return-Path: 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 3E09C1A8A9B for ; Fri, 24 Oct 2014 05:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 TYd3eGamwxbM for ; Fri, 24 Oct 2014 05:03:38 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8D61A7001 for ; Fri, 24 Oct 2014 05:03:38 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id z12so2671779lbi.2 for ; Fri, 24 Oct 2014 05:03:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l+vbk294Asf4Qbltr0/FxiyoC4qVl7mQjaiuCw3DdXA=; b=PmL0GX9e02LARYC6FCyc6hGmjMxbNNwEeRmTpSdCduamY0oPQ65V/7vkYaOJV5WABM PYTOqBg9OFrPUZ4OhCNWN8/Tk+yPhwdmVw7rv8VtprYsnaefg93mEj8YDL2/IEQC+/g2 HqcrgskkO4BPlhglIg6Zj146ALj1qFUVBMaLtzpFR5roLgpiKrfzq/TiBpxwXEOgYAwK 4bObBNfn5zq6J14fwzycAB+AkJKuXO6LiXrap3zocnbc3mO+x6T69Oabb5jT4TQ8dNKe gXu+jjFtsQS9BFdX7t1+OWIqHSp38gDU6eKOsm8T8U/W9f+/Pre1Xn/qDlCfaYGKyL0Y kA8A== X-Gm-Message-State: ALoCoQnsvWAPKRzzjsUpFbq3wsqVsOWuzCWPXZjL8xrMbw/MAByldyBZRO4eT3CuXsfHdmhmydX5 MIME-Version: 1.0 X-Received: by 10.152.198.166 with SMTP id jd6mr2853019lac.81.1414152216170; Fri, 24 Oct 2014 05:03:36 -0700 (PDT) Received: by 10.25.21.67 with HTTP; Fri, 24 Oct 2014 05:03:36 -0700 (PDT) X-Originating-IP: [80.246.32.33] In-Reply-To: <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 24 Oct 2014 14:03:36 +0200 Message-ID: From: Hagen Paul Pfeifer To: "Scharf, Michael (Michael)" , Youjianjie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nf3W2vvnTXlC9RvtzTYccZfiMug Cc: "tcpm@ietf.org Extensions" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:03:40 -0000 On 24 October 2014 13:11, Scharf, Michael (Michael) wrote: > Based on my past work, I'd suggest to survey what applications can indeed= provide that sort of information. A while back I had a prototype with a We= b server for such an API, but it as far as I remember it really depends on = the content and the server architecture whether that kind of information ca= n indeed be provided to the TCP stack. Until it is clear that this type of = API is indeed doable, this topic seems to me more research than engineering= . Absolutely! Until now we identified several risks/inconsistency - on the other hand it is hard to see real world use-cases where the API change is beneficial. More research is clearly required. And bye the way, this API change even exists in a form of a prime-time ready patch for Linux Kernel 4 years ago! This patch even include a upper system limit sysctl. Everyone should read this email thread because the arguments are equally. E.g. IW is not a user thing, the kernel should handle this automatically, ... http://thread.gmane.org/gmane.linux.network/162103 Hagen From nobody Fri Oct 24 08:02:09 2014 Return-Path: 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 254B01A1A1D for ; Fri, 24 Oct 2014 08:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 iD6OXjjcbpD5 for ; Fri, 24 Oct 2014 08:01:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65951A1A1C for ; Fri, 24 Oct 2014 08:01:53 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B6D45CE55969B; Fri, 24 Oct 2014 15:01:49 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9OF1pQU013275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 17:01:51 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 17:01:51 +0200 From: "Scharf, Michael (Michael)" To: Michael Welzl Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JrlQwXqnfP+VEK9XtW6PcZDjJw6aJaAgABYtgCAAAz2gIAATT6AgAKpoK2AAQCSgIAABZ6AgAAQyICAADuogP//59wAgABbNkA= Date: Fri, 24 Oct 2014 15:01:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no> In-Reply-To: <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/npfWAwAc5lIjUI7CNAo6UsYlwHQ Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:02:01 -0000 > >>> I think this IW is not an appropriate parameter to present to the > >> API, > >>> because the choice of value has a very significant impact on the > >>> robustness of the TCP service. > >> > >> Actually the proposal that some of us agreed on in emails would not > >> expose the IW but let an application provide the length of its > >> transfer. What the OS does with this information is then up to the > OS. > > > > This idea has been out there for a while. For instance, see in > http://www.ikr.uni- > stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Section > 5.1.1 or specifically Section 5.1.1.3. This reference is probably not > the first time this kind of API was proposed, but out of my head I > don't recall other references. > > > > Based on my past work, I'd suggest to survey what applications can > indeed provide that sort of information. A while back I had a prototype > with a Web server for such an API, but it as far as I remember it > really depends on the content and the server architecture whether that > kind of information can indeed be provided to the TCP stack. Until it > is clear that this type of API is indeed doable, this topic seems to me > more research than engineering. >=20 > I actually don't get that: obviously you'd only apply it *when* an > application can specify a file length. For static files, web servers > can do that (no doubt that web servers don't provide only static > content). By "only apply" I mean: when an application doesn't specify > anything, you get the system default IW. Disclaimer: I haven't looked into that question in the last years. However, as far as I recall, I used lighttpd in my past experiments in 2008= /2009 because in that code I could access the content length directly in th= e function that contained the actual socket calls. In other Web servers tha= t I checked at that time, there were wrapper functions e.g. by libraries to= hide the socket API from the actual server logic. Being able to pass the f= ile length to the socket would have implied a complete change of that libra= ry API. This is a less low-hanging fruit than adding just the "setsockopt" = call. I haven't looked at Java-based servers. A research study could have a look which software would actually allow such= an API change, and how disruptive that change would be for the overall sof= tware architecture. Michael From nobody Fri Oct 24 08:13:31 2014 Return-Path: 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 014351A1A46 for ; Fri, 24 Oct 2014 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 WGr5WhSONAhh for ; Fri, 24 Oct 2014 08:13:25 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46011A1A28 for ; Fri, 24 Oct 2014 08:13:03 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so540204igb.8 for ; Fri, 24 Oct 2014 08:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Fb+ElrsqtnzT4JsdqsKmcSkCsZI1gnVSpD/udWgTr4c=; b=WtQ4uDyrgQS4OGgGN6Q3FQSzSaBrjyM4hLOPJDAOHHBLuDPsc9YdxFhV4RkrRz+8Lh K/lWXZsOKKS4nXcK+omCND/BXUUM+YI5wXzZ1oXk2JALE+JJFpjxj89zu/b3POO6pFOa 3zEXn5iWmDFNhcGJ+ubPY1l98l/sDuuhsBulrBogltFSHTvKN6mKkfMZWXqjsqAlsf2d uwwYJw//uijrfKIFi8OEuVS1Lc3N7Q1bIP37tSpJhOF0V1X6z4rTmeC45Ajz+DZXKwet qgBHKBgv3foqG7/X00PG1zqgql8Y/fT2gLo+1crlw1yCvZan/SmBX8se1oBNAaZGxqVT nofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Fb+ElrsqtnzT4JsdqsKmcSkCsZI1gnVSpD/udWgTr4c=; b=juyXp0CE3sYEMaOKS//ZycWTj7uUsoKGJvUUxNc2kyc49/iC7PnIymTTAINej3Xjsb 2j4AzFhU+3uaEgT1LhTAlv5eEC4PfmRn3llPri+VgL4nmTzDaPUscJa/8OOe1C7hsJJh n1STyor7Em7tH14E3NirlFzct6l0QngLm3Tg9YAH6INw1T8iBt6nIgLvxs4SVXZmM2EQ brIw4dHLp2+D/ThCL7tS6zVk+Bi3KRTOzLBxzqbzz5433Wd7lqX9NHlP5d58xVy1P72F sCJlgFw9cOoFuGV0vbcQVQahRcF7fb2GoDV64t/HshuBs4C7ntt9+WEFbpRRRJlqmH4X jgsQ== X-Gm-Message-State: ALoCoQnbdGutN+QYPi+B+0FyazfeD3Qez7hhlF8MzEU2tAssDlJSvOIZhUIl8uj3qDYoKtPehMND X-Received: by 10.107.10.82 with SMTP id u79mr3073295ioi.46.1414163583161; Fri, 24 Oct 2014 08:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.168 with HTTP; Fri, 24 Oct 2014 08:12:22 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no> <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Fri, 24 Oct 2014 23:12:22 +0800 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/whGrFUsyjtXApZAO9AC441jQBys Cc: "tcpm@ietf.org Extensions" , Michael Welzl , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:13:27 -0000 Why has the thread morphed into 1. should app set IW 2. what's the right IW Michael has already pointed out early that socket API is out of scope of tcpm. Period. From nobody Fri Oct 24 08:33:33 2014 Return-Path: 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 63B5C1A0B00 for ; Fri, 24 Oct 2014 08:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 XumeHxcOUdm0 for ; Fri, 24 Oct 2014 08:33:31 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4291F1A06E9 for ; Fri, 24 Oct 2014 08:33:31 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id x19so2476644ier.5 for ; Fri, 24 Oct 2014 08:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HS2wnZ5hBmEgBUZ/Q9vL1PHL8QVclGeEQycIUa4gEsw=; b=dGT+cYJeZy8RuCCgjKGzYiY+AaduOugaO3++1sibkgjnbknv0tjM4FKVmNxPDwdQNr Q0m1UHiJ6H6R78DoyWOUXrmft8YnAb+1fU1bbBW2NKPRE2RbBVpwoeVTeuPrKnECfIke zrKDHWNU75cJU+nC17mqRUdBM+4XYMY0zPVk6HsDACXnlwX4Q7qgwBh4DZIQRyR2MA0x 7hvg4ofcPFiavDFuA86KpKZagMkCiqCByZhaBD63EQ16zmkuTlCGisx2KgTDETa8GOhj zUUcwenOFmkFSwFO46lpKCDFj95UqSOX6HSjdiVJoE6iRIZraiKlY5ORpvn0zlXE0XAh HEbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HS2wnZ5hBmEgBUZ/Q9vL1PHL8QVclGeEQycIUa4gEsw=; b=Lt/lHshnlM5VQw+K50DP8dLf/PhmMaTrovvFNcBOesPrZs3V0GEIw1FkOG+T1gT/YX hw39wQ3uls17jk2VkphhNK01gV8ZTta3LPZ/EFYMaLdrMDN5Su1kgdp4BfoEh6+OKhmI AXZqnnpzNwASXa3SyHNae1g+Usl+c4DPBMqvbEwWrISZoUKv5/ouxj3t4ewwKOX/so1j GpAL1GIVr6tLUnYaWxM/sHZkt1LxyAEPISRpXlela/KHpErVU8uXRY96GF1utKqtaCE1 hTYJruxCiDqldcJZeIO2XcOM54D3bi6h/05iVLn1GX8JZeXYMVvZ4u0ORnyxs+m1VQ3k ENDA== X-Gm-Message-State: ALoCoQmFL6OWLH4eRChKcc8pUmBO7dUT5uidCxJdz82YjJPkcztCM0iaTB2q61ZYjMrA/5TOWXdl X-Received: by 10.107.7.10 with SMTP id 10mr1843158ioh.85.1414164810663; Fri, 24 Oct 2014 08:33:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.168 with HTTP; Fri, 24 Oct 2014 08:32:50 -0700 (PDT) In-Reply-To: <544708C1.7020006@isi.edu> References: <544708C1.7020006@isi.edu> From: Yuchung Cheng Date: Fri, 24 Oct 2014 23:32:50 +0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3zGZC1b9fvR9PTu-niHMHAVe830 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] simultaneous open with different options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:33:32 -0000 On Wed, Oct 22, 2014 at 9:30 AM, Joe Touch wrote: > Hi, all, > > One of the questions that has kept coming up regarding SYN option > extension has to do with options that differ during simultaneous open. > > IMO, it'd be useful to understand what happens in the current case > before assuming we can solve this case for extensions. > > Here's the scenario > > host A host B > > SYN w/X -> <- SYN w/Y > > What happens next? > > AFAICT, it depends on a few things: > > - whether host A supports Y > > - whether host B supports X > > I.e., let's say that: > > host A supports Y What existing option is like Y? i.e. not announce in SYN but acknowledge its support if the remote peer announces it. > > host B does NOT support X > > in that case, the next step would be: > > host A host B > > SYN/ACK w/XY -> <- SYN/ACK w/- > > I.e., A supports both X and Y, and B supports neither. > > At this point, the final ACK is critical to the completion of the > exchange, because it's where A finds out that neither option should be used: > > ACK w/- -> <- ACK w/- > > (these ACKs happen if both sides agree to skip the options they > requested. if not, then they drop the connection and send a RST) > > Is there any agreement on this point? > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Oct 24 08:35:13 2014 Return-Path: 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 D683B1A1A5E for ; Fri, 24 Oct 2014 08:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 dH0ZioePDejI for ; Fri, 24 Oct 2014 08:35:07 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AC81A06E9 for ; Fri, 24 Oct 2014 08:35:07 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XhgtO-0007kQ-1b; Fri, 24 Oct 2014 17:35:06 +0200 Received: from mail-ex04.exprod.uio.no ([129.240.52.7]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1XhgtN-00021p-FS; Fri, 24 Oct 2014 17:35:05 +0200 Received: from mail-ex12.exprod.uio.no (2001:700:100:120::74) by mail-ex04.exprod.uio.no (2001:700:100:52::7) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 24 Oct 2014 17:35:03 +0200 Received: from mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b]) by mail-ex12.exprod.uio.no ([fe80::bdf0:8ebc:dd9c:548b%19]) with mapi id 15.00.0847.030; Fri, 24 Oct 2014 17:35:02 +0200 From: Runa Barik To: "Scharf, Michael (Michael)" , "Michael Welzl" Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7Jrf4gSerTsMrUKXfcSC/EOqOpw6aJaAgAB6PQD//+tvgIAATT6AgACTPQCAAfSRAIABImSAgAAFnoCAABDIgIAAH6uAgAAD2QCAADyHAIAAKJpa Date: Fri, 24 Oct 2014 15:35:01 +0000 Message-ID: References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no>, <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 165 max rcpts/h 17 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 265D020187FA0DBCC94FCD234E5E7D9D26814A19 X-UiO-SPAM-Test: remote_host: 129.240.52.7 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 57 total 358321 max/h 442 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/g0H0yT4vqjIEwFKKQtiBGAQZnoY Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:35:10 -0000 Hi,=0A= =0A= Comments inline.=0A= ________________________________________=0A= From: tcpm on behalf of Scharf, Michael (Michael) <= michael.scharf@alcatel-lucent.com>=0A= Sent: Friday, October 24, 2014 5:01 PM=0A= To: Michael Welzl=0A= Cc: tcpm@ietf.org Extensions; Joe Touch=0A= Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring= -tcp-initial-window-00.txt=0A= =0A= > >>> I think this IW is not an appropriate parameter to present to the=0A= > >> API,=0A= > >>> because the choice of value has a very significant impact on the=0A= > >>> robustness of the TCP service.=0A= > >>=0A= > >> Actually the proposal that some of us agreed on in emails would not=0A= > >> expose the IW but let an application provide the length of its=0A= > >> transfer. What the OS does with this information is then up to the=0A= > OS.=0A= > >=0A= > > This idea has been out there for a while. For instance, see in=0A= > http://www.ikr.uni-=0A= > stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Section=0A= > 5.1.1 or specifically Section 5.1.1.3. This reference is probably not=0A= > the first time this kind of API was proposed, but out of my head I=0A= > don't recall other references.=0A= > >=0A= > > Based on my past work, I'd suggest to survey what applications can=0A= > indeed provide that sort of information. A while back I had a prototype= =0A= > with a Web server for such an API, but it as far as I remember it=0A= > really depends on the content and the server architecture whether that=0A= > kind of information can indeed be provided to the TCP stack. Until it=0A= > is clear that this type of API is indeed doable, this topic seems to me= =0A= > more research than engineering.=0A= >=0A= > I actually don't get that: obviously you'd only apply it *when* an=0A= > application can specify a file length. For static files, web servers=0A= > can do that (no doubt that web servers don't provide only static=0A= > content). By "only apply" I mean: when an application doesn't specify=0A= > anything, you get the system default IW.=0A= =0A= Disclaimer: I haven't looked into that question in the last years.=0A= =0A= RB=0A= The idea mentioned above by Michael Welzl is the one I tested by using s= imulations in ns2, and =0A= experiments in testbed. There are couple of papers already published. = =0A= The function I used,=0A= =0A= if (flow-size <=3D theta)=0A= IW =3D MaxIW=0A= else=0A= IW =3D flow-size/theta * MaxIW + (1-flow-size/theta) * MinIW= =0A= =0A= where theta is the flow size threshold used to distinguish between= =0A= large flows and the rest, MinIW is the lower bound (four segments=0A= [RFC3390]), and MaxIW is the maximum IW that any connection can=0A= have (e.g. 10 [RFC6928]). The parameters, theta, MinIW and MaxIW are=0A= in number of TCP segments. Observe that, while small flows, defined=0A= by the threshold theta, will have IW as large as MaxIW, flows=0A= with size greater than theta will have IW closer to MinIW with=0A= increasing size.=0A= =0A= RB=0A= =0A= However, as far as I recall, I used lighttpd in my past experiments in 2008= /2009 because in that code I could access the content length directly in th= e function that contained the actual socket calls. In other Web servers tha= t I checked at that time, there were wrapper functions e.g. by libraries to= hide the socket API from the actual server logic. Being able to pass the f= ile length to the socket would have implied a complete change of that libra= ry API. This is a less low-hanging fruit than adding just the "setsockopt" = call. I haven't looked at Java-based servers.=0A= =0A= A research study could have a look which software would actually allow such= an API change, and how disruptive that change would be for the overall sof= tware architecture.=0A= =0A= Michael=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm= From nobody Fri Oct 24 09:00:00 2014 Return-Path: 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 E6EA41A1B70 for ; Fri, 24 Oct 2014 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 jHbn0s-1IOzZ for ; Fri, 24 Oct 2014 08:59:49 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B0C1A1B49 for ; Fri, 24 Oct 2014 08:59:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CDA09A05AD98C; Fri, 24 Oct 2014 15:59:44 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9OFxlMP020277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 17:59:47 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.81]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 17:59:47 +0200 From: "Scharf, Michael (Michael)" To: Runa Barik Thread-Topic: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt Thread-Index: AQHP7JrlQwXqnfP+VEK9XtW6PcZDjJw6aJaAgABYtgCAAAz2gIAATT6AgAKpoK2AAQCSgIAABZ6AgAAQyICAADuogP//59wAgABbNkD//+qXgIAAJE0A Date: Fri, 24 Oct 2014 15:59:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D166881C8@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no>, <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/rO-l_qgnSS6JaziQFoj3ByGcRzs Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:59:51 -0000 Runa, > The idea mentioned above by Michael Welzl is the one I tested by > using simulations in ns2, and > experiments in testbed. There are couple of papers already > published. For this discussion being relevant to TCPM, please focus how such a solutio= n could be engineered for general use in the global Internet, including the= different classes of applications and architectures implementing TCP. Thanks Michael From nobody Fri Oct 24 09:21:20 2014 Return-Path: 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 C7D031A6F22 for ; Fri, 24 Oct 2014 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PuwDUCcBsTwu for ; Fri, 24 Oct 2014 09:21:09 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2DB1A1B64 for ; Fri, 24 Oct 2014 09:21:08 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9OGL7pC027368 for ; Fri, 24 Oct 2014 11:21:07 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 11:21:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org (tcpm@ietf.org)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xA59Zwcn_0efcJow6bY382eBNEI Subject: Re: [tcpm] I-D Action: draft-borman-tcpm-tcp4way-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:21:13 -0000 I=E2=80=99ve just posted an update to the TCP Four-Way handshake = document. 1) I changed the name of the document to include tcpm: = draft-dborman-tcpm-tcp4way-00.txt 2) I=E2=80=99ve added text that any implementation that indicates = support for the Four-Way handshake is also indicating that it properly = handles unknown TCP options, as per RFC 1122. We keep dancing around = that issue, and this gives us a way to stop worrying about it anymore, = and a way for an implementation to know for sure that it isn=E2=80=99t = talking to a legacy TCP implementation. 3) I=E2=80=99ve added a preliminary section to discuss specific TCP = options 4) I=E2=80=99ve added text about the TS option to clarify RFC 7323, that = it is the presence of TSopt in both a sent and received packet with the = SYN bit that enables the option, i.e. it is not limited to the specific = instance of the and packets of the three-way handshake. And something entirely new: 5) I=E2=80=99ve added a new TCP option, the Unknown Option option. = Currently, the primary way to determine that the other side of the = connection doesn=E2=80=99t support a specific option is by lack of = response to that option, because it silently ignores it. The Unknown = Option option provides a mechanism where a TCP can inform the other side = that it does not understand or support any given option for a = connection. This can be very useful for sending TCP options in non-SYN = packets, especially if the option is not explicitly enabled through the = SYN exchange, or it is a one-way option. UTO comes to mind. The document needs more work, but I wanted to get an update out today, = before Mondays submission cutoff. -David Borman > On Oct 24, 2014, at 11:01 AM, Internet-Drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : TCP Four-Way Handshake > Author : David Borman > Filename : draft-borman-tcpm-tcp4way-00.txt > Pages : 21 > Date : 2014-10-24 >=20 > Abstract: > One of the limitations of TCP is that it has limited space for TCP > options, only 40 bytes. Many mechanisms have been proposed for for > extending the TCP option space, but the biggest challenge has been = to > get additional option space in the initial SYN packet. >=20 > This memo presents a optional four-way TCP handshake to allow > extended option space to be used in SYN packets in both directions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-borman-tcpm-tcp4way/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-borman-tcpm-tcp4way-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Oct 24 09:45:19 2014 Return-Path: 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 508B31A6FE7; Fri, 24 Oct 2014 09:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 f-xuMmxcCmg8; Fri, 24 Oct 2014 09:45:12 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA731A6F44; Fri, 24 Oct 2014 09:45:11 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XhhzC-0005bK-Gh; Fri, 24 Oct 2014 18:45:10 +0200 Received: from 25.71.202.84.customer.cdi.no ([84.202.71.25] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1XhhzB-0007f6-T5; Fri, 24 Oct 2014 18:45:10 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_8FD75BC9-BFCE-4B24-8016-EF48A7786985" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D166881C8@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 24 Oct 2014 18:45:08 +0200 Message-Id: <164A8875-F68A-4AF2-BCA0-525347008C4C@ifi.uio.no> References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> <655C07320163294895BBADA28372AF5D16687D24@FR712WXCHMBA15.zeu.alcatel-lucent.com> <2B509CEC-832B-4D4F-856E-E2F72A8325C1@ifi.uio.no> <, > <655C07320163294895BBADA28372AF5D16688066@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D166881C8@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 21712 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 923F0622B3BA85F7D376A8B168FA5B0E0BFCF5BE X-UiO-SPAM-Test: remote_host: 84.202.71.25 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 1 total 458 max/h 11 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/2Yhujl2z5WXpEl9vrSew-K0SfTg Cc: "tcpm@ietf.org Extensions" , iccrg@irtf.org Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:45:17 -0000 --Apple-Mail=_8FD75BC9-BFCE-4B24-8016-EF48A7786985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 24. okt. 2014, at 17.59, Scharf, Michael (Michael) = wrote: >=20 > Runa, >=20 >> The idea mentioned above by Michael Welzl is the one I tested by >> using simulations in ns2, and >> experiments in testbed. There are couple of papers already >> published. >=20 > For this discussion being relevant to TCPM, please focus how such a = solution could be engineered for general use in the global Internet, = including the different classes of applications and architectures = implementing TCP. I think that=E2=80=99s well worth looking into. Meanwhile, I sense some = annoyance with this discussion continuing in TCPM while it has already = been agreed that it should happen in ICCRG. My apologies, even though I = want more list traffic in ICCRG, I have been answering to TCPM too = without thinking much about that. All people involved in this discussion, let=E2=80=99s now really move = the thread over to iccrg@irtf.org and try to = make this the last message on the matter that has tcpm@ietf.org = in the recipient list. All others, sorry for the = continued noise. Cheers, Michael --Apple-Mail=_8FD75BC9-BFCE-4B24-8016-EF48A7786985 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 24. okt. 2014, at 17.59, Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:

Runa,

=   The idea mentioned above by Michael Welzl is the one I = tested by
using simulations in ns2, and
=  experiments  in testbed. There are couple of papers = already
published.

For this discussion being relevant to TCPM, please focus how = such a solution could be engineered for general use in the global = Internet, including the different classes of applications and = architectures implementing TCP.

I think that=E2=80=99s well worth looking into. = Meanwhile, I sense some annoyance with this discussion continuing in = TCPM while it has already been agreed that it should happen in ICCRG. My = apologies, even though I want more list traffic in ICCRG, I have been = answering to TCPM too without thinking much about that.

All people involved in this discussion, let=E2=80=99= s now really move the thread over to iccrg@irtf.org and try to make this the last message on = the matter that has tcpm@ietf.org in the recipient list. All others, = sorry for the continued noise.

Cheers,
Michael

= --Apple-Mail=_8FD75BC9-BFCE-4B24-8016-EF48A7786985-- From nobody Fri Oct 24 09:48:56 2014 Return-Path: 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 4AB441A86F7 for ; Fri, 24 Oct 2014 09:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Tz5UG6e2rDpb for ; Fri, 24 Oct 2014 09:48:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71151A1A40 for ; Fri, 24 Oct 2014 09:48:28 -0700 (PDT) Received: from [10.123.102.156] (usc-secure-wireless-206-156.usc.edu [68.181.206.156]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9OGle9b018878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2014 09:47:49 -0700 (PDT) References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <398949FE-4F05-40A4-B59B-729EDCEFCD45@isi.edu> X-Mailer: iPhone Mail (12B411) From: Joe Touch Date: Fri, 24 Oct 2014 09:47:39 -0700 To: "gorry@erg.abdn.ac.uk" 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/8KyLyVKypBeQVlxFe6cWuTTHPhs Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:48:53 -0000 +1 > On Oct 24, 2014, at 1:18 AM, gorry@erg.abdn.ac.uk wrote: > > I think this IW is not an appropriate parameter to present to the API, > because the choice of value has a very significant impact on the > robustness of the TCP service. > > An app can anyway decide to send less (defer sending a large volume of > data straight away) - it is not in a place to decide the network path is > safe to send more. Although if this were to be used as a part of the TCB > sharing method (i.e. using cached network path state), that may be of > value. > > Gorry > >> Hi Joe, >> >> In line: >> >> >>> On 23. okt. 2014, at 16:38, Joe Touch wrote: >>> >>> >>> >>>> On 10/22/2014 1:46 AM, runabk wrote: >>>> Hi all, >>>> >>>> On 2014-10-22 01:59, Joe Touch wrote: >>> ... >>>>> - IW cannot be determined at the time of the connection per se >>>>> The only way to do so would be to send IW segments into the net and >>>>> see >>>>> if they get there, which isn't so much a probe as just using that >>>>> value >>>>> as the initial window anyway. >>>>> >>>>> I continue to believe that IW can be adapted over loooong periods of >>>>> time using information on past connections as network behavior evolves >>>>> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is >>>>> definitely needed. >>>> >>>> In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the >>>> connections at a particular instance start with nearly same IW value >>>> --- a single constant window for all flows. >>> >>> I had been assuming 2140-style grouping of information based on network >>> interface, destination IP address, destination subnet, etc. >> >> ...which I'm not sure would be a good idea here, see my previous response >> to Hagen and also further below. >> >> >>>> My point is, why not to take a look on flow characteristics. I played >>>> with a lot of simulations and experiments. >>>> In my simulations in ns2, I considered a combination of flow types >>>> based >>>> on sizes --- large flows from Pareto Distribution, and small flows from >>>> Exponential Distribution. And we observed, large flows having a small >>>> IW, and even randomly choosing a large IW for small flows gives better >>>> performance than all the flows with IW10; >>> >>> Large flows are not as affected by IW effects because IW applies only >>> during transients that are presumably rare (startup, restart after idle, >>> etc.) >>> >>> The problem with your observation is that it fails to consider the >>> "tragedy of the commons". Capacity is a common network resource, and >>> your increase of IW for short flows causes them to consume that resource >>> before feedback corrects it in ways that are not generally considered >>> "fair". >> >> So you're arguing that this work creates an incentive for applications to >> make their flows shorter? Interesting. An application cheating the system >> by splitting a large flow into small ones would have to weigh the benefits >> of being able to use a larger IW against the cost of the handshakes for >> closing and re-opening a connection, at least. Depending on the IW >> calculation function in use, there can be corner cases where such cheating >> might work, I think this should be addressed in the draft. >> >> >>> I.e., it's been known for a long time that making IW large helps short >>> flows and has no real impact on long flows. It's also been known that >>> this is not necessarily how we want the network to behave. >>> >>> There's a balance between trying to complete a short flow quickly and >>> having flows that are basically non-responsive to network congestion. We >>> only recently increased IW to 10 based on the assumption that "a problem >>> we haven't seen doesn't exist". >>> >>> ... >>>> A constant IW may not be suitable. >>> >>> If you have 2140 in place, you might have the information useful to set >>> an appropriate IW on a per-connection basis. However, setting that value >>> solely based on the length of the connection is (IMO) inappropriate. >> >> So, I think it's the most appropriate thing that can be done, and RFC 2140 >> can end up being less appropriate: >> 1) if you reduce IW on later connections to a host you're already talking >> to (ensemble sharing) or have talked to before (temporal sharing), ECMP >> may put you on a different path and you may end up being too conservative. >> 2) if you ONLY apply 2140-style IW reduction, you may not be conservative >> enough because all these first connections to various IP addresses start >> with IW10 (which may not seem to matter if we think about it from the >> perspective of a single web server, but certain web pages open many >> *first* connections from many different IP addresses to my browser, so >> then it's my access link that suffers). >> >> At the same time, using IW10 on large transfers is just useless. So I >> think incorporating the flow length in the decision to only use a large >> window when it can make sense is the best we can currently do. >> >> Cheers, >> Michael >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From nobody Fri Oct 24 09:49:56 2014 Return-Path: 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 963A11A8704 for ; Fri, 24 Oct 2014 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 3Kw-jKO0UcTB for ; Fri, 24 Oct 2014 09:49:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789951A0231 for ; Fri, 24 Oct 2014 09:49:39 -0700 (PDT) Received: from [10.123.102.156] (usc-secure-wireless-206-156.usc.edu [68.181.206.156]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9OGle9c018878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Oct 2014 09:48:36 -0700 (PDT) References: <5446A7D4.5070607@ifi.uio.no> <20141021192331.GB4851@virgo.local> <5446F37F.7020007@isi.edu> <5c7b7a1f5b28bd321b30b660c9d3c8f6@ulrik.uio.no> <544912EA.70404@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (12B411) From: Joe Touch Date: Fri, 24 Oct 2014 09:48:36 -0700 To: Michael Welzl 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/VIdaNMEIZRLhpKExhOk-QkrfGb8 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:49:50 -0000 > On Oct 24, 2014, at 2:18 AM, Michael Welzl wrote: >=20 >=20 >> On 24. okt. 2014, at 10:18, = wrote: >>=20 >> I think this IW is not an appropriate parameter to present to the API, >> because the choice of value has a very significant impact on the >> robustness of the TCP service. >=20 > Actually the proposal that some of us agreed on in emails would not expose= the IW but let an application provide the length of its transfer. What the O= S does with this information is then up to the OS. Apps will lie.=20 >=20 >=20 >> An app can anyway decide to send less (defer sending a large volume of >> data straight away) - it is not in a place to decide the network path is >> safe to send more. >=20 > My interest is not in saying "it's safe to send more" but in saying "let's= only use a large IW (capped by whatever the current agreement is - i.e. if f= olks use IW10, then that number is 10) for flows that can really benefit fro= m it". It just seems so wrong to me to use IW10 on *all* flows irrespective o= f their length when it's used at all. >=20 >=20 >> Although if this were to be used as a part of the TCB >> sharing method (i.e. using cached network path state), that may be of >> value. >=20 > I don't see how (see my email to Joe). Maybe only when the same 5-tuple is= used again? >=20 > Cheers, > Michael >=20 From nobody Fri Oct 24 10:04:03 2014 Return-Path: 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 BAD811A875B for ; Fri, 24 Oct 2014 10:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 kklyMeTTNjvs for ; Fri, 24 Oct 2014 10:04:00 -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 D54821A8934 for ; Fri, 24 Oct 2014 09:57:43 -0700 (PDT) Received: from [10.123.103.120] (usc-secure-wireless-088-120.usc.edu [68.181.88.120]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9OGvP4E025968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Oct 2014 09:57:28 -0700 (PDT) Message-ID: <544A84F7.5080902@isi.edu> Date: Fri, 24 Oct 2014 09:57:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yuchung Cheng References: <544708C1.7020006@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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/dYdnqceNzbQ5QO2Na7y3QMFCbks Cc: "tcpm@ietf.org" Subject: Re: [tcpm] simultaneous open with different options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:04:02 -0000 On 10/24/2014 8:32 AM, Yuchung Cheng wrote: ... >> I.e., let's say that: >> >> host A supports Y > What existing option is like Y? i.e. not announce in SYN but > acknowledge its support if the remote peer announces it. AFAICT, TS and WS *can* work that way (at least). Joe From nobody Fri Oct 24 11:01:45 2014 Return-Path: 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 4E0A51A8A8D for ; Fri, 24 Oct 2014 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 fO-Oo14K74-h for ; Fri, 24 Oct 2014 11:01:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AD28B1A8A7B for ; Fri, 24 Oct 2014 11:01:34 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 04E40C94A9; Fri, 24 Oct 2014 14:01:31 -0400 (EDT) Date: Fri, 24 Oct 2014 14:01:31 -0400 From: John Leslie To: Joe Touch Message-ID: <20141024180131.GA60217@verdi> References: <20141023211541.GE525@verdi> <5449743E.60300@isi.edu> <20141023220537.GF525@verdi> <544980FE.10307@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544980FE.10307@isi.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EGVhYjiMCPVjjOJRpxo_4bcDYqw Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 18:01:42 -0000 Joe Touch wrote: > On 10/23/2014 3:05 PM, John Leslie wrote: >> >> I'm happy to add simple byte-count; but I'm not sure where to add it. >> One particular issue is how big the count can grow. Right now, we're >> thinking less than 256 bytes of options, but that obviously might grow >> to 65536 -- and I'm nervous to say that, with jumbograms, it might not >> someday exceed 65536... > > I'd say at least 1K because the length of options is probably easier to > convey in units of 4-byte words, as DO is already encoded. I won't object to counting option bytes that way, but I don't advise it. IMHO, 1024 bytes is not a good "forever" limit; nor do I believe that all the ways option space might be expanded will necessarily fall on 32-bit boundaries. The easier-to-code argument leaves me cold. > Note that we might end up caring about the length of the user data (and > whether it changes), not just the options. E.g., if the header has > TCP-AO, you care whether the rest of the user data was split or not... Good point. I did include a field-covered value for "TCP payload intended to go to the application. -- John Leslie From nobody Fri Oct 24 11:19:02 2014 Return-Path: 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 658611A8ADC for ; Fri, 24 Oct 2014 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 FFIowA_dqr4M for ; Fri, 24 Oct 2014 11:18:58 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D27521A8A7C for ; Fri, 24 Oct 2014 11:18:57 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 46AA9C94BE; Fri, 24 Oct 2014 14:18:55 -0400 (EDT) Date: Fri, 24 Oct 2014 14:18:55 -0400 From: John Leslie To: Wesley Eddy Message-ID: <20141024181855.GB60217@verdi> References: <20141023211541.GE525@verdi> <5449B3FA.1060601@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5449B3FA.1060601@mti-systems.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KlZrKYcDTX05xqkNswhtOVxnZkg Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 18:19:01 -0000 Wesley Eddy wrote: > On 10/23/2014 5:15 PM, John Leslie wrote: >> >> A new version of I-D, draft-leslie-tcpm-checksum-option-00.txt >> has been successfully submitted by John Leslie and posted to the >> IETF repository. >> >> Name: draft-leslie-tcpm-checksum-option > > Thanks for submitting this; I think it's interesting and useful > for some of the issues being discussed currently, as noted in > the draft. > > Here are some questions and suggestions: > > - Is the "request" mechanism really necessary? It was a design goal of mine to make it as unnecessary as possible: that you can never depend upon it being recevied: least of all acted upon. However, I did think it important that there should be a way to ask the other point to stop sending checksums; and it seemed useful to switch between always-send and send-once. > I think this is something you either send when doing risky things, > or don't, but in any case, it's triggered by the sender. It certainly will often be triggered by the sender. Just as an endpoint sending a request can't depend upon it being acted upon, neither can it depend upon not receiving an unsolicited checksum. > I think we would tie a dependency to do this into any other options > that are presumed to be risky (e.g. EDO). I would suggest that, especially for Bob's version which depends upon a "magic number". > - If the request mechanism is necessary, then do we really need > to be able to dynamically request the other side to turn the > different checksums on and off? I can't imagine logic doing > that, but I might just be uncreative or unperceptive of the need. I don't envision that for EDO; but I can imagine cases where the level of paranoia changes during a connection... > - In section 5, I was confused ... I had assumed that the 16-bit > and longer values were computed using the sum of 16-bit or > longer values (not 8-bit values), but the text here only talks > about byte-wide inputs. That is indeed what I intended. It was a fairly major design goal that it should be easy to _use_ a wrong-length checksum. I don't really see much need for three- or four-byte checksums, but I wanted one- and two-byte checksums to interoperate as simply as possible. I don't trust my memory about comparing two-byte checksums where one is generated from 8-bit arithmetic while the other is generated from 16-bit arithmetice -- except that both cases _can_ be reduced to 8-bits and then compared. (Somebody may wish to refresh my memory there.) I wouldn't _object_ to comparing two-byte checksums that way; but it seemed unwise while I was writing this... -- John Leslie From nobody Mon Oct 27 08:32:12 2014 Return-Path: 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 D3B4D1A88B2 for ; Mon, 27 Oct 2014 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 sPC7rhhhdMUj for ; Mon, 27 Oct 2014 08:32:09 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id DCECF1ACD6B for ; Mon, 27 Oct 2014 08:32:07 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.22) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 543C16C901215BF2 for tcpm@ietf.org; Mon, 27 Oct 2014 17:32:06 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9B0DBAE7-5E40-40B3-9813-459B9DB77797@iki.fi> Date: Mon, 27 Oct 2014 17:32:04 +0200 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7zXyNOokspmg0nvfQHo9mOspplQ Subject: [tcpm] Draft TCPM agenda for IETF-91 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:32:11 -0000 Hi, Here is the draft agenda for the TCPM meeting in Honolulu. There may be = some changes yet to come, especially on the middle part, which is still = under planning. - Pasi TCPM meeting, IETF-91, Honolulu, HI, USA Monday, November 10, 09:00 - 11:30 WG Status --------- Time: 5 minutes Working Group Items ------------------- * TCP and SCTP RTO Restart draft-ietf-tcpm-rtorestart Speaker: Michael Welzl Time: 15 minutes * TCP Extended Data Offset Option draft-ietf-tcpm-tcp-edo Speaker: Wes Eddy (?) Time: 20 minutes Placeholder for discussion on Advanced Extended Option Space solutions ---------------------------------------------------------------------- Time: 20 minutes Other Items ----------- * CUBIC for Fast Long-Distance Networks draft-zimmermann-tcpm-cubic Speaker: Alex Zimmermann Time: 10 min * TCP Retransmission Timer for Virtual Machines draft-heitzhe-tcpm-vm-rto-00 Speaker: Jakob Heitz Time: 10 minutes * Detection/Reaction for Packet Reordering with TCP draft-zimmermann-tcpm-reordering-detection draft-zimmermann-tcpm-reordering-reaction Speaker: Alexander Zimmermann Time: 10 minutes * TCP RACK: reordering resilient fast recovery Speaker: Yuchung Cheng Time: 15 minutes From nobody Mon Oct 27 10:53:33 2014 Return-Path: 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 49E481A8783 for ; Mon, 27 Oct 2014 10:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c0PM2QMnITNO for ; Mon, 27 Oct 2014 10:53:01 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7200C1A87D1 for ; Mon, 27 Oct 2014 10:52:20 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 27 Oct 2014 22:09:11 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 27 Oct 2014 17:52:15 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 27 Oct 2014 17:52:15 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.243]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9RHqDDv016465; Mon, 27 Oct 2014 17:52:14 GMT Message-ID: <201410271752.s9RHqDDv016465@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2014 17:52:12 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <54455CA6.2020105@isi.edu> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> <543DA031.6090705@isi.edu> <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> <54455CA6.2020105@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZY4PFTEr4StT_NNitTopujJfkZk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:53:05 -0000 Joe, At 19:04 20/10/2014, Joe Touch wrote: >On 10/19/2014 6:15 PM, Bob Briscoe wrote: > > Joe, >... > >> > * The syn-op-sis client ensures that it aborts the connection to a > >> > legacy server before it passes this corrupt TCP Data to the app. > >> > >> You have to prohibit use of TFO (and maybe some others, e.g., TCPCT) > >> with syn-op-sys in that case. > > > > Nope (we've been through that argument, and I recall you suddenly 'got > > it' at one point). > >You mentioned putting TFO in the extension space for the extended SYN. >You still have the problem of the legacy SYN - if that uses TFO, you'd >be trying to stop a connection after user data were passed to the app. > >I.e., you have to prohibit TFO on the legacy SYN. Nope. Because the payload in the legacy SYN isn't polluted with control options. So it can be passed to the app. It doesn't matter that an upgraded server will then pass the payloads of both the legacy and the upgraded SYN to the app. Because TFO is required to be turned on only if the app can cope with duplicate SYNs. Bob (Sorry for delayed response - been travelling) >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Mon Oct 27 11:03:43 2014 Return-Path: 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 0656C1A8784 for ; Mon, 27 Oct 2014 11:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 XfafoRmK0j_R for ; Mon, 27 Oct 2014 11:00:28 -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 71A6A1A877C for ; Mon, 27 Oct 2014 11:00:28 -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 s9RHxxAn010291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 11:00:00 -0700 (PDT) Message-ID: <544E8822.4000001@isi.edu> Date: Mon, 27 Oct 2014 11:00:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> <543DA031.6090705@isi.edu> <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> <54455CA6.2020105@isi.edu> <201410271752.s9RHqDDv016465@bagheera.jungle.bt.co.uk> In-Reply-To: <201410271752.s9RHqDDv016465@bagheera.jungle.bt.co.uk> 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/4fB8tIVyVWzxYjwXwHZa4DLg8Nc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:00:30 -0000 On 10/27/2014 10:52 AM, Bob Briscoe wrote: > Joe, > > At 19:04 20/10/2014, Joe Touch wrote: > > >> On 10/19/2014 6:15 PM, Bob Briscoe wrote: >> > Joe, >> ... >> >> > * The syn-op-sis client ensures that it aborts the connection to a >> >> > legacy server before it passes this corrupt TCP Data to the app. >> >> >> >> You have to prohibit use of TFO (and maybe some others, e.g., TCPCT) >> >> with syn-op-sys in that case. >> > >> > Nope (we've been through that argument, and I recall you suddenly 'got >> > it' at one point). >> >> You mentioned putting TFO in the extension space for the extended SYN. >> You still have the problem of the legacy SYN - if that uses TFO, you'd >> be trying to stop a connection after user data were passed to the app. >> >> I.e., you have to prohibit TFO on the legacy SYN. > > Nope. Because the payload in the legacy SYN isn't polluted with control > options. So it can be passed to the app. > > It doesn't matter that an upgraded server will then pass the payloads of > both the legacy and the upgraded SYN to the app. Because TFO is required > to be turned on only if the app can cope with duplicate SYNs. Apps shouldn't have to deal with these issues, IMO. Joe From nobody Mon Oct 27 11:05:58 2014 Return-Path: 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 6F6D71A8915 for ; Mon, 27 Oct 2014 11:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tiSgOpqnqv81 for ; Mon, 27 Oct 2014 11:05:25 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A671A892E for ; Mon, 27 Oct 2014 11:05:22 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 27 Oct 2014 18:06:27 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 27 Oct 2014 18:05:18 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Mon, 27 Oct 2014 18:05:18 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.243]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9RI5EIs016509; Mon, 27 Oct 2014 18:05:15 GMT Message-ID: <201410271805.s9RI5EIs016509@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2014 18:05:06 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <54455A68.9040708@isi.edu> References: <201410200058.s9K0wQnS014207@bagheera.jungle.bt.co.uk> <54455A68.9040708@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/D96_8Xvdn9CG_baJWhN60J-AafA Cc: tcpm IETF list Subject: Re: [tcpm] More option space on any segment: draft-briscoe-tcpm-inner-space-00 (was syn-op-sis-02) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:05:28 -0000 Joe, At 18:54 20/10/2014, Joe Touch wrote: >On 10/19/2014 5:58 PM, Bob Briscoe wrote: > > Chairs and list, > > > > My individual draft has a new file-name (and title): inner-space-00 > > > > This is a major rev of syn-op-sis-02 > > , but I > > won't be using that name any more. > > Sorry to confuse everyone by changing the name. But the old name was no > > longer relevant. > > > > I believe the new Inner Space protocol could be a significant advance > > for TCP. > >IMO, you're on the path to implementing TCP inside TCP. > >That is, right up until a middlebox starts parsing and modifying the >inner TCP, at which point you'll need TCP-in-TCP-in-TCP, ad infinitum. Nope. Here's a bulleted summary of the section in=20 inner-space that explains why this could be a=20 permanent stop on middleboxes, not just a step in=20 an arms race. Of course, I can't predict for=20 certain what the operators will buy, but this is a plausible argument: non-goal * evasion of security middleboxes =96they will evolve to check Inner Options goal * Inner Space deployed for something useful (e.g. tcpcrypt) =96traverses most middleboxes, so reaches critical mass =96can deploy integrity protection over TCP Data =96(cannot protect Outer Options for consumer=20 Internet today =96 would fail too often) * raises stakes =96then tampering with Inner Options will break comms, not just the theoretical potential benefit of a new option * puts security middlebox designers on the back foot =96blocking comms just 'cos options are non-typical will not sell =96distinguishing attacks from the latest advances will sell result * mess with options and you shoot yourself in the foot For full text, see >IMO this whole exercise is a significant step backwards, except as a >good example of why we need constraints for middleboxes. It /is/ about constraining future middleboxes.=20 But you have to provide something useful as well,=20 to get it deployed. And that means getting thru today's middleboxes first. It's fairly pointless trying to constrain=20 deployment of middleboxes that are already deployed. That horse has bolted. Bob >Joe ________________________________________________________________ Bob Briscoe, BT=20 From nobody Mon Oct 27 11:19:39 2014 Return-Path: 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 8E7BF1A8A4D for ; Mon, 27 Oct 2014 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qHBnx1pt0K3k for ; Mon, 27 Oct 2014 11:19:12 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AFAC1A8985 for ; Mon, 27 Oct 2014 11:19:02 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 27 Oct 2014 22:35:54 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 27 Oct 2014 18:19:00 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Mon, 27 Oct 2014 18:19:00 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.243]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9RIIxVL016544; Mon, 27 Oct 2014 18:18:59 GMT Message-ID: <201410271818.s9RIIxVL016544@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2014 18:18:58 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <544E8822.4000001@isi.edu> References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> <543DA031.6090705@isi.edu> <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> <54455CA6.2020105@isi.edu> <201410271752.s9RHqDDv016465@bagheera.jungle.bt.co.uk> <544E8822.4000001@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UkSidkhQGWOaxoUaxCUB14ofQDc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:19:21 -0000 Joe, At 18:00 27/10/2014, Joe Touch wrote: >On 10/27/2014 10:52 AM, Bob Briscoe wrote: > > Joe, > > > > At 19:04 20/10/2014, Joe Touch wrote: > > > > > >> On 10/19/2014 6:15 PM, Bob Briscoe wrote: > >> > Joe, > >> ... > >> You mentioned putting TFO in the extension space for the extended SYN. > >> You still have the problem of the legacy SYN - if that uses TFO, you'd > >> be trying to stop a connection after user data were passed to the app. > >> > >> I.e., you have to prohibit TFO on the legacy SYN. > > > > Nope. Because the payload in the legacy SYN isn't polluted with control > > options. So it can be passed to the app. > > > > It doesn't matter that an upgraded server will then pass the payloads of > > both the legacy and the upgraded SYN to the app. Because TFO is required > > to be turned on only if the app can cope with duplicate SYNs. > >Apps shouldn't have to deal with these issues, IMO. Inner Space is not changing anything in that respect. Your issue is with TFO. FWIW, I think TFO is worth this tradeoff. I was very concerned about the safety of TFO in this respect and spent some time with Yuchung developing wording to make the RFC clearer. Problem is that most Web admins won't read the RFCs. They will read a potted summary written by some half-clueless Web performance blogger. The best we can do is ensure the explanation is in the first few lines of the abstract. But at least harm and blame should land on the same doorstep (the server operator) in this case. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Mon Oct 27 11:35:33 2014 Return-Path: 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 CF4391ACF17 for ; Mon, 27 Oct 2014 11:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 BiHdyUxBsaMM for ; Mon, 27 Oct 2014 11:35:13 -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 AFA681ACD8B for ; Mon, 27 Oct 2014 11:33:41 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9RIXESc019905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 11:33:14 -0700 (PDT) Message-ID: <544E8FEA.80807@isi.edu> Date: Mon, 27 Oct 2014 11:33:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bob Briscoe References: <543BFC10.7050209@tik.ee.ethz.ch> <543C08DA.206@isi.edu> <201410141825.s9EIP3rT017080@bagheera.jungle.bt.co.uk> <543D6E72.6050509@isi.edu> <201410142136.s9ELaIO6017868@bagheera.jungle.bt.co.uk> <543DA031.6090705@isi.edu> <201410200115.s9K1FIMH014340@bagheera.jungle.bt.co.uk> <54455CA6.2020105@isi.edu> <201410271752.s9RHqDDv016465@bagheera.jungle.bt.co.uk> <544E8822.4000001@isi.edu> <201410271818.s9RIIxVL016544@bagheera.jungle.bt.co.uk> In-Reply-To: <201410271818.s9RIIxVL016544@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/P1q1FPzIYgDu7k2kkh1KOKgGgx8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Further comments on extending option space X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:35:16 -0000 On 10/27/2014 11:18 AM, Bob Briscoe wrote: > Joe, ... >> > It doesn't matter that an upgraded server will then pass the >> payloads of >> > both the legacy and the upgraded SYN to the app. Because TFO is >> required >> > to be turned on only if the app can cope with duplicate SYNs. >> >> Apps shouldn't have to deal with these issues, IMO. > > Inner Space is not changing anything in that respect. Your issue is with > TFO. I don't have that issue with TFO with my SYN extension, though. AFAICT, it's an interaction between TFO and a dual-stack approach. Joe From nobody Mon Oct 27 11:40:31 2014 Return-Path: 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 2C8541ACF04 for ; Mon, 27 Oct 2014 11:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 t14-GDAMblz6 for ; Mon, 27 Oct 2014 11:40:02 -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 27CE31ACF92 for ; Mon, 27 Oct 2014 11:37:10 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s9RIaYvT020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 11:36:35 -0700 (PDT) Message-ID: <544E90B2.4080501@isi.edu> Date: Mon, 27 Oct 2014 11:36:34 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bob Briscoe References: <201410200058.s9K0wQnS014207@bagheera.jungle.bt.co.uk> <54455A68.9040708@isi.edu> <201410271805.s9RI5EIs016509@bagheera.jungle.bt.co.uk> In-Reply-To: <201410271805.s9RI5EIs016509@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252 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/4AE8zyKtu6RaPoLtpds9GPxUILI Cc: tcpm IETF list Subject: Re: [tcpm] More option space on any segment: draft-briscoe-tcpm-inner-space-00 (was syn-op-sis-02) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:40:06 -0000 On 10/27/2014 11:05 AM, Bob Briscoe wrote: > Joe, > > At 18:54 20/10/2014, Joe Touch wrote: > > >> On 10/19/2014 5:58 PM, Bob Briscoe wrote: >> > Chairs and list, >> > >> > My individual draft has a new file-name (and title): inner-space-00 >> > >> > This is a major rev of syn-op-sis-02 >> > , but I >> > won't be using that name any more. >> > Sorry to confuse everyone by changing the name. But the old name was no >> > longer relevant. >> > >> > I believe the new Inner Space protocol could be a significant advance >> > for TCP. >> >> IMO, you're on the path to implementing TCP inside TCP. >> >> That is, right up until a middlebox starts parsing and modifying the >> inner TCP, at which point you'll need TCP-in-TCP-in-TCP, ad infinitum. > > Nope. Here's a bulleted summary of the section in inner-space that > explains why this could be a permanent stop on middleboxes, not just a > step in an arms race. Of course, I can't predict for certain what the > operators will buy, but this is a plausible argument: ... > result > * mess with options and you shoot yourself in the foot And, as now, we'll all start to worry about that and try to create a mechanism that avoids letting middleboxes shoot themselves in the foot. And the result will be TCP-in-TCP-in-TCP, as I noted originally. We're both just guessing, but I see no reason to believe that "laws for the lawless" ever ends up getting the lawless to obey the new laws. Joe From nobody Mon Oct 27 16:01:41 2014 Return-Path: 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 D87911A6F3A for ; Mon, 27 Oct 2014 16:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tyKP12EWLeCE for ; Mon, 27 Oct 2014 16:01:20 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457601A6F11 for ; Mon, 27 Oct 2014 16:00:30 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 28 Oct 2014 03:18:18 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 27 Oct 2014 23:00:24 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Mon, 27 Oct 2014 23:00:22 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.38.168]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9RN0Kx0017152 for ; Mon, 27 Oct 2014 23:00:20 GMT Message-ID: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2014 23:00:20 +0000 To: tcpm IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JrzY5UOOPECWi0fUGLezCsnkTY0 Subject: [tcpm] Inner Option Space revised: inner-space-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:01:25 -0000 TCPM folks, I've posted a revision to: "Inner Space for TCP Options" Thanks to the following for useful discussions (mostly off-list), whom I've added the Acknowledgements section: Costin Raiciu, Marcelo Bagnulo Braun, Julian Chesterfield and Jaime Garcia, and of course the continuing discussions with Joe Touch. Technical changes: * Corrected DO to 4 * DO (twice) * Confirmed that receive window applies to Inner Options * Generalised the cause of decryption/decompression from a previous TCP option to any previous control message * Added requirement for a middlebox not to defer data on SYN * Latency of dual handshake is worst of two * Completed "Interaction with Pre-Existing TCP Implementations" section, covering other TCP variants, TCP in middleboxes and the TCP API. Shifted some TCP options to Outer only, because of RWND deadlock problem * Added two outstanding issues: i) ossifies reliable ordered delivery; ii) Ideally Outer in Inner. Editorial changes: * Removed section on Echo TCP option to a separate I-D that is mandatory to implement for inner-space, and shifted some SYN flood discussion in Security Considerations * Clarifications throughout * Acknowledged more review comments Cheers Bob >From: >To: Bob Briscoe , "Bob J. Briscoe" >Subject: New Version Notification for draft-briscoe-tcpm-inner-space-01.txt >Date: Mon, 27 Oct 2014 12:07:17 -0700 > > >A new version of I-D, draft-briscoe-tcpm-inner-space-01.txt >has been successfully submitted by Bob Briscoe and posted to the >IETF repository. > >Name: draft-briscoe-tcpm-inner-space >Revision: 01 >Title: Inner Space for TCP Options >Document date: 2014-10-27 >Group: Individual Submission >Pages: 49 >URL: >http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-inner-space-01.txt >Status: >https://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/ >Htmlized: http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-briscoe-tcpm-inner-space-01 > >Abstract: > This document describes an experimental method to extend the limited > space for control options in every segment of a TCP connection. It > can use a dual handshake so that, from the very first SYN segment, > extra option space can immediately start to be used optimistically. > At the same time a dual handshake prevents a legacy server from > getting confused and sending the control options to the application > as user-data. The dual handshake is only one strategy - a single > handshake will usually suffice once deployment has got started. The > protocol is designed to traverse most known middleboxes including > connection splitters, because it sits wholly within the TCP Data. It > also provides reliable ordered delivery for control options. > Therefore, it should allow new TCP options to be introduced i) with > minimal middlebox traversal problems; ii) with incremental deployment > from legacy servers; iii) without an extra round of handshaking delay > iv) without having to provide its own loss recovery and ordering > mechanism and v) without arbitrary limits on available space. > > > > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT From nobody Mon Oct 27 16:11:39 2014 Return-Path: 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 A7C171A6F86; Mon, 27 Oct 2014 16:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gPKWig1LuJpT; Mon, 27 Oct 2014 16:11:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9A01A6F2E; Mon, 27 Oct 2014 16:11:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 16:11:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uyc7MzjYYnqKSascAbQfBFDHybw Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:11:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP and SCTP RTO Restart Authors : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-04.txt Pages : 13 Date : 2014-10-27 Abstract: This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 16:19:00 2014 Return-Path: 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 B846D1A6FC7 for ; Mon, 27 Oct 2014 16:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 ReBAuYfOYfxA for ; Mon, 27 Oct 2014 16:18:51 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2181A6FC8 for ; Mon, 27 Oct 2014 16:18:28 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 28 Oct 2014 00:17:57 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 148.122.14.30 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Message-ID: <544ED2B8.4020208@kau.se> Date: Tue, 28 Oct 2014 00:18:16 +0100 From: Per Hurtig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> In-Reply-To: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6EymlmJEjlZABFUbZt-wpetVcIk Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:18:58 -0000 Hi all, we have now updated the draft to address the outstanding comments. The main changes from last version are: o Changed the algorithm to allow RTOR when there is unsent data available, but the cwnd does not allow transmission. o Changed the algorithm to not trigger if "RTO - T_earliest" <= 0, to avoid that ACKs to previous retransmissions trigger premature timeouts. o Made minor adjustments throughout the document to adjust for the algorithmic changes. o Improved the wording throughout the document. for experimental results and a Linux implementation, please visit: http://riteproject.eu/resources/rto-restart/ Cheers, Per On 2014-10-28 00:11, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP and SCTP RTO Restart > Authors : Per Hurtig > Anna Brunstrom > Andreas Petlund > Michael Welzl > Filename : draft-ietf-tcpm-rtorestart-04.txt > Pages : 13 > Date : 2014-10-27 > > Abstract: > This document describes a modified algorithm for managing the TCP and > SCTP retransmission timers that provides faster loss recovery when > there is a small amount of outstanding data for a connection. The > modification, RTO Restart (RTOR), allows the transport to restart its > retransmission timer more aggressively in situations where fast > retransmit cannot be used. This enables faster loss detection and > recovery for connections that are short-lived or application-limited. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Oct 27 16:54:59 2014 Return-Path: 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 7CA4B1A8788 for ; Mon, 27 Oct 2014 16:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZzplTEtZOIj9 for ; Mon, 27 Oct 2014 16:54:45 -0700 (PDT) Received: from atl4mhob01.myregisteredsite.com (atl4mhob01.myregisteredsite.com [209.17.115.39]) by ietfa.amsl.com (Postfix) with ESMTP id 652031A86F7 for ; Mon, 27 Oct 2014 16:54:43 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s9RNsftw024031 for ; Mon, 27 Oct 2014 19:54:41 -0400 Received: (qmail 25965 invoked by uid 0); 27 Oct 2014 23:54:41 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 27 Oct 2014 23:54:41 -0000 Message-ID: <544EDB38.3050600@mti-systems.com> Date: Mon, 27 Oct 2014 19:54:32 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe , tcpm IETF list References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> In-Reply-To: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/9J1YmjeD5EVyuvrQ6kc6Kj_-1d0 Subject: Re: [tcpm] Inner Option Space revised: inner-space-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:54:51 -0000 On 10/27/2014 7:00 PM, Bob Briscoe wrote: > TCPM folks, > > I've posted a revision to: > "Inner Space for TCP Options" > > Hi Bob, this is well written, and I think it has some good pieces. The EchoCookie, for instance, seems useful with or without regard to all these other documents about extending option space. That said, I really don't like so-called "dual handshake" or multiple parallel SYN designs, personally. The downsides are well trodden, and you mention some in the draft. The driving force behind this approach, as I understand, is to keep latency minimal. IMHO, the draft-borman-tcp4way approach: http://tools.ietf.org/html/draft-borman-tcp4way-00 is a bit cleaner in avoiding the parallel SYNs and the associated issues. The main downside of 4way is potentially a slight latency. Importantly, just as you say that after upgrades have been made, the multiple SYNs of inner-space can go away, and only upgraded SYNs be sent, the same is true of the 4way approach; it could just revert to a normal 3way handshake after transition. Also, I believe it would be possible to implement a cache of hosts that have successfully negotiated using 4way in the recent past, so that new client connections can optimistically directly send an upgraded SYN, rather than initiating a full 4way connection. This would be a heuristic, of course, for cases where latency is a major concern. So, I guess this is very long-winded, but my real question is for others in the working group and whether or not there's consensus about multiple parallel SYN approaches being an acceptable design pattern or not. My personal opinion is that they aren't desirable. -- Wes Eddy MTI Systems From nobody Mon Oct 27 17:02:26 2014 Return-Path: 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 DCD211A86FE for ; Mon, 27 Oct 2014 17:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Vv4j0-U-gS7D for ; Mon, 27 Oct 2014 17:02:21 -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 CAE591A1B85 for ; Mon, 27 Oct 2014 17:02:21 -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 s9S01ovo009446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 17:01:50 -0700 (PDT) Message-ID: <544EDCF1.4000200@isi.edu> Date: Mon, 27 Oct 2014 17:01:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Wesley Eddy , Bob Briscoe , tcpm IETF list References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> In-Reply-To: <544EDB38.3050600@mti-systems.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/FpCIEQS4NE4OWGhjXk57-Z-3vYc Subject: Re: [tcpm] Inner Option Space revised: inner-space-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:02:24 -0000 On 10/27/2014 4:54 PM, Wesley Eddy wrote: > So, I guess this is very long-winded, but my real question is for > others in the working group and whether or not there's consensus > about multiple parallel SYN approaches being an acceptable design > pattern or not. > > My personal opinion is that they aren't desirable. I have similar issues with 4WHS, FWIW. I.e., it's clear we need to put the additional SYN space outside the original SYN. We have three options: - supplement segment sent in parallel SYN-OOB, as per my draft - dual-stack IMO, that's what inner-space ends up being - an additional exchange IMO, that's what 4WHS ends up being, albeit reversed and overlapped I'm not completely sure we need to pick yet, however; it's very clear we need more experience with these approaches to see what works and determine interactions. Joe From nobody Mon Oct 27 17:42:27 2014 Return-Path: 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 8D8C41A1B39 for ; Mon, 27 Oct 2014 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 MBjzfwAm0cEf for ; Mon, 27 Oct 2014 17:42:22 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 54B351A03D0 for ; Mon, 27 Oct 2014 17:42:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D1824C94A9; Mon, 27 Oct 2014 20:42:18 -0400 (EDT) Date: Mon, 27 Oct 2014 20:42:18 -0400 From: John Leslie To: Wesley Eddy Message-ID: <20141028004218.GI525@verdi> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544EDB38.3050600@mti-systems.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ld4I7YYNR3JMsS2V7wbxnRIOBA4 Cc: tcpm IETF list Subject: [tcpm] Parallel SYNs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:42:25 -0000 Wesley Eddy wrote: >... > > That said, I really don't like so-called "dual handshake" or > multiple parallel SYN designs, personally. Alas, we have long since painted ourselves in a corner where parallel SYNs is arguably the "cleanest" way out. :^( > The downsides are well trodden, and you mention some in the draft. > The driving force behind this approach, as I understand, is to > keep latency minimal. That, alas, is pretty essential. > IMHO, the draft-borman-tcp4way approach: > http://tools.ietf.org/html/draft-borman-tcp4way-00 > is a bit cleaner in avoiding the parallel SYNs and the associated > issues. It's a toss-up... I feel more nervous about that path right now. > The main downside of 4way is potentially a slight latency. I have some other worries, but any added latency is nearly fatal. > Importantly, just as you say that after upgrades have been made, > the multiple SYNs of inner-space can go away, and only upgraded SYNs > be sent, the same is true of the 4way approach; it could just revert > to a normal 3way handshake after transition. Both those future optimizations deserve to be discussed; but won't drive the decision which approach(es) to use. > Also, I believe it would be possible to implement a cache of hosts > that have successfully negotiated using 4way in the recent past, > so that new client connections can optimistically directly send > an upgraded SYN, rather than initiating a full 4way connection. > This would be a heuristic, of course, for cases where latency is > a major concern. That, alas, is dangerous ground, with load-balancers out there which do nothing to verify compatibility of the hosts behind them. > So, I guess this is very long-winded, but my real question is for > others in the working group and whether or not there's consensus > about multiple parallel SYN approaches being an acceptable design > pattern or not. I don't think we're ready for a consensus call on that. But my own opinion is that parallel-SYN is entirely "acceptable". Nobody is forced to use it. (There's really no good reason to use it on _every_ TCP connection.) > My personal opinion is that they aren't desirable. My own preference would be to route-around-it, working up a clean solution for expanded option space on the SYN-ACK; and working in parallel to reduce the need for nearly-all options to be listed in the initial SYN. (Even reducing the size of the instance of an option in the initial SYN could help substantially.) (I've been biting my tongue during the recent discussion about whether options need to be "negotiated" starting with the initial SYN...) -- John Leslie From nobody Mon Oct 27 21:42:27 2014 Return-Path: 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 7C35D1A0470 for ; Mon, 27 Oct 2014 21:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 N1gxS7RKWjsA for ; Mon, 27 Oct 2014 21:42:19 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id C3C001A0469 for ; Mon, 27 Oct 2014 21:42:18 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s9S4gGGX007271 for ; Tue, 28 Oct 2014 00:42:16 -0400 Received: (qmail 22860 invoked by uid 0); 28 Oct 2014 04:42:16 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 28 Oct 2014 04:42:16 -0000 Message-ID: <544F1E9F.3060108@mti-systems.com> Date: Tue, 28 Oct 2014 00:42:07 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Touch , Bob Briscoe , tcpm IETF list References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> In-Reply-To: <544EDCF1.4000200@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/k9Ooqy2a7xMgz_scf4wAxSwM5n0 Subject: Re: [tcpm] Inner Option Space revised: inner-space-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 04:42:20 -0000 On 10/27/2014 8:01 PM, Joe Touch wrote: > > I.e., it's clear we need to put the additional SYN space outside the > original SYN. We have three options: > > - supplement segment sent in parallel > SYN-OOB, as per my draft > > - dual-stack > IMO, that's what inner-space ends up being > > - an additional exchange > IMO, that's what 4WHS ends up being, albeit > reversed and overlapped I neglected to mention the OOB approach, though now I remember that you did sketch this taxonomy already in section 4 of the syn-ext-opt draft. For what it's worth, I also think the OOB approach is more desirable than the "dual-stack" type, however, am more uncertain about firewall behavior towards the segments with both SYN & ACK bits clear. That's definitely a good experiment to get widespread data on. I also don't really understand specifically how one decides how long to wait for the OOB segment before assuming it isn't coming, but that could be tweakable or algorithmically determined, so I don't think it's a major issue. > I'm not completely sure we need to pick yet, however; it's very clear we > need more experience with these approaches to see what works and > determine interactions. Agreed! My curiosity is whether we only need a smaller number of experiments because maybe we prefer approach X and just need to know if it really tends to pass through a high enough percentage of the time. -- Wes Eddy MTI Systems From nobody Mon Oct 27 23:12:52 2014 Return-Path: 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 256C81A1A68 for ; Mon, 27 Oct 2014 23:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3fsU2mjYHNpf for ; Mon, 27 Oct 2014 23:12:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C531A1A63 for ; Mon, 27 Oct 2014 23:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1414476767; x=1415686367; h=from:to:cc:subject:date:message-id:mime-version; bh=AZ0gRcG5V5k7uFFZnnzQS/b8SqUwTMcav3Yd763Z67s=; b=dQdyPsxorUrHwtzbtFJhYd6x541DTHkjY2HuEBGqfEJ4Y1Y7ApR8SNoB 5cMi6+wSXIDsOd5Zy4FQztp6RgeAfH7dQNKhoUeexerflywGI92n0+3Ju su3P2wn0U4nvlkro3cAdzgTIPpl4ZsREZlEujdmq4gJfDv/0ZR92yD+IU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FAHszT1StJA2B/2dsb2JhbABcgkhGVFzOFodNgR0WAXILhAl5EgEMAXMnBA6IRg3LBgEBAQEBAQEBAgEBAQEBAQEBARUEkQQEhFIFkgeESIcSgTGNXoMfhACDeII0gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,801,1406592000"; d="scan'208,217";a="367017167" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 28 Oct 2014 06:12:39 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9S6CcNJ014444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Oct 2014 06:12:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 01:12:38 -0500 From: "Sujeet Nayak A (sua)" To: "tcpm@ietf.org" Thread-Topic: Updated SHA-2 AO draft Thread-Index: AQHP8nYrPM6bJff4oUqZ0Bc1WuqHwQ== Date: Tue, 28 Oct 2014 06:12:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.142.110.37] Content-Type: multipart/alternative; boundary="_000_D07531AA74A10suaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HKidVdVMlOu_-SHEJNzaUMwLfY0 Subject: [tcpm] Updated SHA-2 AO draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 06:12:50 -0000 --_000_D07531AA74A10suaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks everyone for your valuable review comments so far. Brian and myself = have updated the draft to produce the next version. https://tools.ietf.org/html/draft-nayak-tcp-sha2-01 Some of the high level changes made are: * Because of TCP option space issue, SHA512 has been moved out of the d= raft (a note added in the "Security Consideration" for future support, when= needed). * Moved the motivation contents into the introduction section. * Taken care of some of the RFC language related comments. Pl. review and let me know your feedback. On the other hand, if there is a = consensus that, the contents need to update RFC5926, and if that RFC allows= such an update, then we are happy to work with Greg on it. Regards, Sujeet --_000_D07531AA74A10suaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <29B9D32A553EED42A79EF16E2077EFF3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,
Thanks everyone for your valuable review comments so far. Brian and my= self have updated the draft to produce the next version. 

Some of the high level changes made are:
  • Because of TCP option space issue, SHA512 has been moved out of the dra= ft (a note added in the "Security Consideration" for future suppo= rt, when needed).
  • Moved the motivation contents into the introducti= on section.
  • Taken care of some of the RFC language related comments= .
Pl. review and let me know your feedback. On the other hand, if there = is a consensus that, the contents need to update RFC5926, and if that RFC a= llows such an update, then we are happy to work with Greg on it.

Regards,

Sujeet
--_000_D07531AA74A10suaciscocom_-- From nobody Tue Oct 28 04:00:36 2014 Return-Path: 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 EC0041A1B8E for ; Tue, 28 Oct 2014 03:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 sdjVQckl7Akg for ; Tue, 28 Oct 2014 03:59:50 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0044A1A1AFC for ; Tue, 28 Oct 2014 03:59:49 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 28 Oct 2014 10:59:47 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 28 Oct 2014 10:59:46 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 28 Oct 2014 10:59:44 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.120.116]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9SAxftl019079; Tue, 28 Oct 2014 10:59:41 GMT Message-ID: <201410281059.s9SAxftl019079@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Oct 2014 10:59:41 +0000 To: Wesley Eddy From: Bob Briscoe In-Reply-To: <544F1E9F.3060108@mti-systems.com> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BPlkiSRw4O39199f7tq8z21kFHw Cc: tcpm IETF list , Joe Touch Subject: Re: [tcpm] Inner Option Space revised: inner-space-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 10:59:53 -0000 Wes, Before doing experiments, we need to understand / agree what problem we're trying to solve and what success would look like. The roll-out of an enabling technology like extended option space has to be tied to the roll-out of something really useful that it enables. No-one will go through deployment pain with only a weak promise of possible future gain. Opportunistic encryption is one possible flag-pole to tie the extra option space flag to. The problem that the tcpinc w-g faces is that if something new in the TCP header is 'normalised' on 15% of paths by middleboxes, then it's really easy for to target connections it wants to snoop by just normalising headers. Ie. when middleboxes are indistinguishable from downgrade attacks, it's easy to hide a real downgrade attack. So the ideal is 100% legacy middlebox traversal{Note1}. 99.9% might be enough, but 98% would be too low. Then we get the full force of demand for increased security behind extra option space deployment. If that succeeds, we get widespread integrity-checking of the TCP options, and we've beaten the middleboxes for ever (see previous email). And ideally 0% average extra latency. 1% might be OK, but 10% would not. And finally, the protocol architecture needs to remain clean and evolvable. For instance Inner Space places TCP Options within the TCP Data because I've learned that's the proper way to make a protocol architecture evolvable. I.e. TCP should always have been like that. It's not just a hack. Regards Bob {Note1} To be clear 'legacy' does not include any middleboxes specifically coded to seek out and destroy the new approach. As long as that's very rare, users won't click on "Connection not secured; Continue anyway?" without being reeeeeeally careful. At 04:42 28/10/2014, Wesley Eddy wrote: >On 10/27/2014 8:01 PM, Joe Touch wrote: > > > > I.e., it's clear we need to put the additional SYN space outside the > > original SYN. We have three options: > > > > - supplement segment sent in parallel > > SYN-OOB, as per my draft > > > > - dual-stack > > IMO, that's what inner-space ends up being > > > > - an additional exchange > > IMO, that's what 4WHS ends up being, albeit > > reversed and overlapped > > >I neglected to mention the OOB approach, though now I remember that >you did sketch this taxonomy already in section 4 of the syn-ext-opt >draft. > >For what it's worth, I also think the OOB approach is more desirable >than the "dual-stack" type, however, am more uncertain about firewall >behavior towards the segments with both SYN & ACK bits clear. That's >definitely a good experiment to get widespread data on. I also don't >really understand specifically how one decides how long to wait for >the OOB segment before assuming it isn't coming, but that could be >tweakable or algorithmically determined, so I don't think it's a major >issue. > > > > I'm not completely sure we need to pick yet, however; it's very clear we > > need more experience with these approaches to see what works and > > determine interactions. > > >Agreed! My curiosity is whether we only need a smaller number of >experiments because maybe we prefer approach X and just need to know >if it really tends to pass through a high enough percentage of the time. > > >-- >Wes Eddy >MTI Systems ________________________________________________________________ Bob Briscoe, BT From nobody Tue Oct 28 06:01:13 2014 Return-Path: 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 6FF2F1A6F3B for ; Tue, 28 Oct 2014 06:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 rad0NJFx-psE for ; Tue, 28 Oct 2014 06:00:23 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44301A6EF0 for ; Tue, 28 Oct 2014 05:59:07 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id b13so486186qcw.9 for ; Tue, 28 Oct 2014 05:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=u2Nmi6MUVf4phZJYEAHt7rKXDU0aqxT1VSN0JKKTCV8=; b=JmxfErKP5Qj0hApVQ74g45MjHkuGoegIVKaa+wcJQmuoPUd14jQ04mE/CnM/iYusfQ rBx226JBFZ6YkAkD1ShGR98dMNE8UiGqBLUStIQ+6FqOj6Gop2szlUpqpQklIOrXsdwb crO23zZDvb6in3mYPJEgxuKsBmqvfpXItT6Ih8b/KDolxc8xKycT9uNYtbrKK/UxNF8O FZb3ReFA7Yn0etMCzlrcBzHIYYtSeqLxL0L46+8WY+59Zfw+Iv7rvkNcWpaoa1ET6Rb9 7VfN1GsRUQxIId0spB+CuiQ0n/INLnNHh77KCx5U8IKKnZf+whbGJhh1v++IPbKYCzoM PiUA== MIME-Version: 1.0 X-Received: by 10.229.106.68 with SMTP id w4mr4797258qco.18.1414501145062; Tue, 28 Oct 2014 05:59:05 -0700 (PDT) Received: by 10.140.240.198 with HTTP; Tue, 28 Oct 2014 05:59:05 -0700 (PDT) Date: Tue, 28 Oct 2014 13:59:05 +0100 Message-ID: From: renaud sallantin To: "tcpm@ietf.org" , cedric baudoin , Dubois Emmanuel Content-Type: multipart/alternative; boundary=001a1134c6de49322c05067b36be Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/tX3e9kEicjz6tIk_Ya3VCMWX0x8 Subject: [tcpm] New Version notification for draft-sallantin-tcpm-initial-spreading-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 13:00:31 -0000 --001a1134c6de49322c05067b36be Content-Type: text/plain; charset=UTF-8 Dear all, The following document replaces the draft we proposed in the frame of ICCRG (draft-sallantin-iccrg-initial-spreading-01 : http://www.ietf.org/proceedings/89/slides/slides-89-iccrg-1.pdf) Following points have been updated to take your comments into considerations: - A more accurate function of spacing to improve Initial Spreading performance in any cases. - An implementation that does not rely on Jiffy URL: http://www.ietf.org/internet-drafts/draft-sallantin-tcpm-initial-spreading-00.txt Status: https://datatracker.ietf.org/doc/draft-sallantin-tcpm-initial-spreading/ Htmlized: http://tools.ietf.org/html/draft-sallantin-tcpm-initial-spreading-00 Simulations (via NS2), experiments on Linux kernel and even an analytic model have been realized to refine our mechanism, and two papers have been presented in the last LCN conferences. A new patch will soon be available and post on this list. Sallantin, R.; Baudoin, C.; Chaput, E.; Arnal, F.; Dubois, E.; Beylot, A.-L., "Initial spreading: A fast Start-Up TCP mechanism," Local Computer Networks (LCN), 2013 IEEE 38th Conference on , vol., no., pp.492,499, 21-24 Oct. 2013 Sallantin, R; Baudoin, C; Chaput,E; Arnal, F; Dubois,E; Beylot, A, "A TCP model for short-lived flows to validate initial spreading," Local Computer Networks (LCN), 2014 IEEE 39th Conference on , vol., no., pp.177,184, 8-11 Sept. 2014 To conclude, we share the same concern about optimizing the IW transmission as discussed in "draft-you-tcpm-configuring-tcp-initial-window" and related mail exchanges. We are also convinced that using the information that can be learned about the connection characteristics is critical to ensure the best start. However, ,instead of considerations on the flow size, we use the initial RTT measurement to improve the IW transmission. We would like to receive your feedback, Best regards, Renaud Sallantin --001a1134c6de49322c05067b36be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=09 =09 =09

Dear all,

The following document replaces the draft we proposed in the frame of ICCRG (draft-sallantin-i= ccrg-initial-spreading-01=C2=A0:=C2=A0http://www.ietf.org/proceed= ings/89/slides/slides-89-iccrg-1.pdf)

Following points have been updated to take your comments into considerations:<= /p>

  • A more accurate function of spacing to improve Initial Spreading performance in any cases.

  • An implementation that does not rely on Jiffy

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0http://www.ietf.org/internet-drafts/draft-sallantin-tcpm-initial-sprea= ding-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://da= tatracker.ietf.org/doc/draft-sallantin-tcpm-initial-spreading/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.i= etf.org/html/draft-sallantin-tcpm-initial-spreading-00

Simulations= (via NS2), experiments on Linux kernel and even an analytic model have been realized to refine our mechanism, and two papers have been presented in the last LCN conferences. A new patch will soon be available and post on this list.

Sallantin, = R.; Baudoin, C.; Chaput, E.; Arnal, F.; Dubois, E.; Beylot, A.-L., "Initial spreading: A fast Start-Up TCP mechanism," Local Computer Networks (LCN), 2013 IEEE 38th Conference on , vol., no., pp.492,499, 21-24 Oct. 2013

Sallantin, R; Baudoin, C; Chaput,E; Arnal, F; Dubois,E; Beylot, A, "A TCP model for short-lived flows to validate initial spreading," Local Computer Networks (LCN), 2014 IEEE 39th Conference on , vol., no., pp.177,184, 8-11 Sept. 2014


To conclude, we share the same concern about optimizing the IW transmission as discussed in "draft-you-tcpm-configuring-tcp-initial-w= indow" and related mail exchanges.=C2=A0We are also convinced that using the information that can be learned about the connection characteristics is critical to ensure the best start.=C2=A0
However, ,instead o= f considerations on the flow size, we use the initial RTT measurement to improve the IW transmission.=C2=A0

We would li= ke to receive your feedback,

Best regards,
Renaud Sallantin

--001a1134c6de49322c05067b36be-- From nobody Wed Oct 29 10:00:23 2014 Return-Path: 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 863C41A1BF4 for ; Wed, 29 Oct 2014 10:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TjhreZi6RodL for ; Wed, 29 Oct 2014 10:00:16 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FCD1A1BEA for ; Wed, 29 Oct 2014 10:00:13 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 29 Oct 2014 17:00:12 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 29 Oct 2014 17:00:08 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 29 Oct 2014 17:00:01 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9TH01jU026074 for ; Wed, 29 Oct 2014 17:00:01 GMT Message-ID: <201410291700.s9TH01jU026074@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Oct 2014 17:00:00 +0000 To: tcpm IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SvCcHMq_CAOzSL1UOsGlD9yJTvY Subject: [tcpm] Accurate ECN status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:00:18 -0000 Folks, Initial reactions to AccECN were that it was hard to understand (ie no longer simple). This had been necessary to ensure middlebox traversal. We intended to propose a strawman design that would be simpler but with with poorer middlebox traversal - intended to enable a discussion on the merits of each. However, we are holding back until the dust settles a little in tcpm on the merits of different ways of extending TCP option space. If a good middlebox traversal solution comes out of that, AccECN could just use it. Bob ________________________________________________________________ Bob Briscoe, BT From nobody Fri Oct 31 07:58:04 2014 Return-Path: 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 EA9471A007D for ; Fri, 31 Oct 2014 07:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ROJNMnHE4Yor for ; Fri, 31 Oct 2014 07:57:56 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FFA1A0111 for ; Fri, 31 Oct 2014 07:57:56 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9VEvswa001271 for ; Fri, 31 Oct 2014 08:57:54 -0600 (CST) From: David Borman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 31 Oct 2014 09:57:55 -0500 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xWbhHTenWcKW_zylkDMgKHEPIso Subject: [tcpm] We already support multiple versions of the TCP header X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:58:03 -0000 I won=E2=80=99t be at the Honolulu IETF, so I=E2=80=99d like some more = discussion going here on the list. This message is to explicitly bring up some issues that haven=E2=80=99t really been addressed yet, and to = hopefully bring some clarity to what decisions need to be made. A key point is that using expanded option space during connection establishment should be separated from how that expanded option space is encoded. TCP Header Versions ------------------- The EDO option is really just another example of how do you support a new version of the TCP header. We=E2=80=99ve done it with Window Scale; once negotiated, the TCP header has been modified for the duration of the connection, in how the Window field is interpreted. TCP doesn=E2=80=99t have a version number, so the approach taken by both WS and EDO is that both sides determine that the modification to the TCP header is understood, and then it takes effect by mutual agreement to change how the TCP header is interpreted. The focus has been on a single TCP connection to an unknown host, so no a priori knowledge of whether or not the other side supports the new TCP header. The mechanism provided by TCP is to use TCP options, the initial SYN has to assume the legacy TCP header until it can find out otherwise from the other system, but include everything needed in a TCP option. Say we wanted to define an entirely new TCP header that was 40 bytes long, and include it verbatim in a TCP option in the initial SYN, so as to not introduce any latency or degradation for either legacy or updated TCP implementations. But it won=E2=80=99t fit, so we need the = expanded option space to include the new TCP header. But by definition, the expanded option space doesn=E2=80=99t fit in the existing option space. Hence, the expanded option space is our chicken-and-the-egg problem. By now I assume that everyone is convinced that there is no clever way to include expanded option space in an initial SYN, such that a legacy TCP will properly ignore the extra option space, and still continue to process the packet as a normal SYN packet. Hence the only way to send the additional options are in a second packet. Now the question becomes how the legacy TCP deals with that second packet. 1) Ignore it: SYN-EOS Uses a normal SYN and a separate OOB packet to contain the extended option space. The OOB packet does not have the SYN or the ACK bit set, which legacy implementations should silently drop. 2) Abort it: Inner-space Uses two SYN packets for two distinct TCP connections, one with the extended option space and one without. The client terminates the extended option space connection before it becomes established if it gets a response indicating that it is a legacy TCP, else it terminates the first connection if the remote host indicates it supports extended option space. 3) Don=E2=80=99t send it: Four-way Handshake (4WHS) Uses a normal SYN, but does not make use of extended option space until it knows that the other side supports it. It replaces the ACK with a SYN,ACK so that there is another SYN packet client->server than can use extended option space. These can be classified into two categories: 1) Include the extended option space packet within a single TCP session. o SYN-EOS o 4WHS 2) Create 2 TCP sessions, one with and one without extended option space, then abort one of the connections. This is a dual-SYN approach. o Inner-space How you encode the extended option space is a separate issue. There are two techniques on the table, EDO and Inner-space. Either one of these techniques could be used with any of the three proposals. So the first question is whether to use a dual-SYN approach, or to use a single TCP connection. The TCP State Machine --------------------- TCP is not just the format of the bits on the wire, it is also the processing at each end of the connection, done through the TCP state machine. The introduction of a second packet to contain the extended option space needs to be accounted for in the TCP state machine. TCP runs off of state transitions based on packets received and packets sent. Timers ensure that control and data packets are retransmitted if they are not acknowledged. (Yes, there are other timers, such as for delayed ACKs, but that is an efficiency enhancement, TCP can functionally operate without them). I believe that this model has = served TCP very well over the years, and we should continue to stick to this basic model. The current SYN-EOS description does not follow this model due to: If an upgraded server has received only a SYN with the SYN-EOS option but no corresponding OOB segment, after a certain time it MUST proceed with the connection as if the SYN had been received without the SYN-EOS option. I.e. it processes all other TCP options and responds with a SYN/ACK without the SYN-EOS option. and >> If a server, whether upgraded or not, receives only an OOB segment and no corresponding SYN, it MUST discard it and it MUST NOT ever respond (see Security Considerations). Inner-space adds a layer above the standard TCP state machine, to manage the dual connections and to decide which one to abort. The state machine has to be modified to have knowledge of the parallel connection, so the added layer can hook in when determining which connection to abort or to allow to continue. The Four-way Handshake is defined with extensions to the existing TCP state machine, so it already fits into the current model. Delivering User Data -------------------- Today, even if SYN packets have user data, the data is not delivered to the application until the connection has entered ESTABLISHED state. The cleanest way to extend the option space is with a five way handshake. An initial two packet exchange is used to discover that the remote host supports extended option space, then a full three-way handshake can ensue making use of the extended option space. This approach has been mostly dismissed because it adds a full RTT to connection establishment, delaying when user data can be presented to the application. The Four-way handshake adds one extra packet to the connection startup, the server still enters ESTABLISHED after the first 3 packets, but the client doesn=E2=80=99t enter ESTABLISHED until after = all 4 packets, instead of only 2 with the three way handshake. Depending on the direction of the initial data, and whether or not it is included in a SYN packet, there is either a 0 or 1 RTT change in when the initial data can be delivered to the application. The SYN-EOS approach uses the standard 3WHS, so the timing of presenting user data is mostly unchanged. The dual-SYN approach, for the connection that goes to established, also completes the standard 3WHS, so the timing of presenting user data is also mostly unchanged. So at first blush, when thinking about presenting user data, the SYN-EOS and Dual-SYN approaches appear to be better than the 4WHS. But before making that quick decision, I=E2=80=99d like to consider what is the real criteria for when it is safe to present user data to the application. The reason that data in the initial SYN is not presented to the application is that given a single inbound SYN, we can not verify verify that this is a genuine connection startup, i.e., it could be an old duplicate SYN. The criteria for allowing initial data in the SYN to be presented to the application is that we have sent a SYN packet to the other side, and we have received acknowledgment of that SYN. That takes a 3 packet exchange, which happens to correspond exactly with the 3WHS entering ESTABLISHED state. If we take the same criteria and apply it to the 4WHS, then we can see that delivering the initial data does not have to be delayed due to the additional packet exchange; once the first 3 packets have been exchanged both sides have verified that this is a viable connection, and it should be safe to deliver any user data to the application, making this no different than the 3WHS when considering when data can be delivered to the application. The 4WHS added a conditional transition for the client from SYN-SENT to SYN-RCVD, mirroring the transition that happens during a simultaneous open. Instead it would go to a parallel state, say PRE-ESTABLISHED, that would be identical to SYN-RCVD, with the exception that user data could be delivered to the application, implying that the connect() call would return without waiting for the transition to ESTABLISHED. In closing... ------------- Clearly I think that the 4WHS has some nice properties, since it is what I have proposed. My biggest concern has been with the delay in presenting user data to the application, but I now believe that that is no longer an issue, for the reasons stated above. I think that the 4WHS has applications beyond just expanding the option space, that=E2=80=99s just the most immediate issue that it can be used to address. I also like that the 4WHS continues to use single packets for each TCP state transition. The SYN-EOS approach complicates initial connection startup with two parallel packets, and rules need to be developed for how to handle all combinations of reordering or either packet getting lost. This can be done, but there are more state transitions than with the 4WHS. The biggest downside of the Dual-SYN approach, in my mind, is that it does not handle the case where an application needs to specify the source port number for a connection. The simultaneous open case becomes very tricky, if not impossible, since by definition a simultaneous open requires specification of the source port. While the vast majority of TCP connections are client->server with the client not caring about the source port, I=E2=80=99m not ready to give up that functionality to solve the extended option space problem. I also believe that the way that the extended option space is defined is orthogonal to how connections get established with knowledge that the other side supports extended option space. You could do inner-space options using an OOB packet or as part of a 4WHS, you could use EDO with a Dual-SYN approach. It=E2=80=99ll be easier to make forward progress if we separate using extended option space from how the extended option space is encoded. -David Borman= From nobody Fri Oct 31 10:05:52 2014 Return-Path: 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 754421A0149 for ; Fri, 31 Oct 2014 10:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 nniNFfombVZ0 for ; Fri, 31 Oct 2014 10:05:48 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 534841A00E1 for ; Fri, 31 Oct 2014 10:05:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 06AE9C94C1; Fri, 31 Oct 2014 13:05:40 -0400 (EDT) Date: Fri, 31 Oct 2014 13:05:40 -0400 From: John Leslie To: David Borman Message-ID: <20141031170539.GN525@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XcrisUmCqePYm80H_SoEBcaCTMQ Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] We already support multiple versions of the TCP header X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:05:51 -0000 David Borman wrote: > > I won't be at the Honolulu IETF, :^( :^( > so I'd like some more discussion going here on the list. :^) :^) > This message is to explicitly bring up some issues that haven't really > been addressed yet, and to hopefully bring some clarity to what > decisions need to be made. Alas, exchanges between the same few participants don't seem likely to accomplish this. :^( Yet, if we can get the discussion on-list, everything can work better... > A key point is that using expanded option space during connection > establishment should be separated from how that expanded option space > is encoded. For discussion purposes, I entirely agree. > TCP Header Versions > ------------------- > The EDO option is really just another example of how do you > support a new version of the TCP header. I'd much rather we used a different name than "EDO" here. EDO has been adopted as a WG document; and holds the promise of solving our problem after the SYN and SYN-ACK, and possibly for the SYN-ACK itself. We should not abandon that promise. Nonetheless, there is great value in solving the problem of expanding option space starting with the original SYN. I'd like to see this actively explored. > We've done it with Window Scale; once negotiated, the TCP header has > been modified for the duration of the connection, in how the Window > field is interpreted. That, alas, was a much simpler problem. There was no reason to worry about window scaling on the initial SYN; and RFC 1323 happened in 1992, before we had all those meddleboxes to deal with. > TCP doesn't have a version number, so the approach taken by both WS > and EDO (PLEASE, can we use a different term here?) > is that both sides determine that the modification to the TCP header > is understood, and then it takes effect by mutual agreement to > change how the TCP header is interpreted. Indeed, mutual agreement seems to be the only way to proceed. Alas, in 2014 we _have_ all those meddleboxes. :^( :^( :^( > The focus has been on a single TCP connection to an unknown host, > so no a priori knowledge of whether or not the other side supports > the new TCP header. (That, of course, is not the only possible scenario...) > The mechanism provided by TCP is to use TCP options, the initial SYN > has to assume the legacy TCP header until it can find out otherwise > from the other system, Yes. > but include everything needed in a TCP option. We like to believe that a TCP option will either tunnel through any middleboxes, or be dropped by them. Alas, this may not always be true... > Say we wanted to define an entirely new TCP header that was 40 bytes > long, and include it verbatim in a TCP option in the initial SYN, so > as to not introduce any latency or degradation for either legacy or > updated TCP implementations. But it won't fit, Yes. :^( > so we need the expanded option space to include the new TCP header. (This is a good way to think about our problem.) > But by definition, the expanded option space doesn't fit in the > existing option space. Thus, we must look elsewhere. > Hence, the expanded option space is our chicken-and-the-egg problem. > By now I assume that everyone is convinced that there is no clever way > to include expanded option space in an initial SYN, such that a > legacy TCP will properly ignore the extra option space, and still > continue to process the packet as a normal SYN packet. (Actually, that is _almost_ solvable; but there's no hope of avoiding middlebox damage. So I _do_ agree we need to find something else.) > Hence the only way to send the additional options are in a second > packet. I don't think that's quite correct. Parallel-SYN approaches can send one packet with added options and one without. At the very least, the one _with_ added options can be sent first. But also, there could be ways to ensure the _with_extra_options_ packet could never lead to a legacy connection -- and there will certainly be some cases (in the future) where there's no point in establishing a legacy connection at all. Nonetheless, I'm quibbling here... > Now the question becomes how the legacy TCP deals with that second > packet. > 1) Ignore it: SYN-EOS > Uses a normal SYN and a separate OOB packet to contain > the extended option space. The OOB packet does not have the SYN > or the ACK bit set, which legacy implementations should > silently drop. "should" is a big question here! > 2) Abort it: Inner-space > Uses two SYN packets for two distinct TCP connections, > one with the extended option space and one without. The client > terminates the extended option space connection before it becomes > established if it gets a response indicating that it is a legacy > TCP, else it terminates the first connection if the remote host > indicates it supports extended option space. This _does_ sound ugly; but it _is_ workable. IMHO we'd be foolish to rule it out entirely at this point; but it seems to require a significant period of experimental status (during which we would hope to finish something better). > 3) Don't send it: Four-way Handshake (4WHS) > Uses a normal SYN, but does not make use of extended option > space until it knows that the other side supports it. It > replaces the ACK with a SYN,ACK so that there is another > SYN packet client->server than can use extended option space. This is an interesting approach. While I very much want to consider it, I'm leaving the lengthy explanation out of this response -- it deserves its own thread. > These can be classified into two categories: > > 1) Include the extended option space packet within a single TCP session. > o SYN-EOS > o 4WHS > > 2) Create 2 TCP sessions, one with and one without extended option > space, then abort one of the connections. This is a dual-SYN > approach. > o Inner-space > > How you encode the extended option space is a separate issue. "Separable," certainly; and I'm happy to separate them here. > There are two techniques on the table, EDO and Inner-space. PLEASE, don't use the name EDO for this: it's not even clear what David intend this term to refer to. > Either one of these techniques could be used with any of the three > proposals. As well as many other encodings... > So the first question is whether to use a dual-SYN approach, or to > use a single TCP connection. That's exactly the kind of question I _don't_ want the WG to try to solve. Nonetheless, David should get an opportunity to explain why his solution is better. (Just not here: I'll start another thread for that.) ==== We have three proposals for how to expand option space beginning in the initial SYN. IMHO, all three deserve Experimental status. High among the issue needing to be resolved is middlebox damage. WG participants have many different approaches to dealing with middlebox damage. I tend to think so long as we detect it, the specifics about routing around it don't need to be solved right now. YMMV. I see no reason three experiments can't run it parallel: there seems to be no obvious reason the three proponents can't find folks to work on all three. What I wish this WG would do is give those three free rein to experiment; but process EDO-as-adopted to RFC status. Myself, I don't see how any of the three initial-SYN options can reach substantial deployment in under five years, while EDO could. -- John Leslie From nobody Fri Oct 31 11:01:47 2014 Return-Path: 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 75D1F1A0378 for ; Fri, 31 Oct 2014 11:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ydJq7kqC7HZa for ; Fri, 31 Oct 2014 11:01:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ADCC21A037C for ; Fri, 31 Oct 2014 11:01:41 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E341FC94C0; Fri, 31 Oct 2014 14:01:28 -0400 (EDT) Date: Fri, 31 Oct 2014 14:01:28 -0400 From: John Leslie To: David Borman Message-ID: <20141031180128.GO525@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/G80qOyEjHOj-F7631CXiWPlz9h8 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: [tcpm] Four-way Handshake justification X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 18:01:46 -0000 David Borman wrote: > > The TCP State Machine > --------------------- > TCP is not just the format of the bits on the wire, it is also the > processing at each end of the connection, done through the TCP state > machine. I agree with David that nothing which messes with the state machine should proceed to Proposed Standard without a clear description of what changes to the state machine it proposes. (But that's not _as_ necessary for Experimental status...) > The introduction of a second packet to contain the extended option > space needs to be accounted for in the TCP state machine. TCP > runs off of state transitions based on packets received and packets > sent. Timers ensure that control and data packets are retransmitted > if they are not acknowledged. (Those timers deserve mention; but I'm not convinced that particular values are needed.) > (Yes, there are other timers, such as for delayed ACKs, but that is > an efficiency enhancement, TCP can functionally operate without them). (Actually, TCP-bis could operate without timers also.) > I believe that this model has served TCP very well over the years, > and we should continue to stick to this basic model. Agreed. But at this stage of discussion, eyes would tend to glaze if we talk too much of the state machine. > The current SYN-EOS description does not follow this model due to: > > If an upgraded server has received only a SYN with the SYN-EOS > option but no corresponding OOB segment, after a certain time it > MUST proceed with the connection as if the SYN had been received > without the SYN-EOS option. I.e. it processes all other TCP options > and responds with a SYN/ACK without the SYN-EOS option. This indeed is hand-waving. :^( > and > >> If a server, whether upgraded or not, receives only an OOB > segment and no corresponding SYN, it MUST discard it and it > MUST NOT ever respond (see Security Considerations). As is that. :^( But IMHO, even such obvious hand-waving could make its way into an Experimental document by simply saying that determining the timer values is part of the experiment. > Inner-space adds a layer above the standard TCP state machine, to > manage the dual connections and to decide which one to abort. The > state machine has to be modified to have knowledge of the parallel > connection, so the added layer can hook in when determining which > connection to abort or to allow to continue. It is described that way right now, and may or may not stay as a layer above the TCP state machine. I'm not too concerned until we try to progress it to Proposed Standard. > The Four-way Handshake is defined with extensions to the existing > TCP state machine, so it already fits into the current model. I thank David for doing this. (But I worry how many eyes are glazed... > Delivering User Data > -------------------- > Today, even if SYN packets have user data, the data is not delivered > to the application until the connection has entered ESTABLISHED state. Very important. Hopefully we realize that TCP-Fast-Open will have to be a special-case in whatever we propose. > The cleanest way to extend the option space is with a five way > handshake. An initial two packet exchange is used to discover that > the remote host supports extended option space, then a full three-way > handshake can ensue making use of the extended option space. Indeed! > This approach has been mostly dismissed because it adds a full RTT to > connection establishment, delaying when user data can be presented > to the application. David correctly states that few uses of TCP will happily wait an extra RTT. > The Four-way handshake adds one extra packet to the connection > startup, the server still enters ESTABLISHED after the first 3 > packets, but the client doesn???t enter ESTABLISHED until after all > 4 packets, instead of only 2 with the three way handshake. This is the critical think to understand. (And I agree with David that it's best understood as a change to the state machine.) > Depending on the direction of the initial data, and whether or not > it is included in a SYN packet, there is either a 0 or 1 RTT change > in when the initial data can be delivered to the application. (Note that an extra RTT to when a client may receive server data is not considered trivial. Nonetheless, it is not necessarily fatal.) > The SYN-EOS approach uses the standard 3WHS, so the timing of > presenting user data is mostly unchanged. > > The dual-SYN approach, for the connection that goes to established, > also completes the standard 3WHS, so the timing of presenting user > data is also mostly unchanged. Neither of those necessarily add delay. > So at first blush, when thinking about presenting user data, the > SYN-EOS and Dual-SYN approaches appear to be better than the 4WHS. > But before making that quick decision, I'd like to consider what > is the real criteria for when it is safe to present user data to > the application. This gets a bit complicated; but is very worth considering. > The reason that data in the initial SYN is not presented to the > application is that given a single inbound SYN, we can not verify > verify that this is a genuine connection startup, i.e., it could > be an old duplicate SYN. (I'm biting my tongue here; but I'll let that pass.) > The criteria for allowing initial data in the SYN to be presented > to the application is that we have sent a SYN packet to the other > side, and we have received acknowledgment of that SYN. That takes > a 3 packet exchange, which happens to correspond exactly with the > 3WHS entering ESTABLISHED state. (NB: TCP-Fast-Open uses a different paradigm of what constitutes sufficient confirmation.) > If we take the same criteria and apply it to the 4WHS, then we > can see that delivering the initial data does not have to be > delayed due to the additional packet exchange; once the first 3 > packets have been exchanged both sides have verified that this is > a viable connection, and it should be safe to deliver any user > data to the application, making this no different than the 3WHS > when considering when data can be delivered to the application. (Alas, we will have to consider middlebox damage sometime.) > The 4WHS added a conditional transition for the client from > SYN-SENT to SYN-RCVD, mirroring the transition that happens > during a simultaneous open. Instead it would go to a parallel > state, say PRE-ESTABLISHED, that would be identical to SYN-RCVD, > with the exception that user data could be delivered to the > application, implying that the connect() call would return > without waiting for the transition to ESTABLISHED. I'm not positive even I understand this paragraph. I think David is talking about the sender of the original SYN -- moving to SYN-RCVD state when it receives the SYN-ACK. By his 4-way handshake, it goes to SYN-RECEIVED state instead of ESTABLISHED. He seems to be saying that the original sender might instead enter a new PRE-ESTABLISHED state upon sending its own SYN-ACK; and upon entering that state it could deliver the data it received in the first SYN-ACK to the originating application. My eyes are already a bit glazed... I don't understand how that could be particularly useful data. > In closing... > ------------- > Clearly I think that the 4WHS has some nice properties, since it > is what I have proposed. My biggest concern has been with the delay > in presenting user data to the application, but I now believe that > that is no longer an issue, for the reasons stated above. I think > that the 4WHS has applications beyond just expanding the option > space, that's just the most immediate issue that it can be used to > address. Indeed, it does seem that a 4-way handshake has potential beyond just added option space. :^) > I also like that the 4WHS continues to use single packets for each > TCP state transition. I share some of David's concern about trying to relate OOB packets to the TCP state machine. > The SYN-EOS approach complicates initial connection startup with > two parallel packets, and rules need to be developed for how to > handle all combinations of reordering or either packet getting > lost. This can be done, but there are more state transitions > than with the 4WHS. Perhaps Joe would like to respond here... > The biggest downside of the Dual-SYN approach, in my mind, is that > it does not handle the case where an application needs to specify > the source port number for a connection. An interesting question. (There certainly are cases where the originator of a TCP connection needs to use a known port: BGP comes to mind first...) But, honestly, I doubt that any of those cases will need expanded option space. (And I very much hope that we'll be able to continue using legacy TCP where the option space is already sufficient.) > The simultaneous open case becomes very tricky, if not impossible, > since by definition a simultaneous open requires specification of > the source port. This strikes me as a more serious issue. Of course, simultaneous-open is not expected to ever occur in the client-server paradigm; and I'm not sure this is actually any worse than the BGP case... > While the vast majority of TCP connections are client->server > with the client not caring about the source port, I'm not ready > to give up that functionality to solve the extended option space > problem. Good point, there. But I see no reason to object to Experimental status because of that. > I also believe that the way that the extended option space is > defined is orthogonal to how connections get established with > knowledge that the other side supports extended option space. It certainly could be... > You could do inner-space options using an OOB packet or as part of > a 4WHS, you could use EDO with a Dual-SYN approach. I see no reason to go there. The proposals are hard enough to understand as it is. > It'll be easier to make forward progress if we separate using > extended option space from how the extended option space is > encoded. I'm afraid I disagree. Our path forward will be far easier if we give the three proposals free rein to experiment. -- John Leslie From nobody Fri Oct 31 12:15:01 2014 Return-Path: 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 5C5CC1A1A4E for ; Fri, 31 Oct 2014 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 EiaqgSo7qcpX for ; Fri, 31 Oct 2014 12:14:50 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BB31A02F1 for ; Fri, 31 Oct 2014 12:14:49 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s9VJEkfX005400; Fri, 31 Oct 2014 13:14:47 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Borman In-Reply-To: <20141031180128.GO525@verdi> Date: Fri, 31 Oct 2014 14:14:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <10A9C4EF-A5EF-42DB-ABF2-1F51BC836F52@weston.borman.com> References: <20141031180128.GO525@verdi> To: John Leslie X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/R8oab1wSVhdl8rdQAqKsCQnFDAE Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Four-way Handshake justification X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:14:58 -0000 John, Thanks for the well thought out response. I=E2=80=99ll touch on just a few points, in hopes of less eyes glazing = over. :-) > On Oct 31, 2014, at 1:01 PM, John Leslie wrote: >=20 > David Borman wrote: ... >> Inner-space adds a layer above the standard TCP state machine, to >> manage the dual connections and to decide which one to abort. The >> state machine has to be modified to have knowledge of the parallel >> connection, so the added layer can hook in when determining which >> connection to abort or to allow to continue. >=20 > It is described that way right now, and may or may not stay as a > layer above the TCP state machine. I'm not too concerned until we > try to progress it to Proposed Standard. For me the key issue here is that currently a single TCP connection is processed in isolation, it doesn=E2=80=99t really matter what is = going on in other parallel TCP connections. With the dual connection model, we now have pairs of TCP connections that need to be processed with consideration for the state of the other TCP connection. ... >> The 4WHS added a conditional transition for the client from >> SYN-SENT to SYN-RCVD, mirroring the transition that happens >> during a simultaneous open. Instead it would go to a parallel >> state, say PRE-ESTABLISHED, that would be identical to SYN-RCVD, >> with the exception that user data could be delivered to the >> application, implying that the connect() call would return >> without waiting for the transition to ESTABLISHED. >=20 > I'm not positive even I understand this paragraph. I think > David is talking about the sender of the original SYN -- moving to > SYN-RCVD state when it receives the SYN-ACK. By his 4-way handshake, > it goes to SYN-RECEIVED state instead of ESTABLISHED. He seems to be > saying that the original sender might instead enter a new > PRE-ESTABLISHED state upon sending its own SYN-ACK; and upon > entering that state it could deliver the data it received in the > first SYN-ACK to the originating application. The point is the active (client) side of the connection sends a SYN, and when the SYN,ACK comes back, if it contains user data, it is safe to make that available to the application. For the passive (server) side, it receives a SYN with some data, but it has to buffer it and send back a SYN,ACK. When it receives an ACK for its SYN, it can now safely deliver the data to the application. This is exactly what happens with the 3WHS, and corresponds with transitioning to ESTABLISHED state. You can use the same criteria with the 4WHS for when it is safe to deliver data to the application. For the active side, this happens when it transitions from SYN-SENT to SYN-RCVD instead of to ESTABLISHED. I am adding the PRE-ESTABLISHED state so that it isn=E2=80=99t overloading the SYN-RCVD state, which is normally only reached by the active side during a simultaneous open, when it is *not* safe to make user data available, because its SYN has not yet been ACKed. ... >> In closing... >> ------------- >> Clearly I think that the 4WHS has some nice properties, since it >> is what I have proposed. My biggest concern has been with the delay >> in presenting user data to the application, but I now believe that >> that is no longer an issue, for the reasons stated above. I think >> that the 4WHS has applications beyond just expanding the option >> space, that's just the most immediate issue that it can be used to >> address. >=20 > Indeed, it does seem that a 4-way handshake has potential beyond > just added option space. :^) What it really does is allow the passive (server) side of the connection to initiate some aspects of the connection setup, rather than being limited to just responding to the initiatives from the active (client) side. And, it does that with a packet containing a control bit (SYN), which is reliably transmitted. For example: The MPTCP specification uses the final ACK as (an optional) part of MP_CAPABLE negotiation, where it contains both keys, allowing the server to act statelessly. Today that ACK is not reliably transmitted, with the 4WHS it would be part of the SYN,ACK and be reliably transmitted. Today, for a stateless server, if that ACK is lost, the connection will never complete, because the ACK is never retransmitted. ... > John Leslie -David Borman From nobody Fri Oct 31 13:08:01 2014 Return-Path: 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 5A0DE1A07BC for ; Fri, 31 Oct 2014 13:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 KnSiLAFUlB-V for ; Fri, 31 Oct 2014 13:07:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA481A0410 for ; Fri, 31 Oct 2014 13:07:55 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9VK7h48003596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 13:07:44 -0700 (PDT) Message-ID: <5453EC0F.3070908@isi.edu> Date: Fri, 31 Oct 2014 13:07:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Borman , "tcpm@ietf.org (tcpm@ietf.org)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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/3n_c4_-O2GlrGqTFGotaxXAt2R0 Subject: Re: [tcpm] We already support multiple versions of the TCP header X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 20:07:58 -0000 On 10/31/2014 7:57 AM, David Borman wrote: ... > The TCP State Machine > --------------------- > TCP is not just the format of the bits on the wire, it is also the > processing at each end of the connection, done through the TCP state > machine. The introduction of a second packet to contain the extended > option space needs to be accounted for in the TCP state machine. TCP > runs off of state transitions based on packets received and packets > sent. Timers ensure that control and data packets are retransmitted > if they are not acknowledged. (Yes, there are other timers, such as > for delayed ACKs, but that is an efficiency enhancement, TCP can > functionally operate without them). I believe that this model has served > TCP very well over the years, and we should continue to stick to this > basic model. > > The current SYN-EOS description does not follow this model due to: > > If an upgraded server has received only a SYN with the SYN-EOS > option but no corresponding OOB segment, after a certain time it > MUST proceed with the connection as if the SYN had been received > without the SYN-EOS option. I.e. it processes all other TCP options > and responds with a SYN/ACK without the SYN-EOS option. > and > >> If a server, whether upgraded or not, receives only an OOB > segment and no corresponding SYN, it MUST discard it and it MUST NOT > ever respond (see Security Considerations). If a SYN-EOS is received without the OOB packet, the server has three options, based on whether the server supports SYN-EOS: if SYN-EOS isn't supported, ACK without the EOS flag if SYN-EOS is supported: a) wait for retransmission (the client would retransmit both SYN-EOS and OOB) NB: during this time, the SYN-EOS could be cached for pairing with the OOB when it arrives, but doesn't have to be b) give up and act like a non-SYN-EOS server I don't see any impact on the state machine. ... > The Four-way Handshake is defined with extensions to the existing > TCP state machine, so it already fits into the current model. It fits into the model by *changing* the model to a new one. That's not called "fitting", FWIW. ... > The reason that data in the initial SYN is not presented to the > application is that given a single inbound SYN, we can not verify > verify that this is a genuine connection startup, i.e., it could > be an old duplicate SYN. The criteria for allowing initial data > in the SYN to be presented to the application is that we have > sent a SYN packet to the other side, and we have received > acknowledgment of that SYN. That takes a 3 packet exchange, > which happens to correspond exactly with the 3WHS entering > ESTABLISHED state. > > If we take the same criteria and apply it to the 4WHS, then > we can see that delivering the initial data does not have to > be delayed due to the additional packet exchange; once the > first 3 packets have been exchanged both sides have verified > that this is a viable connection, and it should be safe to > deliver any user data to the application, making this no > different than the 3WHS when considering when data can be > delivered to the application. I continue to believe this isn't accurate, and that the user data shouldn't be delivered in 4WHS until the final ACK is exchanged (5WHS). I agree that *part* of the 3WHS exchange is to coordinate the initial SYN, but IMO it's also to coordinate all the options that have been negotiated, and I still am unconvinced this happens for all use cases for options in 4WHS. ... > The SYN-EOS approach complicates initial connection startup > with two parallel packets, and rules need to be developed for > how to handle all combinations of reordering or either packet > getting lost. Caching a limited amount of such packets solves that. > This can be done, but there are more state > transitions than with the 4WHS. SYN-EOS uses exactly the same transitions as 3WHS, which is less than 4WHS. ... > It’ll be easier to make forward progress if we separate using > extended option space from how the extended option space is > encoded. +1, but I also believe that it isn't our job to "get around" all possible NAT behaviors by - in effect - running TCP inside TCP, which is how I view in-band encoding of the options in innerspace. Joe From nobody Fri Oct 31 13:18:34 2014 Return-Path: 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 D9F891A0404 for ; Fri, 31 Oct 2014 13:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 THL-PMPo6Hvi for ; Fri, 31 Oct 2014 13:18:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB0D1A00C2 for ; Fri, 31 Oct 2014 13:18:31 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9VKHvpB005275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 13:17:57 -0700 (PDT) Message-ID: <5453EE75.5040307@isi.edu> Date: Fri, 31 Oct 2014 13:17:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , David Borman References: <20141031170539.GN525@verdi> In-Reply-To: <20141031170539.GN525@verdi> 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/Jr2jPbbfhfFlCP3nX02X7BxULGk Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] We already support multiple versions of the TCP header X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 20:18:33 -0000 FWIW, IMO, there are four things on the "table" EDO - the current WG doc negotiated during the SYN, active after SYN-ACK and maybe for SYN-ACK too (depends on what WG decides vs. the potential for asymmetric middleboxes with currently unseen behaviors) 4WHS - (as already known) Dual-SYN (I don't care if Bob wants to call this something else, but I don't want to call it "innerspace" because that includes the in-band encoding, and I agree with David that encoding is orthogonal, and it's basically a "dual-stack" approach) SYN+OOB - Yeah, the name has changed a lot, but IMO that's the most accurate term that differentiates it from the others On 10/31/2014 10:05 AM, John Leslie wrote: ... >> TCP doesn't have a version number, so the approach taken by both WS >> and EDO > > (PLEASE, can we use a different term here?) EDO is the correct term AFAICT; we're not talking about the SYN variants for this statement, are we? >> Hence the only way to send the additional options are in a second >> packet. For the SYN (and maybe the SYN-ACK too, if you believe the asymmetric rogue middlebox case). ... >> How you encode the extended option space is a separate issue. > > "Separable," certainly; and I'm happy to separate them here. > >> There are two techniques on the table, EDO and Inner-space. EDO does also include a way of encoding where the new space is, and these are the two variants that can be used by either SYN-extensions or after-SYN extensions. I'd prefer to call them "new header space vs. in-band encoding". I agree calling the former "EDO" isn't useful. > What I wish this WG would do is give those three free rein to > experiment; but process EDO-as-adopted to RFC status. Myself, I > don't see how any of the three initial-SYN options can reach > substantial deployment in under five years, while EDO could. The only issue here is TCPCRYPT - if you beleive that group will do something useful. They could deploy a SYN extension at the same time as their system, which would help get experience faster, but I don't think any of us wants or expects them to support multiple solutions. Joe From nobody Fri Oct 31 13:20:49 2014 Return-Path: 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 B78281A00C2 for ; Fri, 31 Oct 2014 13:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 F0G_3FkvI3kz for ; Fri, 31 Oct 2014 13:20:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E201A1A2E for ; Fri, 31 Oct 2014 13:20:46 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9VKKA8w005541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 13:20:10 -0700 (PDT) Message-ID: <5453EEFA.3080204@isi.edu> Date: Fri, 31 Oct 2014 13:20:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie , David Borman References: <20141031180128.GO525@verdi> In-Reply-To: <20141031180128.GO525@verdi> 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/b6MdlmNMu36dkqV13kM2g71kGvA Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Four-way Handshake justification X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 20:20:47 -0000 On 10/31/2014 11:01 AM, John Leslie wrote: >> (Yes, there are other timers, such as for delayed ACKs, but that is >> > an efficiency enhancement, TCP can functionally operate without them). I'm not sure I agree with this. It seems like TCP would lockup and never make progress if packets were lost. Joe