From nobody Sat Nov 1 10:08: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 507F31A0089 for ; Sat, 1 Nov 2014 10:08: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 lT0OTUqn_ceQ for ; Sat, 1 Nov 2014 10:08:00 -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 C977C1A89E9 for ; Sat, 1 Nov 2014 10:07:59 -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 sA1H7vmi024240; Sat, 1 Nov 2014 11:07:58 -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: <5453EEFA.3080204@isi.edu> Date: Sat, 1 Nov 2014 12:07:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141031180128.GO525@verdi> <5453EEFA.3080204@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UPoKe5Ao8Q-NmuKl5DVBIFOSMDI 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: Sat, 01 Nov 2014 17:08:02 -0000 > On Oct 31, 2014, at 3:20 PM, Joe Touch wrote: > 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). >=20 > I'm not sure I agree with this. >=20 > It seems like TCP would lockup and never make progress if packets were = lost. The sentence right before that was: Timers ensure that control and data packets are retransmitted if they are not acknowledged. Those timers ensure that TCP doesn=E2=80=99t lock up, by retransmitting = un-ACKed data and control(SYN,FIN) packets. ACK only packets are never = retransmitted. The delayed ACK timer isn=E2=80=99t part of the reliability of TCP, it = is a performance improvement that allows consolidation of ACKs. ACKs could always be sent immediately in response to the incoming packet instead of being delayed by a timer. -David >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Nov 1 10:25: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 042FB1A000D for ; Sat, 1 Nov 2014 10:25: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 kKhWLvVUqiSo for ; Sat, 1 Nov 2014 10:25:24 -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 29D771A89E7 for ; Sat, 1 Nov 2014 10:25:21 -0700 (PDT) Received: from [192.168.1.4] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id sA1HOwRR016610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Nov 2014 10:25:02 -0700 (PDT) References: <20141031180128.GO525@verdi> <5453EEFA.3080204@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (12B411) From: Joe Touch Date: Sat, 1 Nov 2014 10:24:58 -0700 To: David Borman 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/uvXKDgXdrzISbMnhg2A-mNzMPTw 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: Sat, 01 Nov 2014 17:25:26 -0000 > On Nov 1, 2014, at 10:07 AM, David Borman wrote: >=20 >=20 >> On Oct 31, 2014, at 3:20 PM, Joe Touch wrote: >> 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).= >>=20 >> I'm not sure I agree with this. >>=20 >> It seems like TCP would lockup and never make progress if packets were lo= st. >=20 > The sentence right before that was: > Timers ensure that control and data packets are retransmitted > if they are not acknowledged. I'm not sure how you can claim tcp can functionally operate without them. Ip= isn't lossless even over a lossless link layer.=20 Many argue that timers are the only fundamental part of any protocol (esp. W= atson, Day).=20 > Those timers ensure that TCP doesn=E2=80=99t lock up, by retransmitting un= -ACKed > data and control(SYN,FIN) packets. ACK only packets are never retransmitt= ed. What about keepalives? > The delayed ACK timer isn=E2=80=99t part of the reliability of TCP, it is a= > performance improvement that allows consolidation of ACKs. ACKs could > always be sent immediately in response to the incoming packet instead > of being delayed by a timer. >=20 > -David >=20 >>=20 >> Joe >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Sun Nov 2 15:33: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 811C01A1B49 for ; Sun, 2 Nov 2014 15:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 Qv2ncxvuYm8R for ; Sun, 2 Nov 2014 15:33:36 -0800 (PST) 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 561321A1B40 for ; Sun, 2 Nov 2014 15:33:35 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 65E8449E16A93; Sun, 2 Nov 2014 23:33:30 +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 sA2NXXVQ008816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Nov 2014 00:33:33 +0100 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, 3 Nov 2014 00:33:33 +0100 From: "Scharf, Michael (Michael)" To: Per Hurtig , "tcpm@ietf.org" Thread-Topic: draft-ietf-tcpm-rtorestart-04 Thread-Index: AQHP9vVqrXJrvR/Ze0yRRPU/kEN2LQ== Date: Sun, 2 Nov 2014 23:33:32 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> <544ED2B8.4020208@kau.se> In-Reply-To: <544ED2B8.4020208@kau.se> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ym6Qj2a_-9T2izlQR4BbRDh7gM0 Subject: [tcpm] draft-ietf-tcpm-rtorestart-04 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, 02 Nov 2014 23:33:38 -0000 Hi, I've read -04 and I have a couple of questions and suggestions: * Section 4: The "total number of outstanding and previously unsent segment= s" in sum of two variables, right? If so, why not use the term "sum"? * Section 4: I also wonder if the text should define "previously unsent seg= ments". The term "previously unsent data" is very well-known in the RFC ser= ies. A quick search revealed that "previously unsent segments" is usually o= nly used to refer to situations when segments with this property have indee= d been transmitted. Is my understanding correct that draft-ietf-tcpm-rtores= tart-04 uses this term differently? I think it here refers to data that wil= l be sent *in future*. In that case, I wonder if it is really clear how the= sender can determine the number of "previously unsent segments". For insta= nce, that number may depend on the segmentation strategy of the sender, in = particular for applications that use many small write() calls. In this case= a TCP stack may e.g. decide to send partial segments. I am not sure if the= actual number of segments created from the "unsent data" is really known i= n advance always. Or do I miss something? * Section 5.1: "Given RTOR's ability to only work when it is beneficial for= the loss recovery process, it is suitable as a system-wide default mechani= sm for TCP traffic." I think other text in the draft asks for further exper= imentation regarding the actual trade-off between benefit and risk. Given t= hat, I think another wording should be used (e.g., "Given that RTOR is a mo= stly conservative algorithm", ...). Given that this is not a PS document, I= 'd also prefer a more careful phrasing regarding the recommendation as syst= em-wide default (e.g., "it is suitable for experimentation as system-wide d= efault"). * Section 5.2: As mentioned in the last face-to-face meeting, spurious time= out negatively affect the network by needlessly sending data. This negative= effect is not mentioned in this section. Why? * Section 5.2: Mobile networks have a variable RTT, including e.g. longer d= elays during handovers (either without or with transient loss during the ha= ndover). A lot of past work on spurious timeout recovery has been motivated= by these delay spikes. Reducing the RTO almost certainly has an impact in = such environments; I think performance can both increase or decrease. If no= data on that is available, mobile networks seem to me an area where more e= xperimentation would be particularly useful, right? * Section 5.2: Is there any data on the risk of spurious timeouts in networ= ks where RTT and the minimum RTO are of the same order of magnitude? For in= stance, in satellite networks the RTT can be huge. * Section 5.2: "However, with respect to RTOR spurious timeouts are only a = problem for applications transmitting multiple bursts of data within a sing= le flow." I think this section should be reworded and it should more explic= itly discuss the impact of RTOR on HTTP/1.1 and HTTP/2.0 traffic, including= e.g. adaptive video streaming. They all transmit "multiple bursts of data = within a single flow". To me, the current sentence could imply that RTOR wo= uld be a "problem" for a vast majority of Internet traffic. A more explicit= discussion on how RTOR affects HTTP/1.1 and HTTP/2.0 would IMHO make a lot= of sense. * Section 5.3: Given that not all stacks are segment-based, this section se= ems really relevant. However, the description how to determine outstanding = segments is vague ("it is possible to exactly determine..."). I think this = could be reworded to provide more guidance to implementers. The same applie= s to the calculation of "previously unsent segments"; for instance, the tex= t does not explain what happens if the "number of bytes in the send queue" = is not a multiple of the SMSS (see also above regarding the definition of t= his variable). * Section 6: "In contrast, RTOR is trying to make the RTO more appropriate = in cases where there is no need to be overly cautious." I think this senten= ce should use a more neutral language. I think whether an RTO value is "app= ropriate" is impossible to know (in advance), and whether a more aggressive= timeout is "cautious" or not may depend on the network under consideration= . For instance, an alternative would be to compare the complexity of RTOR a= nd TLP. * Section 9: I wonder if an attacker could try to send certain ACK patterns= to increase the risk of timeouts e.g. at a Web Server, leveraging the smal= ler RTO value. If successful, the RTOs could significantly reduce applicati= on performance. Probably, such an attacker could cause much more harm by ot= her means, i.e., this may not be a significant security risk. But the curre= nt security analysis is very short. Thanks Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Per Hurtig > Sent: Tuesday, October 28, 2014 12:18 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-04.txt >=20 > Hi all, >=20 > we have now updated the draft to address the outstanding comments. The > main changes from last version are: >=20 > 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" <=3D 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. >=20 >=20 > for experimental results and a Linux implementation, please visit: > http://riteproject.eu/resources/rto-restart/ >=20 >=20 >=20 > Cheers, > Per >=20 > 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=3Ddraft-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 > > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Nov 3 15:12: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 BC33A1A8851 for ; Mon, 3 Nov 2014 15:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 lZn30YJnVeM1 for ; Mon, 3 Nov 2014 15:12:27 -0800 (PST) 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 738861A8850 for ; Mon, 3 Nov 2014 15:12:22 -0800 (PST) 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; Tue, 4 Nov 2014 03:28:34 +0000 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, 3 Nov 2014 23:12:19 +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, 3 Nov 2014 23:12:19 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sA3NCFEo018381; Mon, 3 Nov 2014 23:12:15 GMT Message-ID: <201411032312.sA3NCFEo018381@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 3 Nov 2014 23:12:14 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <5446C9FB.7050006@isi.edu> 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> 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/rJNl1dd2_oT8xhILQx1MV3go6Bo Cc: David Borman , "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, 03 Nov 2014 23:12:36 -0000 Joe, A 4WHS RFC could specify precisely how any=20 existing TCP option would be negotiated within a=20 4WHS (ie it would update a number of TCP option RFCs all at once). Then, if/when 4WHS was implemented, any necessary=20 changes to the negotiation code for each TCP=20 option could be included in the same release as the update to the 4WHS. You both stated that each TCP option spec defines=20 its own negotiation logic, and that there is no=20 general negotiation rule. But the talking at=20 cross-purposes seemed to go on for dozens of=20 rounds despite this. It seemed to end without any=20 apparent reconciliation - perhaps your keyboards=20 burned out? So I thought the above points might still be useful. In David's latest update=20 he has added a=20 roster of all the existing TCP options and how=20 they are negotiated. This could easily be updated=20 to say how any that need to be changed MUST be negotiated if a 4WHS were= used. Bob At 21:02 21/10/2014, Joe Touch wrote: >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=E2=80=99t 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=20 > 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=20 > 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=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? > >> > >> 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. > >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 > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT =20 From nobody Mon Nov 3 15:16: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 1BFFD1A8853 for ; Mon, 3 Nov 2014 15:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 zS2aREmDk3zg for ; Mon, 3 Nov 2014 15:16:10 -0800 (PST) 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 B79501A8860 for ; Mon, 3 Nov 2014 15:16:09 -0800 (PST) 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; Mon, 3 Nov 2014 23:16:26 +0000 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; Mon, 3 Nov 2014 23:16:06 +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, 3 Nov 2014 23:16:00 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sA3NFxZU018392; Mon, 3 Nov 2014 23:15:59 GMT Message-ID: <201411032315.sA3NFxZU018392@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 3 Nov 2014 23:15:57 +0000 To: Joe Touch 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/31WY4HwdtpY4hsBxNGEU4pNvLmM Cc: tcpm IETF list Subject: [tcpm] Firewall rules and OOB 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, 03 Nov 2014 23:16:12 -0000 Joe, If the OOB segment arrives at a firewall before the SYN, the firewall is nearly certain to drop the OOB segment as a non-SYN packet that is not part of a connection opened earlier by a SYN. Even if OOB arrives second, the following conversation implies some firewall admins will have included a rule to drop it: Search for: "ACK must exist in existing/related connections." "At least one flag must be set (cannot have none set)." "A NULL packet is something you should never see" I know we have to do traversal experiments, but I found this forum while looking for something else. Bob ________________________________________________________________ Bob Briscoe, BT From nobody Mon Nov 3 15:22: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 3C4351A8851 for ; Mon, 3 Nov 2014 15:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 qNhq15qgoSeP for ; Mon, 3 Nov 2014 15:22:03 -0800 (PST) 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 66F131A8827 for ; Mon, 3 Nov 2014 15:22:01 -0800 (PST) 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, 4 Nov 2014 03:39:36 +0000 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, 3 Nov 2014 23:21:59 +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, 3 Nov 2014 23:21:59 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sA3NLu9p018412; Mon, 3 Nov 2014 23:21:57 GMT Message-ID: <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 3 Nov 2014 23:21:55 +0000 To: David Borman From: Bob Briscoe In-Reply-To: <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_877202264==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ysuDppCOH8liaAk17LMBROo2_vQ Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Mon, 03 Nov 2014 23:22:07 -0000 --=====================_877202264==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable David, Thx for updating the draft & filename, and=20 particularly for the adding the roster of=20 existing TCP options. However, to be honest, I=20 think tcp4way has got caught up in following a=20 false trail. Let me explain, and I'll add other critique afterwards too. 1) Following a false trail? Tcp4way aims to give the client a second chance=20 to negotiate some more TCP options on a=20 subsequent SYN/ACK. The original reason you=20 wanted this (from emails back in the summer) was=20 because it would be really complex to allow a=20 second segment from the client to negotiate more=20 options if the hosts had already made an interim=20 decision after the first round. They might need=20 to revoke some of their earlier decisions, which=20 would be extremely complex and often impossible. However, all that tcp4way has achieved is to send=20 more segments before making a decision. That=20 means more segments on which TCP options cannot be /used/ yet. I've calculated how many segments in both=20 directions before a 4WHS server enters the established state: * Without TFO: 3 segments, including 2 that could carry data * A resumed connection with TFO & IW=3D3: 7 segments, all potentially with= data. * A resumed connection with TFO & IW=3D10: 21=20 segments, all potentially with data. So all tcp4way achieves is to prevent TCP options=20 being included on more segments. I believe it was wrong to conclude (back in the=20 summer) that the problem is all about holding=20 back a move to the established state. Most=20 existing TCP options apply to segments of any=20 kind, irrespective of whether the host is in the=20 established state when it sends them, and=20 irrespective of whether they even carry data. In all the following examples, if the client=20 wants to support option X and the server can=20 support X, the server would ideally like to start=20 using X on the first SYN/ACK, whether or not the=20 client is offering to delay moving into the established state for a round: * TCP-AO * The following sub-options of the tcpcrypt CRYPT=20 option: DECLINE, PKCONF*, NEXTK1*, NEXTK2*,=20 INIT1, INIT2, UNKNOWN, SYNCOOOKIE, ACKCOOKIE, REKEY, REKEYSTREAM. * the tcpcrypt MAC option * MPTCP_JOIN, ADD_ADDR(2), DSS, MP_PRIO, MP_FAIL * SACK permitted * MSS * TFO * TS (if used for RTT calculation) * UTO The only ones that are meaningless on the first SYN/ACK are: * SACK (because the SACK block for zero previous=20 ACKs would be pretty uninteresting. However SACK=20 would be useful on ACKs from the client while still in SYN-RCVD) * TS (if used for PAWS, 'cos there's no risk of wrap on the first few= segments) * WS (The client can't use a large RWND until it=20 has opened up cwnd thru a few rounds of=20 slow-start. However, this is arguable, because=20 there might be occasions where a connection can safely inherit a large= cwnd). Some option are only meaningful once data has=20 started (e.g. UTO, MPTCP-DSS, WS), but even those=20 can be used prior to connection establishment. We can't know which of these two lists=20 yet-to-be-defined new options will be in. If the=20 past is a good predictor of the future, the first=20 list is more likely (ie. the ones tcp4way doesn't help much). 2) Latency Tcp4way always introduces latency. How much depends on which scenario: * TCP client sends request first (by far the majority of connections): 1 RTT * TCP server sends data first (e.g. resuming a push connection): 0.5 RTT As JohnL said, "any added latency is nearly=20 fatal". I strongly agree with every word, except "nearly". 3) Firewalls & Intrusion Detection Systems Outgoing SYN/ACK: To a firewall protecting a private network, an=20 outgoing SYN/ACK is as abnormal as an incoming=20 SYN. I guess most firewalls will not have a rule=20 blocking an outgoing SYN/ACK. But given it's=20 abnormal, I'm sure some IDSs will block it. 4W Reserved flag: I suspect some firewalls / IDSs might drop=20 packets with a Reserved flag set. I suspect we'll=20 see a fair amount of 'correction' of Reserved flags back to zero too. I appreciate that the 4W flag isn't crucial to your scheme. But the second SYN/ACK is fundamental. Even if you don't use a Reserved flag, you've=20 still got to find something 'abnormal' to signal support for the 4WHS. I don't have data for Reserved flag discard or=20 normalisation. If tcp4way used a TCP option,=20 [Honda] reported %stripped options to the following port numbers: port 80: 14% port 443: 6% port 34343: 4%. I suspect a lot of the option stripping is due to=20 connection splitters, which won't set options=20 that they don't understand for the ongoing=20 connection. I'm sure they won't set unrecognised=20 Reserved flags either. So I suspect traversal=20 will be just as bad for Reserved flags as for options. It is particularly important for TCP options that=20 provide security (e.g. TCP-AO, tcpcrypt) to aim=20 for 100% middlebox traversal. If attempts to use=20 security fail so often they become normal, it is=20 too easy for an attacker to target any connection=20 it wants to snoop or alter by stripping options=20 or flags, which just looks like yet another middlebox problem. I.e. when middlebox interference looks just like=20 a downgrade attack, it's really easy to make a=20 downgrade attack look like middlebox interference. __________________ They are my 3 main criticisms. The rest are nits... 4) Nit: Reflection of Reserved Flags Simple reflection of Reserved flags cannot be=20 used to confirm that the server agrees with the=20 client. There are TCP implementations that just=20 reflect whatever Reserved flags the client sends,=20 whether or not they support them. This is fairly easy to work-round. Similar to ECN=20 negotiation [RFC3168, Sec 6.1.1.2] you just=20 define the confirmation as a different pattern of=20 flags (but this burns more flags). Richard Scheffenegger was testing the Alexa top=20 1M Web servers in Apr with flags on SYN as follows: > CWR ECE SYN The correct response of ECN-capable servers was: < ECE SYN ACK I know he found a fair number (sorry I don't have=20 the %) that just dumbly reflected: < CWR ECE SYN ACK And when he set the nonce flag on a SYN sent to=20 these same broken Web servers, all of them just=20 dumbly reflected back the new pattern: > NS CWR ECE SYN < NS CWR ECE SYN ACK 5) Nit: Remembering EDO support across connections S.7.3.2.1 says that server EDO support can be=20 saved alongside a TFO cookie. I don't believe=20 this is safe. During an upgrade, there might be=20 some server replicas that support EDO and others=20 that don't. The legacy servers would then ignore=20 the EDO option, but still pass TCP options as a corrupt payload to the app. [BTW, it is safe for a client to hold solely the=20 TFO capability of a server in a cookie, because=20 (unlike EDO) TFO doesn't put data that is not=20 intended for the app in the payload. So, if a=20 replica server that picks up the resumed=20 connection does not support TFO, it will simply=20 ignore the cookie and just hold the data back until the 3WHS completes.] 6) Nit: Unknown Option Altho it would be nice to think that this might=20 help, there doesn't seem to be a case where it=20 will. Can you give an example where the Unknown Options is useful? 7) Nit: T/TCP is obsolete. T/TCP had vulnerabilities and was obsoleted by RFC6247. Bob At 16:21 24/10/2014, David Borman wrote: >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=20 >tcpm: draft-dborman-tcpm-tcp4way-00.txt > >2) I=E2=80=99ve added text that any implementation=20 >that indicates support for the Four-Way=20 >handshake is also indicating that it properly=20 >handles unknown TCP options, as per RFC=20 >1122. We keep dancing around that issue, and=20 >this gives us a way to stop worrying about it anymore, and >a way for an implementation to know for sure=20 >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=20 >clarify RFC 7323, that it is the presence of=20 >TSopt in both a sent and received packet with=20 >the SYN bit that enables the option, i.e. it is=20 >not limited to the specific instance of the=20 > and packets of the three-way handshake. > > >And something entirely new: > >5) I=E2=80=99ve added a new TCP option, the Unknown=20 >Option option. Currently, the primary way to=20 >determine that the other side of the connection=20 >doesn=E2=80=99t support a specific option is by lack=20 >of response to that option, because it silently=20 >ignores it. The Unknown Option option provides=20 >a mechanism where a TCP can inform the other=20 >side that it does not understand or support any=20 >given option for a connection. This can be very=20 >useful for sending TCP options in non-SYN=20 >packets, especially if the option is not=20 >explicitly enabled through the SYN exchange, or=20 >it is a one-way option. UTO comes to mind. > >The document needs more work, but I wanted to=20 >get an update out today, before Mondays submission cutoff. > > -David Borman > > > On Oct 24, 2014, at 11:01 AM, Internet-Drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the=20 > on-line Internet-Drafts directories. > > > > > > Title : TCP Four-Way Handshake > > Author : David Borman > > Filename : draft-borman-tcpm-tcp4way-00.txt > > Pages : 21 > > Date : 2014-10-24 > > > > 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. > > > > This memo presents a optional four-way TCP handshake to allow > > extended option space to be used in SYN packets in both directions. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-borman-tcpm-tcp4way/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-borman-tcpm-tcp4way-00 > > > > > > Please note that it may take a couple of=20 > 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/ > > > > _______________________________________________ > > 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 > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT=20 --=====================_877202264==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David,

Thx for updating the draft & filename, and particularly for the adding the roster of existing TCP options. However, to be honest, I think tcp4way has got caught up in following a false trail. Let me explain, and I'll add other critique afterwards too.

1) Following a false trail?

Tcp4way aims to give the client a second chance to negotiate some more TCP options on a subsequent SYN/ACK. The original reason you wanted this (from emails back in the summer) was because it would be really complex to allow a second segment from the client to negotiate more options if the hosts had already made an interim decision after the first round. They might need to revoke some of their earlier decisions, which would be extremely complex and often impossible.

However, all that tcp4way has achieved is to send more segments before making a decision. That means more segments on which TCP options cannot be /used/ yet.

I've calculated how many segments in both directions before a 4WHS server enters the established state:
* Without TFO: 3 segments, including 2 that could carry data
* A resumed connection with TFO & IW=3D3: 7 segments, all potentially with data.
* A resumed connection with TFO & IW=3D10: 21 segments, all potentially with data.

So all tcp4way achieves is to prevent TCP options being included on more segments.

I believe it was wrong to conclude (back in the summer) that the problem is all about holding back a move to the established state. Most existing TCP options apply to segments of any kind, irrespective of whether the host is in the established state when it sends them, and irrespective of whether they even carry data.

In all the following examples, if the client wants to support option X and the server can support X, the server would ideally like to start using X on the first SYN/ACK, whether or not the client is offering to delay moving into the established state for a round:
* TCP-AO
* The following sub-options of the tcpcrypt CRYPT option: DECLINE, PKCONF*, NEXTK1*, NEXTK2*, INIT1, INIT2, UNKNOWN, SYNCOOOKIE, ACKCOOKIE, REKEY, REKEYSTREAM.
* the tcpcrypt MAC option
* MPTCP_JOIN, ADD_ADDR(2), DSS, MP_PRIO, MP_FAIL
* SACK permitted
* MSS
* TFO
* TS (if used for RTT calculation)
* UTO

The only ones that are meaningless on the first SYN/ACK are:
* SACK (because the SACK block for zero previous ACKs would be pretty uninteresting. However SACK would be useful on ACKs from the client while still in SYN-RCVD)
* TS (if used for PAWS, 'cos there's no risk of wrap on the first few segments)
* WS (The client can't use a large RWND until it has opened up cwnd thru a few rounds of slow-start. However, this is arguable, because there might be occasions where a connection can safely inherit a large cwnd).

Some option are only meaningful once data has started (e.g. UTO, MPTCP-DSS, WS), but even those can be used prior to connection establishment.

We can't know which of these two lists yet-to-be-defined new options will be in. If the past is a good predictor of the future, the first list is more likely (ie. the ones tcp4way doesn't help much).

2) Latency

Tcp4way always introduces latency. How much depends on which scenario:
* TCP client sends request first (by far the majority of connections): 1 RTT
* TCP server sends data first (e.g. resuming a push connection): 0.5 RTT

As JohnL said, "any added latency is nearly fatal". I strongly agree with every word, except "nearly".

3) Firewalls & Intrusion Detection Systems

Outgoing SYN/ACK:
To a firewall protecting a private network, an outgoing SYN/ACK is as abnormal as an incoming SYN. I guess most firewalls will not have a rule blocking an outgoing SYN/ACK. But given it's abnormal, I'm sure some IDSs will block it.

4W Reserved flag:
I suspect some firewalls / IDSs might drop packets with a Reserved flag set. I suspect we'll see a fair amount of 'correction' of Reserved flags back to zero too.

I appreciate that the 4W flag isn't crucial to your scheme.
But the second SYN/ACK is fundamental.

Even if you don't use a Reserved flag, you've still got to find something 'abnormal' to signal support for the 4WHS.

I don't have data for Reserved flag discard or normalisation. If tcp4way used a TCP option, [Honda] reported %stripped options to the following port numbers:
 port 80: 14%
 port 443: 6%
 port 34343: 4%.
I suspect a lot of the option stripping is due to connection splitters, which won't set options that they don't understand for the ongoing connection. I'm sure they won't set unrecognised Reserved flags either. So I suspect traversal will be just as bad for Reserved flags as for options.

It is particularly important for TCP options that provide security (e.g. TCP-AO, tcpcrypt) to aim for 100% middlebox traversal. If attempts to use security fail so often they become normal, it is too easy for an attacker to target any connection it wants to snoop or alter by stripping options or flags, which just looks like yet another middlebox problem.

I.e. when middlebox interference looks just like a downgrade attack, it's really easy to make a downgrade attack look like middlebox interference.

__________________
They are my 3 main criticisms. The rest are nits...

4) Nit: Reflection of Reserved Flags

Simple reflection of Reserved flags cannot be used to confirm that the server agrees with the client. There are TCP implementations that just reflect whatever Reserved flags the client sends, whether or not they support them.

This is fairly easy to work-round. Similar to ECN negotiation [RFC3168, Sec 6.1.1.2] you just define the confirmation as a different pattern of flags (but this burns more flags).

Richard Scheffenegger was testing the Alexa top 1M Web servers in Apr with flags on SYN as follows:
        > CWR ECE SYN
The correct response of ECN-capable servers was:
         <     ECE SYN ACK
I know he found a fair number (sorry I don't have the %) that just dumbly reflected:
        < CWR ECE SYN ACK
And when he set the nonce flag on a SYN sent to these same broken Web servers, all of them just dumbly reflected back the new pattern:
        > NS CWR ECE SYN
        < NS CWR ECE SYN ACK

5) Nit: Remembering EDO support across connections

S.7.3.2.1 says that server EDO support can be saved alongside a TFO cookie. I don't believe this is safe. During an upgrade, there might be some server replicas that support EDO and others that don't. The legacy servers would then ignore the EDO option, but still pass TCP options as a corrupt payload to the app.

[BTW, it is safe for a client to hold solely the TFO capability of a server in a cookie, because (unlike EDO) TFO doesn't put data that is not intended for the app in the payload. So, if a replica server that picks up the resumed connection does not support TFO, it will simply ignore the cookie and just hold the data back until the 3WHS completes.]

6) Nit: Unknown Option

Altho it would be nice to think that this might help, there doesn't seem to be a case where it will. Can you give an example where the Unknown Options is useful?

7) Nit: T/TCP is obsolete.

T/TCP had vulnerabilities and was obsoleted by RFC6247.



Bob



At 16:21 24/10/2014, David Borman wrote:
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 fo= r 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 <SYN> and <SYN,ACK> 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:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : TCP Four-Way Handshake
>        Author          : David Borman
>        Filename        : draft-borman-tcpm-tcp4way-00.txt
>        Pages           : 21
>        Date            : 2014-10-24
>
> 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.
>
>   This memo presents a optional four-way TCP handshake to allow
>   extended option space to be used in SYN packets in both directions.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-borman-tcpm-tcp4way/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-borman-tcpm-tcp4way-00
>
>
> 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/
>
> _______________________________________________
> 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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_877202264==.ALT-- From nobody Mon Nov 3 15:44: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 114FD1A1AAA for ; Mon, 3 Nov 2014 15:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 DnU9PwiEPrBT for ; Mon, 3 Nov 2014 15:43:59 -0800 (PST) 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 5C3441A1A9D for ; Mon, 3 Nov 2014 15:43:57 -0800 (PST) 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, 4 Nov 2014 04:01:32 +0000 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; Mon, 3 Nov 2014 23:43:55 +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, 3 Nov 2014 23:43:54 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sA3NhoGo018452; Mon, 3 Nov 2014 23:43:52 GMT Message-ID: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 3 Nov 2014 23:43:50 +0000 To: Yoshifumi Nishida From: Bob Briscoe In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_878517087==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/76quBoPN7qE-4yQgX9OOJR5wkBk Cc: David Borman , "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, 03 Nov 2014 23:44:03 -0000 --=====================_878517087==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Yoshifumi, I've just sent a critique of tcp4way to David &=20 the list. I've pointed out problems with many of=20 the things you say you like about it inline below... At 04:34 22/10/2014, Yoshifumi Nishida wrote: >Hi David, > >(as an individual of course..) >I personally like this idea from the following reasons. > >1: use SYN-ACK to initiate feature negotiation=20 >(as discussed in the previous thread) tcp4way just seems to prevent use of TCP options=20 on more segments (and for more rounds). >2: it can expand SYN options space to 80 octets=20 >without overriding DO field. It might be more middlebox friendly. I agree that if options are going to be placed=20 beyond DO, and /if/ the signal that says they are=20 there could be stripped or normalised by=20 middleboxes, it is important that the signal that=20 says they are there is ultra-safe - checked and=20 double-checked for middlebox interference. However, deferring the point at which a=20 connection moves to the established state doesn't=20 suddenly mean that the segments sent before this didn't need any TCP= options. Also: * Some IDSs and perhaps some stateful firewalls=20 might not like the abnormal extra SYN/ACK. * The segments have to be abnormal (e.g. 4W flag=20 or a TCP option) in order to signal 4WHS support.=20 Your [Honda] study found option stripping was far=20 from a minor effect, probably due to split=20 connections - a split connection would also strip a Reserved flag. >3: we might be able to re-design syn cookie=20 >solution that can address the previous issues. What previous issues? >4: even if an option in SYN/ACK has been removed=20 >by middleboxes, it can reliably find this situation. So can any solution that is prepared to add as much latency as the 4WHS. >5: in mptcp, initiating subflow requires 4=20 >packet exchanges. With 4-way handshake=20 >mechanism, we might be able to do this with non-mptcp-specific way.=C2 There seems little point in doing a 4-way=20 exchange in a non-mptcp-specific way if it still=20 has the same latency problem. There is certainly=20 little point if another solution is available=20 that adds no latency and traverses middleboxes. >6: similar to 5, it might be useful some secure=20 >negotiations where we don't want to put=20 >something that requires computations in SYN, but=20 >want to perform some cryptic algorithms in later packet exchanges. Any specific TCP security option can always=20 require that computation is deferred, without=20 making a 4WHS the /only/ way to extend option space for all TCP options. Nonetheless, I do appreciate you posting your=20 views as an individual, so that we can have a discussion about these points. Cheers Bob >(as one of co-chairs..) > >When you submit new version, please include=20 >-tcpm- in the draft's name so that we can track it easily. > >Regards, >-- >Yoshi At 04:34 22/10/2014, Yoshifumi Nishida wrote: >Hi David, > >(as an individual of course..) >I personally like this idea from the following reasons. > >1: use SYN-ACK to initiate feature negotiation=20 >(as discussed in the previous thread) > >2: it can expand SYN options space to 80 octets=20 >without overriding DO field. It might be more middlebox friendly. > >3: we might be able to re-design syn cookie=20 >solution that can address the previous issues. > >4: even if an option in SYN/ACK has been removed=20 >by middleboxes, it can reliably find this situation. > >5: in mptcp, initiating subflow requires 4=20 >packet exchanges. With 4-way handshake=20 >mechanism, we might be able to do this with non-mptcp-specific way.=C2 > >6: similar to 5, it might be useful some secure=20 >negotiations where we don't want to put=20 >something that requires computations in SYN, but=20 >want to perform some cryptic algorithms in later packet exchanges. > > >(as one of co-chairs..) > >When you submit new version, please include=20 >-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=20 ><dab@weston.borman.com> wrote: >Hi, > >I=E2=80=99ve just posted draft-borman-tcp4way-00.txt,=20 >which describes a 4-Way TCP handshake that is=20 >intended to allow the TCP EDO option to be used=20 >during the initial SYN exchange.=C2 This was=20 >mentioned during the TCPM WG at the last IETF=20 >meeting.=C2 Please see the draft for more details. > >=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 -David Borman >_______________________________________________ >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 ________________________________________________________________ Bob Briscoe, BT=20 --=====================_878517087==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yoshifumi,

I've just sent a critique of tcp4way to David & the list. I've pointed out problems with many of the things you say you like about it inline below...

At 04:34 22/10/2014, Yoshifumi Nishida wrote:

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)

tcp4way just seems to prevent use of TCP options on more segments (and for more rounds).


2: it can expand SYN options space to 80 octets without overriding DO field. It might be more middlebox friendly.

I agree that if options are going to be placed beyond DO, and /if/ the signal that says they are there could be stripped or normalised by middleboxes, it is important that the signal that says they are there is ultra-safe - checked and double-checked for middlebox interference.

However, deferring the point at which a connection moves to the established state doesn't suddenly mean that the segments sent before this didn't need any TCP options.

Also:
* Some IDSs and perhaps some stateful firewalls might not like the abnormal extra SYN/ACK.
* The segments have to be abnormal (e.g. 4W flag or a TCP option) in order to signal 4WHS support. Your [Honda] study found option stripping was far from a minor effect, probably due to split connections - a split connection would also strip a Reserved flag.


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

What previous issues?


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

So can any solution that is prepared to add as much latency as the 4WHS.


5: in mptcp, initiating subfl= ow requires 4 packet exchanges. With 4-way handshake mechanism, we might be able to do this with non-mptcp-specific way.=C2

There seems little point in doing a 4-way exchange in a non-mptcp-specific way if it still has the same latency problem. There is certainly little point if another solution is available that adds no latency and traverses middleboxes.


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.

Any specific TCP security option can always require that computation is deferred, without making a 4WHS the /only/ way to extend option space for all TCP options.


Nonetheless, I do appreciate you posting your views as an individual, so that we can have a discussion about these points.

Cheers




Bob



(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

At 04:34 22/10/2014, Yoshifumi Nishida wrote:
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.=C2

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 <dab@weston.borman.com> 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.=C2  This was mentioned during the TCPM WG at the last IETF meeting.=C2  Please see the draft for more details.

=C2  =C2  =C2  =C2  =C2  =C2  =C2  = =C2  =C2  =C2  =C2  =C2  -David Borman
_______________________________________________
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

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_878517087==.ALT-- From nobody Mon Nov 3 16:22: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 4CCDC1A1AF2 for ; Mon, 3 Nov 2014 16:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 4xrOFamXZfrF for ; Mon, 3 Nov 2014 16:22:50 -0800 (PST) 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 EDD7E1A1AFB for ; Mon, 3 Nov 2014 16:22:49 -0800 (PST) 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 sA40MTFA014624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Nov 2014 16:22:29 -0800 (PST) Message-ID: <54581C45.7070109@isi.edu> Date: Mon, 03 Nov 2014 16:22:29 -0800 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: <201411032315.sA3NFxZU018392@bagheera.jungle.bt.co.uk> In-Reply-To: <201411032315.sA3NFxZU018392@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/nQ2IeLTeX9Pg7L10zWhdqOGMRSU Cc: tcpm IETF list Subject: Re: [tcpm] Firewall rules and OOB 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, 04 Nov 2014 00:22:51 -0000 On 11/3/2014 3:15 PM, Bob Briscoe wrote: > Joe, > > If the OOB segment arrives at a firewall before the SYN, the firewall is > nearly certain to drop the OOB segment as a non-SYN packet that is not > part of a connection opened earlier by a SYN. Yes, as with any such segment. > Even if OOB arrives second, the following conversation implies some > firewall admins will have included a rule to drop it: > That depends on whether they implement those rules, or that's just "how they understand it". And, if those rules are accurate, there are lots of other valid packets that are not permitted either (e.g., SYN with URG, PSH). > Search for: > "ACK must exist in existing/related connections." > "At least one flag must be set (cannot have none set)." > "A NULL packet is something you should never see" > > I know we have to do traversal experiments, but I found this forum while > looking for something else. Agreed, but as you note it's just one forum. This is a great example of why NAT behavior must be modeled correctly, not just derived from blind rules. Joe From nobody Mon Nov 3 16:25: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 7DE511A1B04 for ; Mon, 3 Nov 2014 16:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 QiWYkbl_E5zf for ; Mon, 3 Nov 2014 16:25:02 -0800 (PST) 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 913C51A1AF4 for ; Mon, 3 Nov 2014 16:25:02 -0800 (PST) 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 sA40O40o015187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Nov 2014 16:24:04 -0800 (PST) Message-ID: <54581CA3.9040604@isi.edu> Date: Mon, 03 Nov 2014 16:24:03 -0800 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: <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> <201411032312.sA3NCFEo018381@bagheera.jungle.bt.co.uk> In-Reply-To: <201411032312.sA3NCFEo018381@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/G7d0GSSls0yXeoDOS6M_yh3ehkQ Cc: David Borman , "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, 04 Nov 2014 00:25:03 -0000 On 11/3/2014 3:12 PM, Bob Briscoe wrote: > Joe, > > A 4WHS RFC could specify precisely how any existing TCP option would be > negotiated within a 4WHS (ie it would update a number of TCP option RFCs > all at once). > > Then, if/when 4WHS was implemented, any necessary changes to the > negotiation code for each TCP option could be included in the same > release as the update to the 4WHS. Yes, but it might limit how such options can be negotiated. That's the sense in which neither I nor Dave wants to have 4WHS include such limits. Joe From nobody Tue Nov 4 01:10: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 11EFE1A891D for ; Tue, 4 Nov 2014 01:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 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.594, 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 EoSlajfyB7xg for ; Tue, 4 Nov 2014 01:10:10 -0800 (PST) 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 5AC121A1B86 for ; Tue, 4 Nov 2014 01:10:09 -0800 (PST) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8958729C003 for ; Tue, 4 Nov 2014 18:10:05 +0900 (JST) Received: by mail-qg0-f46.google.com with SMTP id i50so9038341qgf.19 for ; Tue, 04 Nov 2014 01:09:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.85.116 with SMTP id m107mr69186871qgd.93.1415092197965; Tue, 04 Nov 2014 01:09:57 -0800 (PST) Received: by 10.96.195.106 with HTTP; Tue, 4 Nov 2014 01:09:57 -0800 (PST) In-Reply-To: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> References: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> Date: Tue, 4 Nov 2014 01:09:57 -0800 Message-ID: From: Yoshifumi Nishida To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a11c123dec8dac6050704d325 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dxSHP0PvaLeZNKp-Ezg-JcWXEtI Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" , David Borman 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, 04 Nov 2014 09:10:15 -0000 --001a11c123dec8dac6050704d325 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On Mon, Nov 3, 2014 at 3:43 PM, Bob Briscoe wrote: > Yoshifumi, > > I've just sent a critique of tcp4way to David & the list. I've pointed ou= t > problems with many of the things you say you like about it inline below..= . > > At 04:34 22/10/2014, Yoshifumi Nishida wrote: > > 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) > > > tcp4way just seems to prevent use of TCP options on more segments (and fo= r > more rounds). > Hmm. Sorry, I'm not very sure if I understand this. > 2: it can expand SYN options space to 80 octets without overriding DO > field. It might be more middlebox friendly. > > > I agree that if options are going to be placed beyond DO, and /if/ the > signal that says they are there could be stripped or normalised by > middleboxes, it is important that the signal that says they are there is > ultra-safe - checked and double-checked for middlebox interference. > > However, deferring the point at which a connection moves to the > established state doesn't suddenly mean that the segments sent before thi= s > didn't need any TCP options. > > Also: > * Some IDSs and perhaps some stateful firewalls might not like the > abnormal extra SYN/ACK. > * The segments have to be abnormal (e.g. 4W flag or a TCP option) in orde= r > to signal 4WHS support. Your [Honda] study found option stripping was far > from a minor effect, probably due to split connections - a split connecti= on > would also strip a Reserved flag. > Yep. You got a point and we know the discussions for middlebox is always tricky. I know this is not a very strong argument, but if we use payload as option space, we'll need extra mechanisms to avoid being parsed wrongly, which will increase complexity. > 3: we might be able to re-design syn cookie solution that can address the > previous issues. > > What previous issues? > In SYN cookie, tcp cannot use TCP options other than mss. Also, if the third ack is lost, the connection might be frozen because the server cannot retransmit SYN/ACK. > 4: even if an option in SYN/ACK has been removed by middleboxes, it can > reliably find this situation. > > > So can any solution that is prepared to add as much latency as the 4WHS. > Yep. maybe. but, not sure about complexity. > 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.=C3=82 > > > There seems little point in doing a 4-way exchange in a non-mptcp-specifi= c > way if it still has the same latency problem. There is certainly little > point if another solution is available that adds no latency and traverses > middleboxes. > Well, it may be a very tiny point, but, the third ACK can be pure ACK. So, in order to perform 4-way exchange, mptcp may need to violate a basic rule in TCP, which is "don't send ack for ack" I personally don't want to see this kind of adhoc logic if possible. > 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 t= o > perform some cryptic algorithms in later packet exchanges. > > > Any specific TCP security option can always require that computation is > deferred, without making a 4WHS the /only/ way to extend option space for > all TCP options. > Yep. again, you maybe right, but not sure about complexity. A problem in 3WHS is there's no good way to retransmit the third ACK. We might be able to solve it with additional logic, but at the same time, I would like to see something simpler. I think I'm focusing on complexity rather than latency. I'm not very sure if this is right or not, but I believe complexity is also an important factor. However, I cannot and don't want to say 4WHS is less complex than others for now, it will be required more detailed analysis and comparisons. I just intuitively thought it looks like that. I might be wrong. I just would like to say we need more analysis. Thanks, -- Yoshi --001a11c123dec8dac6050704d325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Bob,

On Mon, Nov 3, 2014 at 3:43 PM, Bob Briscoe &= lt;bob.briscoe@bt.c= om> wrote:
Yoshifumi,

I've just sent a critique of tcp4way to David & the list. I've pointed out problems with many of the things you say you like about it inline below...

At 04:34 22/10/2014, Yoshifumi Nishida wrote:
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)

 tcp4way just seems to prevent use of TCP options on more segments (and for more rounds).

Hmm. Sorry, I'm= not very sure if I understand this.=C2=A0
2: it can expand SYN options space to 80 octets without overriding DO field. It might be more middlebox friendly.

 I agree that if options are going to be placed beyond DO, and /if/ the signal that says they are there could be stripped or normalised by middleboxes, it is important that the signal that says they are there is ultra-safe - checked and double-checked for middlebox interference.

However, deferring the point at which a connection moves to the established state doesn't suddenly mean that the segments sent before this didn't need any TCP options.

Also:
* Some IDSs and perhaps some stateful firewalls might not like the abnormal extra SYN/ACK.
* The segments have to be abnormal (e.g. 4W flag or a TCP option) in order to signal 4WHS support. Your [Honda] study found option stripping was far from a minor effect, probably due to split connections - a split connection would also strip a Reserved flag.

Yep. You got a point and we know the discussions for middlebox is a= lways tricky.
I know this is not a very strong argument, but if w= e use payload as option space, we'll need extra mechanisms to avoid bei= ng parsed wrongly, which will increase complexity.=C2=A0
=C2=A0
3: we might be able to re-design syn cookie solution that can address the previous issues.
 What previous issues?

In SYN cookie, = tcp cannot use TCP options other than mss. Also, if the third ack is lost, = the connection might be frozen because the server cannot retransmit SYN/ACK= .
=C2=A0
4: even if an option in SYN/ACK has been removed by middleboxes, it can reliably find this situation.

So can any solution that is prepared to add as much latency as the 4WHS.

Yep. maybe. but, not sure a= bout complexity.
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.=C3=82

There seems little point in doing a 4-way exchange in a non-mptcp-specific way if it still has the same latency problem. There is certainly little point if another solution is available that adds no latency and traverses middleboxes.

We= ll, it may be a very tiny point, but, the third ACK can be pure ACK.=C2=A0<= /div>
So, in order to perform 4-way exchange, =C2=A0mptcp may need to v= iolate a basic rule in TCP, which is "don't send ack for ack"=
I personally don't want to see this kind of adhoc logic if p= ossible.
6: similar to 5, it might be useful some secure negotiations where we don't want to put something th= at requires computations in SYN, but want to perform some cryptic algorithms in later packet exchanges.

 Any specific TCP security option can always require that computation is deferred, without making a 4WHS the /only/ way to extend option space for all TCP options.

Yep. again, you = maybe right, but not sure about complexity.
A problem in 3WHS is = there's no good way to retransmit the third ACK.=C2=A0
We mig= ht be able to solve it with additional logic, but at the same time, I would= like to see something simpler.

I think I'm fo= cusing on complexity rather than latency.=C2=A0
I'm not very = sure if this is right or not, but I believe complexity is also an important= factor.=C2=A0

However, I cannot and don't wan= t to say 4WHS is less complex than others for now, it will be required more= detailed analysis and comparisons.
I just intuitively thought it= looks like that. I might be wrong. I just would like to say we need more a= nalysis.

Thanks,
--
Yoshi
--001a11c123dec8dac6050704d325-- From nobody Tue Nov 4 09:22: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 AD3211AC3A0 for ; Tue, 4 Nov 2014 09:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 aFip-T-fyw8O for ; Tue, 4 Nov 2014 09:22:01 -0800 (PST) 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 A5BD81A0BE8 for ; Tue, 4 Nov 2014 09:22:00 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 4 Nov 2014 17:21:58 +0000 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, 4 Nov 2014 17:21:57 +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, 4 Nov 2014 17:21:57 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.52.85]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sA4HLpr8022330; Tue, 4 Nov 2014 17:21:53 GMT Message-ID: <201411041721.sA4HLpr8022330@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 4 Nov 2014 16:52:21 +0000 To: Yoshifumi Nishida From: Bob Briscoe In-Reply-To: References: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_941999697==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lA7rrtMr9iBShKrWPqJ6DZZKJyE Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" , David Borman 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, 04 Nov 2014 17:22:05 -0000 --=====================_941999697==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Yoshifumi, At 09:09 04/11/2014, Yoshifumi Nishida wrote: >Hi Bob, > >On Mon, Nov 3, 2014 at 3:43 PM, Bob Briscoe=20 ><bob.briscoe@bt.com> wrote: >Yoshifumi, > >I've just sent a critique of tcp4way to David &=20 >the list. I've pointed out problems with many of=20 >the things you say you like about it inline below... > >At 04:34 22/10/2014, Yoshifumi Nishida wrote: >>Hi David, >> >>(as an individual of course..) >>I personally like this idea from the following reasons. >> >>1: use SYN-ACK to initiate feature negotiation=20 >>(as discussed in the previous thread) > >tcp4way just seems to prevent use of TCP options=20 >on more segments (and for more rounds). > > >Hmm. Sorry, I'm not very sure if I understand this.=C2 See email to Dave Borman yesterday. Look for my first point: "Following a false trail?" When you step back and think about it, tcp4way is=20 just confusing us into thinking it is doing=20 something useful, but I don't believe it is. >>2: it can expand SYN options space to 80 octets=20 >>without overriding DO field. It might be more middlebox friendly. > >I agree that if options are going to be placed=20 >beyond DO, and /if/ the signal that says they=20 >are there could be stripped or normalised by=20 >middleboxes, it is important that the signal=20 >that says they are there is ultra-safe - checked=20 >and double-checked for middlebox interference. > >However, deferring the point at which a=20 >connection moves to the established state=20 >doesn't suddenly mean that the segments sent=20 >before this didn't need any TCP options. > >Also: >* Some IDSs and perhaps some stateful firewalls=20 >might not like the abnormal extra SYN/ACK. >* The segments have to be abnormal (e.g. 4W flag=20 >or a TCP option) in order to signal 4WHS=20 >support. Your [Honda] study found option=20 >stripping was far from a minor effect, probably=20 >due to split connections - a split connection would also strip a Reserved= flag. > > >Yep. You got a point and we know the discussions=20 >for middlebox is always tricky. >I know this is not a very strong argument, but=20 >if we use payload as option space, we'll need=20 >extra mechanisms to avoid being parsed wrongly,=20 >which will increase complexity.=C2 EDO, tcp4way, EOS, Inner Space /all/ use payload=20 as option space, because if an option like EDO=20 that extends the header is stripped, the data=20 receiver thinks the data offset has reverted to=20 DO, so the place where the options had been placed becomes payload. I explained to Joe in the posting pasted below,=20 why there is a safety issue when header and=20 payload do not necessarily share the same fate. At 21:36 14/10/2014, Bob Briscoe wrote: >>[Inner Space] does not involve any additional=20 >>TCP options in the TCP option space, ie the=20 >>space between the end of the 20B base TCP=20 >>header and the max 60B Data Offset. This makes=20 >>each [Inner Space] segment /inherently/ robust against option stripping. >> >>All the additional options of [Inner Space] are=20 >>beyond the Data Offset, including the option=20 >>that creates the additional space for the other=20 >>options. So they all share the same fate. >> >>Whereas, in EDO the option that creates the=20 >>space beyond DO is not itself beyond DO. So the=20 >>option that creates the space is at risk of=20 >>being stripped without stripping the space it=20 >>created. The two do not /inherently/ share the same fate. >> >>Yes, checks can be added to EDO to check for=20 >>option stripping (e.g. deferring use of extra=20 >>space until after the SYN/ACK). But this has to=20 >>assume that stripping behaviour remains=20 >>consistent through the flow. Whereas, with=20 >>[Inner Space], each individual segment is=20 >>robust against option stripping, all by itself. This is why Joe has updated EDO to now require an=20 EDO option on every segment, even if no extra=20 option space is needed. Then if the receiver sees=20 the EDO option disappear at a certain point in=20 the connection, it knows that the payload could be corrupt. This is still not as inherently safe as Inner=20 Space. For instance segmentation offload might be=20 programmed to forward unrecognised options but it=20 still resegments the data. So if it blindly=20 forwarded EDO with resegmented data, the app would receive corrupt payload. >=C2 >>3: we might be able to re-design syn cookie=20 >>solution that can address the previous issues. >What previous issues? > > >In SYN cookie, tcp cannot use TCP options other=20 >than mss. Also, if the third ack is lost, the=20 >connection might be frozen because the server cannot retransmit SYN/ACK. OK. This is why I have published the EchoCookie=20 option separately. I originally had it within the=20 Inner Space draft, but it should be usable by any of the approaches. >=C2 >>4: even if an option in SYN/ACK has been=20 >>removed by middleboxes, it can reliably find this situation. > >So can any solution that is prepared to add as much latency as the 4WHS. > > >Yep. maybe. but, not sure about complexity. Lots of people can design simple solutions that=20 do not work. The task is surely to design the=20 simplest solution that does work. We need to=20 agree whether latency is part of the design brief. >>5: in mptcp, initiating subflow requires 4=20 >>packet exchanges. With 4-way handshake=20 >>mechanism, we might be able to do this with non-mptcp-specific way.=C3=82 > >There seems little point in doing a 4-way=20 >exchange in a non-mptcp-specific way if it still=20 >has the same latency problem. There is certainly=20 >little point if another solution is available=20 >that adds no latency and traverses middleboxes. > > >Well, it may be a very tiny point, but, the third ACK can be pure ACK.=C2 >So, in order to perform 4-way exchange, =C2 mptcp=20 >may need to violate a basic rule in TCP, which is "don't send ack for ack" >I personally don't want to see this kind of adhoc logic if possible. This is not a tiny point. It is important to try=20 to avoid ad hoc exceptions. I am having that=20 discussion with the tcpcrypt authors, concerning a MAC on a pure ACK. Because we /are/ changing basic stuff about TCP=20 here, we have to be prepared to change even=20 'basic' rules. However, if we do, we have to=20 replace them with equally universal new rules, not just ad hoc hacks. >>6: similar to 5, it might be useful some secure=20 >>negotiations where we don't want to put=20 >>something that requires computations in SYN,=20 >>but want to perform some cryptic algorithms in later packet exchanges. > >Any specific TCP security option can always=20 >require that computation is deferred, without=20 >making a 4WHS the /only/ way to extend option space for all TCP options. > > >Yep. again, you maybe right, but not sure about complexity. >A problem in 3WHS is there's no good way to retransmit the third ACK.=C2 >We might be able to solve it with additional=20 >logic, but at the same time, I would like to see something simpler. > >I think I'm focusing on complexity rather than latency.=C2 >I'm not very sure if this is right or not, but I=20 >believe complexity is also an important factor.=C2 > >However, I cannot and don't want to say 4WHS is=20 >less complex than others for now, it will be=20 >required more detailed analysis and comparisons. >I just intuitively thought it looks like that. I=20 >might be wrong. I just would like to say we need more analysis. Simplicity is very important, because otherwise bugs will appear. However, as I said, the task is to design the=20 simplest solution that works, not a simple solution that doesn't work. I am certain that a solution that adds latency=20 will not see any deployment - ie. it will not 'work'. I also want /one/ solution that /completely/ gets=20 rid of the complexity of middlebox traversal for=20 every other TCP option. It is false simplicity if=20 the middlebox problem is not solved when=20 providing extra option space. Then every TCP=20 option still has all the traversal complexity. Finally, I would caution against measuring the=20 complexity of a scheme by the number of pages of=20 the draft. For instance, the protocol spec in=20 inner-space-01 is only 12pp, because I have spent=20 a lot of effort simplifying the protocol design.=20 But the draft is 49pp, much of which is=20 justifying all the subtle aspects of what appears to be a simple design. Most authors don't explain their rationale in a=20 draft. They don't realise that other people might=20 not infer their intent from the design, then they=20 have to write the rationale repeatedly in=20 response to questions on mailing lists. I have posted a presentation about Inner Space that is a quick way to get= it: >Thanks, This is useful conversation - thank you Bob >-- >Yoshi ________________________________________________________________ Bob Briscoe, BT=20 --=====================_941999697==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yoshifumi,

At 09:09 04/11/2014, Yoshifumi Nishida wrote:
Hi Bob,

On Mon, Nov 3, 2014 at 3:43 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
Yoshifumi,

I've just sent a critique of tcp4way to David & the list. I've pointed out problems with many of the things you say you like about it inline below...

At 04:34 22/10/2014, Yoshifumi Nishida wrote:
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)

tcp4way just seems to prevent use of TCP options on more segments (and for more rounds).


Hmm. Sorry, I'm not very sure if I understand this.=C2

See email to Dave Borman yesterday.
< http://www.ietf.org/mail-archive/web/tcpm/current/msg09322.html >
Look for my first point: "Following a false trail?"
When you step back and think about it, tcp4way is just confusing us into thinking it is doing something useful, but I don't believe it is.

2: it can expand SYN options space to 80 octets without overriding DO field. It might be more middlebox friendly.

I agree that if options are going to be placed beyond DO, and /if/ the signal that says they are there could be stripped or normalised by middleboxes, it is important that the signal that says they are there is ultra-safe - checked and double-checked for middlebox interference.

However, deferring the point at which a connection moves to the established state doesn't suddenly mean that the segments sent before this didn't need any TCP options.

Also:
* Some IDSs and perhaps some stateful firewalls might not like the abnormal extra SYN/ACK.
* The segments have to be abnormal (e.g. 4W flag or a TCP option) in order to signal 4WHS support. Your [Honda] study found option stripping was far from a minor effect, probably due to split connections - a split connection would also strip a Reserved flag.


Yep. You got a point and we know the discussions for middlebox is always tricky.
I know this is not a very strong argument, but if we use payload as option space, we'll need extra mechanisms to avoid being parsed wrongly, which will increase complexity.=C2

EDO, tcp4way, EOS, Inner Space /all/ use payload as option space, because if an option like EDO that extends the header is stripped, the data receiver thinks the data offset has reverted to DO, so the place where the options had been placed becomes payload.

I explained to Joe in the posting pasted below, why there is a safety issue when header and payload do not necessarily share the same fate.

At 21:36 14/10/2014, Bob Briscoe wrote:
[Inner Space] does not involv= e 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 [Inner Space] segment /inherently/ robust against option stripping.

All the additional options of [Inner Space] 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 [Inner Space], each individual segment is robust against option stripping, all by itself.

This is why Joe has updated EDO to now require an EDO option on every segment, even if no extra option space is needed. Then if the receiver sees the EDO option disappear at a certain point in the connection, it knows that the payload could be corrupt.

This is still not as inherently safe as Inner Space. For instance segmentation offload might be programmed to forward unrecognised options but it still resegments the data. So if it blindly forwarded EDO with resegmented data, the app would receive corrupt payload.

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


In SYN cookie, tcp cannot use TCP options other than mss. Also, if the third ack is lost, the connection might be frozen because the server cannot retransmit SYN/ACK.

OK. This is why I have published the EchoCookie option separately. I originally had it within the Inner Space draft, but it should be usable by any of the approaches.

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

So can any solution that is prepared to add as much latency as the 4WHS.


Yep. maybe. but, not sure about complexity.

Lots of people can design simple solutions that do not work. The task is surely to design the simplest solution that does work. We need to agree whether latency is part of the design brief.

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.=C3=82

There seems little point in doing a 4-way exchange in a non-mptcp-specific way if it still has the same latency problem. There is certainly little point if another solution is available that adds no latency and traverses middleboxes.


Well, it may be a very tiny point, but, the third ACK can be pure ACK.=C2
So, in order to perform 4-way exchange, =C2 mptcp may need to violate a basic rule in TCP, which is "don't send ack for ack"
I personally don't want to see this kind of adhoc logic if possible.

This is not a tiny point. It is important to try to avoid ad hoc exceptions. I am having that discussion with the tcpcrypt authors, concerning a MAC on a pure ACK.

Because we /are/ changing basic stuff about TCP here, we have to be prepared to change even 'basic' rules. However, if we do, we have to replace them with equally universal new rules, not just ad hoc hacks.

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.

Any specific TCP security option can always require that computation is deferred, without making a 4WHS the /only/ way to extend option space for all TCP options.


Yep. again, you maybe right, but not sure about complexity.
A problem in 3WHS is there's no good way to retransmit the third ACK.=C2
We might be able to solve it with additional logic, but at the same time, I would like to see something simpler.

I think I'm focusing on complexity rather than latency.=C2
I'm not very sure if this is right or not, but I believe complexity is also an important factor.=C2

However, I cannot and don't want to say 4WHS is less complex than others for now, it will be required more detailed analysis and comparisons.
I just intuitively thought it looks like that. I might be wrong. I just would like to say we need more analysis.

Simplicity is very important, because otherwise bugs will appear.
However, as I said, the task is to design the simplest solution that works, not a simple solution that doesn't work.

I am certain that a solution that adds latency will not see any deployment - ie. it will not 'work'.

I also want /one/ solution that /completely/ gets rid of the complexity of middlebox traversal for every other TCP option. It is false simplicity if the middlebox problem is not solved when providing extra option space. Then every TCP option still has all the traversal complexity.

Finally, I would caution against measuring the complexity of a scheme by the number of pages of the draft. For instance, the protocol spec in inner-space-01 is only 12pp, because I have spent a lot of effort simplifying the protocol design. But the draft is 49pp, much of which is justifying all the subtle aspects of what appears to be a simple design.

Most authors don't explain their rationale in a draft. They don't realise that other people might not infer their intent from the design, then they have to write the rationale repeatedly in response to questions on mailing lists.

I have posted a presentation about Inner Space that is a quick way to get it:
< http://www.bobbriscoe.net/present.html#1411inner-space>


Thanks,

This is useful conversation - thank you



Bob
--
Yoshi

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_941999697==.ALT-- From nobody Tue Nov 4 09:47: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 1A3841ACC8C for ; Tue, 4 Nov 2014 09:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 1mEikXTryRuw for ; Tue, 4 Nov 2014 09:46:59 -0800 (PST) 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 ECD191ACC8D for ; Tue, 4 Nov 2014 09:46:58 -0800 (PST) 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 sA4HkGKm003512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Nov 2014 09:46:17 -0800 (PST) Message-ID: <545910E8.40301@isi.edu> Date: Tue, 04 Nov 2014 09:46:16 -0800 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 , Yoshifumi Nishida References: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> <201411041721.sA4HLpr8022330@bagheera.jungle.bt.co.uk> In-Reply-To: <201411041721.sA4HLpr8022330@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/YMlSfw793xvaQwmMDFHE55wYfio Cc: David Borman , "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, 04 Nov 2014 17:47:00 -0000 On 11/4/2014 8:52 AM, Bob Briscoe wrote: ... > EDO, tcp4way, EOS, Inner Space /all/ use payload as option space, > because if an option like EDO that extends the header is stripped, the > data receiver thinks the data offset has reverted to DO, so the place > where the options had been placed becomes payload. > > I explained to Joe in the posting pasted below, why there is a safety > issue when header and payload do not necessarily share the same fate. That's also true for DO, FWIW. However, the issue of how the option is encoded is orthogonal to these solutions. Bob's in-band encoding would work in any of them, but also ends up "encoding TCP inside TCP", which can easily lead to escalation (as I've pointed out on the list already). For that reason, I don't support the idea of in-band encoding, but that's independent of the way in which the space itself is indicated and coordinated. ... > This is why Joe has updated EDO to now require an EDO option on every > segment, even if no extra option space is needed. Then if the receiver > sees the EDO option disappear at a certain point in the connection, it > knows that the payload could be corrupt. > > This is still not as inherently safe as Inner Space. And neither would be as safe as running encrypted TCP inside TCP. The question is whether we need to deal with this issue, i.e., whether such middlebox asymmetries can occur in practice. > ...We need to agree > whether latency is part of the design brief. +1 Joe From nobody Tue Nov 4 13:01: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 0A6F31A871C for ; Tue, 4 Nov 2014 13:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 lKqfVo6XQ5oo for ; Tue, 4 Nov 2014 13:01:43 -0800 (PST) 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 5092A1A8549 for ; Tue, 4 Nov 2014 13:01:43 -0800 (PST) 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 sA4L1b7l014358; Tue, 4 Nov 2014 15:01:37 -0600 (CST) 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: <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> Date: Tue, 4 Nov 2014 15:01:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <710F909D-62CE-426F-A868-0A7894137650@weston.borman.com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/PdulmU0dOuQAYXaAgP0HcW197wQ Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Tue, 04 Nov 2014 21:01:47 -0000 > On Nov 3, 2014, at 5:21 PM, Bob Briscoe wrote: >=20 > David,=20 >=20 > Thx for updating the draft & filename, and particularly for the adding = the roster of existing TCP options. However, to be honest, I think = tcp4way has got caught up in following a false trail. Let me explain, = and I'll add other critique afterwards too. >=20 > 1) Following a false trail? >=20 > Tcp4way aims to give the client a second chance to negotiate some more = TCP options on a subsequent SYN/ACK. The original reason you wanted this = (from emails back in the summer) was because it would be really complex = to allow a second segment from the client to negotiate more options if = the hosts had already made an interim decision after the first round. = They might need to revoke some of their earlier decisions, which would = be extremely complex and often impossible. No. My original point is that negotiating TCP options in packets = without the SYN bit requires additional complexity because ACK-only = packets are not reliably transmitted. The 4WHS adds a client SYN/ACK = packet that is reliably transmitted, and is distinct from the original = client SYN packet. For a non-directional option, it doesn=92t matter which side sends it = first, hence the server SYN/ACK can propose using additional = non-directional options, which can then be confirmed in the client = SYN/ACK of the 4WHS. Because both sides know that the other side supports extended option = space, both of the SYN/ACK packets can take advantage of it. > However, all that tcp4way has achieved is to send more segments before = making a decision. That means more segments on which TCP options cannot = be /used/ yet. Again, no. Options in the initial SYN and SYN/ACK are not delayed. = Nothing from the client side is delayed, because it decides the full set = of what is being used when it gets the servers SYN/ACK, because it knows = which options from the SYN were accepted by the server, and which = options proposed by the server it is willing to acknowledge when it = sends the SYN/ACK. It=92s the same point as with the 3WHS. The server won=92t know if the client supports the additional options = that the server proposed in the SYN/ACK until it gets the client=92s = SYN/ACK, so from the server standpoint, there=92s one more RTT for those = additional options. >=20 > I've calculated how many segments in both directions before a 4WHS = server enters the established state: > * Without TFO: 3 segments, including 2 that could carry data > * A resumed connection with TFO & IW=3D3: 7 segments, all potentially = with data. > * A resumed connection with TFO & IW=3D10: 21 segments, all = potentially with data. >=20 > So all tcp4way achieves is to prevent TCP options being included on = more segments. I don=92t follow this logic at all. With the 4WHS the server enters = established state at the exact same time as it does with the 3WHS, when = its SYN is acknowledged. Whether that is an ACK-only packet with a = 3WHS, or a SYN/ACK with a 4WHS, from the server side it still happens at = the same point in the exchange. =46rom the servers perspective, the = only difference is that for the 4WHS it sends a final ACK and does final = option enablement, and for the 3WHS it doesn=92t.=20 >=20 > I believe it was wrong to conclude (back in the summer) that the = problem is all about holding back a move to the established state. Most = existing TCP options apply to segments of any kind, irrespective of = whether the host is in the established state when it sends them, and = irrespective of whether they even carry data. I never said the problem was about holding back established state. I said that if the servers SYN/ACK contained additional options, with = the 4WHS the client can respond with a SYN/ACK to complete negotiation = of those additional options, whereas the 3WHS doesn=92t have that = possibility. And the only reason those options wouldn=92t have been in = the SYN is because there wasn=92t enough space, but with EDO there is = now space in the SYN/ACK. >=20 > In all the following examples, if the client wants to support option X = and the server can support X, the server would ideally like to start = using X on the first SYN/ACK, whether or not the client is offering to = delay moving into the established state for a round: If X was in the SYN, it can. If X wasn=92t in the SYN, it can=92t, = because it doesn=92t know that the client supports X, it=92ll have to = wait for the SYN/ACK to know if the client supports X. > * TCP-AO TCP-AO is not negotiated. > * The following sub-options of the tcpcrypt CRYPT option: DECLINE, = PKCONF*, NEXTK1*, NEXTK2*, INIT1, INIT2, UNKNOWN, SYNCOOOKIE, ACKCOOKIE, = REKEY, REKEYSTREAM. > * the tcpcrypt MAC option > * MPTCP_JOIN, ADD_ADDR(2), DSS, MP_PRIO, MP_FAIL > * SACK permitted > * MSS > * TFO=20 > * TS (if used for RTT calculation) > * UTO >=20 > The only ones that are meaningless on the first SYN/ACK are: > * SACK (because the SACK block for zero previous ACKs would be pretty = uninteresting. However SACK would be useful on ACKs from the client = while still in SYN-RCVD)=20 > * TS (if used for PAWS, 'cos there's no risk of wrap on the first few = segments) > * WS (The client can't use a large RWND until it has opened up cwnd = thru a few rounds of slow-start. However, this is arguable, because = there might be occasions where a connection can safely inherit a large = cwnd). >=20 > Some option are only meaningful once data has started (e.g. UTO, = MPTCP-DSS, WS), but even those can be used prior to connection = establishment. >=20 > We can't know which of these two lists yet-to-be-defined new options = will be in. If the past is a good predictor of the future, the first = list is more likely (ie. the ones tcp4way doesn't help much). I=92m not quite sure what your point is with just an enumerated list. = For each of them, the question is, if the option is not included in the = initial client SYN, can it make sense in the servers SYN/ACK? For = example, if a server doesn=92t receive TFO in the SYN, it could still = send TFO in the SYN/ACK, which would just be ignored by non-TFO = implementations. Directional options, where the servers option is = dependent on first knowing the contents of the clients option, are not = candidates. The 4WHS does not give the client a second chance to initiate option = negotiation, that would require a 5WHS. >=20 > 2) Latency >=20 > Tcp4way always introduces latency. How much depends on which scenario: > * TCP client sends request first (by far the majority of connections): = 1 RTT > * TCP server sends data first (e.g. resuming a push connection): 0.5 = RTT >=20 > As JohnL said, "any added latency is nearly fatal". I strongly agree = with every word, except "nearly=94. If you are talking about latency of delivering user data, there isn=92t = any. See my message entitled "We already support multiple versions of = the TCP header=94, and look for the section entitled =93Delivering User = Data=94. Those changes will be in the next revision of the 4WHS draft. > 3) Firewalls & Intrusion Detection Systems ... I don=92t subscribe to the notion that today=92s deployed middle boxes = get to dictate all future development of the TCP protocol. Yes, = ignoring them would be silly, but kowtowing to them is equally silly. We need to first decide on the destination, and then find a path to that = destination. If we just look at the paths through the middle boxes, = we=92ll still get somewhere, but will it be where we want to go? > __________________ > They are my 3 main criticisms. The rest are nits... >=20 > 4) Nit: Reflection of Reserved Flags ... Did you miss sections 4.3.2 and 4.3.3 where I discussed why this is not = an issue? > 5) Nit: Remembering EDO support across connections >=20 > S.7.3.2.1 says that server EDO support can be saved alongside a TFO = cookie. I don't believe this is safe. During an upgrade, there might be = some server replicas that support EDO and others that don't. The legacy = servers would then ignore the EDO option, but still pass TCP options as = a corrupt payload to the app. >=20 > [BTW, it is safe for a client to hold solely the TFO capability of a = server in a cookie, because (unlike EDO) TFO doesn't put data that is = not intended for the app in the payload. So, if a replica server that = picks up the resumed connection does not support TFO, it will simply = ignore the cookie and just hold the data back until the 3WHS completes.] Good points, I=92ll take that out. >=20 > 6) Nit: Unknown Option >=20 > Altho it would be nice to think that this might help, there doesn't = seem to be a case where it will. Can you give an example where the = Unknown Options is useful? I did, UTO. It would also be useful for late enablement of TS. = Basically, it is useful for using any option which does not require that = use of that option be negotiated in the initial SYN exchange. The main purpose of the Unknown Option option is to provide a generic = way to inform the other side that you don=92t understand a particular = option, when that option first appears mid-stream, rather than support = for that option being negotiated in the initial SYN exchange. = Otherwise, if you send an option for the first time mid-stream, the only = way to know that the other side doesn=92t support it is by lack of any = response to that option. That requires tracking what sequence number = you first sent it with, and waiting for the ACK for that sequence number = to decide on a non-response. But sequence number tracking doesn=92t = work if you don=92t have any new data to send, so you need another = mechanism. If you know the other side support the Unknown Option = option, then you know it=92ll tell you if you send any other options = that it doesn=92t understand.=20 > 7) Nit: T/TCP is obsolete. >=20 > T/TCP had vulnerabilities and was obsoleted by RFC6247. Yes, that=92s why the document says: Though now obsolete [RFC6247], this is a good example of a directional TCP option. > Bob -David= From nobody Tue Nov 4 17:15: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 E7BED1A1ACD for ; Tue, 4 Nov 2014 17:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 RDB3pbFqHpwK for ; Tue, 4 Nov 2014 17:15:47 -0800 (PST) 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 946311A1AD3 for ; Tue, 4 Nov 2014 17:15:47 -0800 (PST) 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 sA51Fgcn018700; Tue, 4 Nov 2014 19:15:42 -0600 (CST) 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: <710F909D-62CE-426F-A868-0A7894137650@weston.borman.com> Date: Tue, 4 Nov 2014 19:15:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> <710F909D-62CE-426F-A868-0A7894137650@weston.borman.com> To: Bob Briscoe X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xgWgBspe2ltgonXBOT4_KwK4pL8 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Wed, 05 Nov 2014 01:15:52 -0000 > On Nov 4, 2014, at 3:01 PM, David Borman = wrote: ... > I don=92t subscribe to the notion that today=92s deployed middle boxes = get to dictate all future development of the TCP protocol. Yes, = ignoring them would be silly, but kowtowing to them is equally silly. >=20 > We need to first decide on the destination, and then find a path to = that destination. If we just look at the paths through the middle = boxes, we=92ll still get somewhere, but will it be where we want to go? ... I re-read that, and I could be clearer. We need to first decide what we want TCP to look like, and then find a = way to transition from current implementations to the new design, which = might include middle boxes having to change, rather than letting current = middle box implementations dictate how we can or can=92t change TCP. -David From nobody Tue Nov 4 17:27: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 BA4B41A00B2 for ; Tue, 4 Nov 2014 17:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 9SDHpMax4URY for ; Tue, 4 Nov 2014 17:27:36 -0800 (PST) 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 8EBF01A1A13 for ; Tue, 4 Nov 2014 17:27:36 -0800 (PST) Received: from [192.168.1.17] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sA51QcTY020245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Nov 2014 17:27:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (12B411) In-Reply-To: Date: Tue, 4 Nov 2014 17:27:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4BB153DC-7763-48EC-A141-F41C470E881A@isi.edu> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> <710F909D-62CE-426F-A868-0A7894137650@weston.borman.com> To: David Borman 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/xyt27ttzWIiIGJ-vO32ez6RPXWg Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Wed, 05 Nov 2014 01:27:37 -0000 +1 > On Nov 4, 2014, at 5:15 PM, David Borman wrote: >=20 >=20 >>> On Nov 4, 2014, at 3:01 PM, David Borman wrote: >> ... >> I don=E2=80=99t subscribe to the notion that today=E2=80=99s deployed mid= dle boxes get to dictate all future development of the TCP protocol. Yes, i= gnoring them would be silly, but kowtowing to them is equally silly. >>=20 >> We need to first decide on the destination, and then find a path to that d= estination. If we just look at the paths through the middle boxes, we=E2=80= =99ll still get somewhere, but will it be where we want to go? > ... > I re-read that, and I could be clearer. >=20 > We need to first decide what we want TCP to look like, and then find a way= to transition from current implementations to the new design, which might i= nclude middle boxes having to change, rather than letting current middle box= implementations dictate how we can or can=E2=80=99t change TCP. >=20 > -David >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Nov 5 05:42: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 E20261A1A5F for ; Wed, 5 Nov 2014 05:42:14 -0800 (PST) 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, 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 BA8jxJ9HzQJc for ; Wed, 5 Nov 2014 05:42:13 -0800 (PST) Received: from kirsi2.inet.fi (mta-out1.inet.fi [62.71.2.227]) by ietfa.amsl.com (Postfix) with ESMTP id F2FC91A88F5 for ; Wed, 5 Nov 2014 05:42:12 -0800 (PST) Received: from t40700-la020.org.aalto.fi (130.233.145.183) by kirsi2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 541AB6BA006966B8 for tcpm@ietf.org; Wed, 5 Nov 2014 15:42:11 +0200 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: <11460_1414423987_544E65B2_11460_55_1_9B0DBAE7-5E40-40B3-9813-459B9DB77797@iki.fi> Date: Wed, 5 Nov 2014 15:42:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D7E4A00-4931-4F6B-A84F-590E529E9584@iki.fi> References: <11460_1414423987_544E65B2_11460_55_1_9B0DBAE7-5E40-40B3-9813-459B9DB77797@iki.fi> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/iQLZxpZGt1o7k9peJK8Pgch_bSI Subject: Re: [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: Wed, 05 Nov 2014 13:42:15 -0000 Hi, We have updated the TCPM agenda a bit. The current agenda is at = http://www.ietf.org/proceedings/91/agenda/agenda-91-tcpm Speakers: please send your slides by Sunday 15:00 Hawaii time. - Pasi From nobody Wed Nov 5 16:57: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 54EA11A1A4F for ; Wed, 5 Nov 2014 16:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.594] 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 89RUMFEh7SVs for ; Wed, 5 Nov 2014 16:57:08 -0800 (PST) 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 264281A1A47 for ; Wed, 5 Nov 2014 16:57:08 -0800 (PST) Received: from [128.9.184.229] ([128.9.184.229]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id sA60tqkg023828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Nov 2014 16:55:52 -0800 (PST) Message-ID: <545AC718.4010407@isi.edu> Date: Wed, 05 Nov 2014 16:55:52 -0800 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> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> In-Reply-To: <544F1E9F.3060108@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/Ax3GAUJu7ZSoMfkDHwi-6qHqPyk 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: Thu, 06 Nov 2014 00:57:09 -0000 Catching up... On 10/27/2014 9:42 PM, Wesley Eddy wrote: ... > 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. Let's be clear - we're ALL in the dark about any of these, both as to whether they will end up working or to what extent they would be over-engineered to get around phantoms that don't exist. > 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, You treat the OOB and SYN as a pair, and treat it with the same time-out on both ends as far as giving up or retransmitting. How long you keep queued copies to deal with reordering or other arrival-timing issues is up to the receiver. > but that could be > tweakable or algorithmically determined, so I don't think it's a major > issue. Yes, esp. for the caching part. Joe From nobody Wed Nov 5 23:24: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 0AEFF1A1A01 for ; Wed, 5 Nov 2014 23:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 FO21LhsTqDaL for ; Wed, 5 Nov 2014 23:24:49 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C23111A19ED for ; Wed, 5 Nov 2014 23:24:41 -0800 (PST) Received: from [IPv6:2001:470:26:9c2:922:204d:19e6:31e1] (unknown [IPv6:2001:470:26:9c2:922:204d:19e6:31e1]) by trammell.ch (Postfix) with ESMTPSA id 194FF1A049D; Thu, 6 Nov 2014 08:24:40 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Trammell In-Reply-To: <545AC718.4010407@isi.edu> Date: Thu, 6 Nov 2014 08:24:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/IR3lBy7_rSNIw67WvrXw99hcUjs Cc: tcpm IETF list Subject: [tcpm] on inline measurement was Re: 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: Thu, 06 Nov 2014 07:24:57 -0000 hi Joe, all, I'm *almost* caught up on this thread, but I did want jump in to = underline something that Joe said here: =20 > On 06 Nov 2014, at 01:55, Joe Touch wrote: >=20 > Catching up... >=20 > On 10/27/2014 9:42 PM, Wesley Eddy wrote: > ... >> 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.=20 >=20 > Let's be clear - we're ALL in the dark about any of these, both as to > whether they will end up working or to what extent they would be > over-engineered to get around phantoms that don't exist. +many. One of the reasons it's been difficult to follow this whole discussion = (beyond "I did not read email during the month of October") is that the = model of the middle/meddle/muddleboxes we're trying to defend against is = often implicit in the descriptions of the proposed mechanisms. Further, it's not clear to me the extent to which these implicit models = correspond to real-world devices, or to the extent that they do how = often they are deployed in such a way that they would lead to = reachability failure in the case of certain proposed extensions, or = header/payload invariance failure that would lead to failure modes in = those extensions. A middlebox that breaks a proposed extension mechanism = in impossible to debug ways but that appears on 1e-7 of the paths on the = Internet and is involved in 1e-14 flows falls into the category of = "acceptable risk". Further, even if we were arguing from explicit models backed up by = openly available data, it would be unclear how the data from study A = applies to situation B. Published network measurements relevant to these = questions is subject to fairly large systematic biases, or put another = way, we know much more about academic networks than we do about mobile = access networks. I see two ways forward here, which are probably complementary. (1) Measure path impairment on the Internet We pull together all the data from various studies of broken paths on = the Internet, build from it a set of observations (i.e. at time t the = path from x to y had these characteristics), look for correlations among = those characteristics to allow the amplification of observations when = possible, then correlate this "path impairment data" with estimates of = traffic and topology information to allow us to quantify the risk of = extension failure or extension-linked connectivity failure, and = prioritize design effort based on this estimated risk.=20 This is not a new idea. There is already a fair amount of work in this = space, and probably a bit of infrastructure we could reuse, but to be = useful for protocol design I think it would need to be placed into a = single database, or at least various path impairment databases would = need to share a common schema. I recognize that this proposal has all the same problems with = measurement data access that all other open measurement platforms do, = with the added bonus that active measurements in this space will be = interpreted as malicious by many of the same people who configure their = firewalls to do end-to-end-hostile things. And given the people reading = this message, even if we pulled all available data and designed lots of = active measurements to plug the gaps, and all of you dropped everything = you were doing to work on this, and told all your friends and colleagues = to do the same, and they did so, we would still not have a very = convincing answer to the bias question. (2) Build path impairment measurement into the specifications and = implementations of the extensions. Or "fallback on steroids". This gives a tautological answer to the bias = question, and if we're proposing vastly overengineering the extension = mechanisms anyway we might as well *explicitly* have them measure = in-line as part of the protocol interaction and/or simultaneously with = protocol interactions in independent flows.=20 Assuming one can devise a representation for path impairment that is = useful and does not require the exposure of routable IP addresses or = derived anonymized data from which routable IP addresses can be = inferred, (2) can even be used as a source of data for (1) given the = growing number of operating environments that already have a concept for = "user consent to passive monitoring for debugging and development = purposes" subject to the same magnitude of bias that (1) is already = subject to. Cheers, Brian >> 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, >=20 > You treat the OOB and SYN as a pair, and treat it with the same = time-out > on both ends as far as giving up or retransmitting. How long you keep > queued copies to deal with reordering or other arrival-timing issues = is > up to the receiver. >=20 >> but that could be >> tweakable or algorithmically determined, so I don't think it's a = major >> issue. >=20 > Yes, esp. for the caching part. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Nov 7 11:26: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 BE3001A01EC for ; Fri, 7 Nov 2014 11:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 STy-8tvCmQHO for ; Fri, 7 Nov 2014 11:26:11 -0800 (PST) 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 7E1911A01EA for ; Fri, 7 Nov 2014 11:26:11 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 7 Nov 2014 19:26:08 +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; Fri, 7 Nov 2014 19:26:08 +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; Fri, 7 Nov 2014 19:26:05 +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 sA7JQ5fg002953; Fri, 7 Nov 2014 19:26:05 GMT Message-ID: <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 7 Nov 2014 19:26:03 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <545AC718.4010407@isi.edu> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@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/KCVbJXp_1UDbt_DorI1rDhKpybw Cc: tcpm IETF list 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: Fri, 07 Nov 2014 19:26:13 -0000 Joe, At 00:55 06/11/2014, Joe Touch wrote: >Catching up... > >On 10/27/2014 9:42 PM, Wesley Eddy wrote: >... > > 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. > >Let's be clear - we're ALL in the dark about any of these, both as to >whether they will end up working or to what extent they would be >over-engineered to get around phantoms that don't exist. > > > 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, > >You treat the OOB and SYN as a pair, and treat it with the same time-out >on both ends as far as giving up or retransmitting. How long you keep >queued copies to deal with reordering or other arrival-timing issues is >up to the receiver. Not so IMO. The OOB has to be sent a 'guard time' after the SYN, to minimise the chance of it getting reordered and then getting tangled up in a firewall before the SYN arrives; the firewall will chuck any segment for which it has not seen a prior SYN. So altho the timeouts might be the same it doesn't seem sensible to start the timers at the same time. Two possibilities: a) the guard time is standardised. b) the guard time is up to the client If a), we (the IETF) don't know the operating conditions, so it's difficult to agree on a standard value. We can't calibrate it in units of RTT, because neither end knows the RTT at the stage when they are sending the SYN. If b), the server end doesn't know what the guard time is, so its choice of when to start the timer for the OOB isn't straightforward. I guess the data that is being collected by ALex Z & co /might/ help choose a guard time that avoids the worst re-ordering effects, whether it's chosen at standardisation time (by the IETF) or at run-time (by the client). Bob > > but that could be > > tweakable or algorithmically determined, so I don't think it's a major > > issue. > >Yes, esp. for the caching part. > >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Fri Nov 7 11: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 89E2A1A0A85 for ; Fri, 7 Nov 2014 11:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 yjVQVIAjKTGX for ; Fri, 7 Nov 2014 11:39:20 -0800 (PST) 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 2AF1A1A047A for ; Fri, 7 Nov 2014 11:39:20 -0800 (PST) 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 sA7JcWGj025507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Nov 2014 11:38:32 -0800 (PST) Message-ID: <545D1FB8.2040505@isi.edu> Date: Fri, 07 Nov 2014 11:38:32 -0800 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: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> In-Reply-To: <201411071926.sA7JQ5fg002953@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/zEsixyZl2-BWezI2y_jXccPyU8M Cc: tcpm IETF list 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: Fri, 07 Nov 2014 19:39:21 -0000 Hi, Bob, On 11/7/2014 11:26 AM, Bob Briscoe wrote: > Joe, > > At 00:55 06/11/2014, Joe Touch wrote: ... >> You treat the OOB and SYN as a pair, and treat it with the same time-out >> on both ends as far as giving up or retransmitting. How long you keep >> queued copies to deal with reordering or other arrival-timing issues is >> up to the receiver. > > Not so IMO. The OOB has to be sent a 'guard time' after the SYN, to > minimise the chance of it getting reordered and then getting tangled up > in a firewall before the SYN arrives; the firewall will chuck any > segment for which it has not seen a prior SYN. Firewalls aren't the issue. NATs are, and unless reordering is prevalent that won't be an issue. Reordering would mostly happen on multiple paths, but you'd need multiple paths between the client and the NAT - i.e., in the private side. That's rare if it happens at all. I thus don't agree that guard times are needed, which means we don't need to worry about determining them. > So although the timeouts might be the same it doesn't seem sensible to > start the timers at the same time. I currently believe that there should be one timer. If you need to resend, you resend BOTH the SYN and OOB. The server side can cache to deal with reordering that happens there, but that doesn't require guard-time at client transmission. Joe From nobody Fri Nov 7 13:41: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 5B6461A1B28 for ; Fri, 7 Nov 2014 13:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 u2w7H9l9c5JH for ; Fri, 7 Nov 2014 13:41:16 -0800 (PST) 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 9DC321A007D for ; Fri, 7 Nov 2014 13:41:15 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 7 Nov 2014 21:41:12 +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; Fri, 7 Nov 2014 21:41:08 +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; Fri, 7 Nov 2014 21:41:07 +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 sA7Lf674003241; Fri, 7 Nov 2014 21:41:06 GMT Message-ID: <201411072141.sA7Lf674003241@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 7 Nov 2014 21:41:05 +0000 To: David Borman From: Bob Briscoe In-Reply-To: <710F909D-62CE-426F-A868-0A7894137650@weston.borman.com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> <710F909D-62CE-426F-A868-0A7894137650@weston.borman.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/ogFMaHIjyFJE7vriZGj0VB7gJRA Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" 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, 07 Nov 2014 21:41:20 -0000 David, At 21:01 04/11/2014, David Borman wrote: > > On Nov 3, 2014, at 5:21 PM, Bob Briscoe wrote: > > > > David, > > > > Thx for updating the draft & filename, and particularly for the > adding the roster of existing TCP options. However, to be honest, I > think tcp4way has got caught up in following a false trail. Let me > explain, and I'll add other critique afterwards too. > > > > 1) Following a false trail? > > > > Tcp4way aims to give the client a second chance to negotiate some > more TCP options on a subsequent SYN/ACK. The original reason you > wanted this (from emails back in the summer) was because it would > be really complex to allow a second segment from the client to > negotiate more options if the hosts had already made an interim > decision after the first round. They might need to revoke some of > their earlier decisions, which would be extremely complex and often impossible. > >No. My original point is that negotiating TCP options in packets >without the SYN bit requires additional complexity because ACK-only >packets are not reliably transmitted. The 4WHS adds a client >SYN/ACK packet that is reliably transmitted, and is distinct from >the original client SYN packet. OK, understood (altho RFC793 does not require the ACK of the 3rd leg to be pure. It can ACK the SYN/ACK and send data - I can dig out some recent literature searches I did on why there is usually a 3rd ACK, if anyone's interested). But, granted, in the general case your point is valid that there might not be any data at this point. >For a non-directional option, it doesn't matter which side sends it >first, hence the server SYN/ACK can propose using additional >non-directional options, which can then be confirmed in the client >SYN/ACK of the 4WHS. > >Because both sides know that the other side supports extended option >space, both of the SYN/ACK packets can take advantage of it. > > > However, all that tcp4way has achieved is to send more segments > before making a decision. That means more segments on which TCP > options cannot be /used/ yet. > >Again, no. Options in the initial SYN and SYN/ACK are not >delayed. Nothing from the client side is delayed, because it >decides the full set of what is being used when it gets the servers >SYN/ACK, because it knows which options from the SYN were accepted >by the server, and which options proposed by the server it is >willing to acknowledge when it sends the SYN/ACK. It's the same >point as with the 3WHS. > >The server won't know if the client supports the additional options >that the server proposed in the SYN/ACK until it gets the client's >SYN/ACK, so from the server standpoint, there's one more RTT for >those additional options. Only those options that fit on the first SYN can start being used early. The rest still have to wait. Given the point of this exercise is to make more space for options, you are saying that you can only provide more space for those options that are prepared to wait. > > > > I've calculated how many segments in both directions before a > 4WHS server enters the established state: > > * Without TFO: 3 segments, including 2 that could carry data > > * A resumed connection with TFO & IW=3: 7 segments, all > potentially with data. > > * A resumed connection with TFO & IW=10: 21 segments, all > potentially with data. > > > > So all tcp4way achieves is to prevent TCP options being included > on more segments. > >I don't follow this logic at all. That's possibly my point. I don't think your logic is relevant to the problem at hand. >With the 4WHS the server enters established state at the exact same >time as it does with the 3WHS, when its SYN is >acknowledged. Whether that is an ACK-only packet with a 3WHS, or a >SYN/ACK with a 4WHS, from the server side it still happens at the >same point in the exchange. From the servers perspective, the only >difference is that for the 4WHS it sends a final ACK and does final >option enablement, and for the 3WHS it doesn't. My point is that most TCP options are useful on /segments/. The problem at hand has nothing to do with the state that the TCP state-machine has reached. It has to do with: a) minimising the round trip times before all TCP options can start to be used; b) minimising how many segments might be exchanged before all TCP options can start to be used. > > > > I believe it was wrong to conclude (back in the summer) that the > problem is all about holding back a move to the established state. > Most existing TCP options apply to segments of any kind, > irrespective of whether the host is in the established state when > it sends them, and irrespective of whether they even carry data. > >I never said the problem was about holding back established state. > >I said that if the servers SYN/ACK contained additional options, >with the 4WHS the client can respond with a SYN/ACK to complete >negotiation of those additional options, whereas the 3WHS doesn't >have that possibility. And the only reason those options wouldn't >have been in the SYN is because there wasn't enough space, but with >EDO there is now space in the SYN/ACK. OK I accept that your goal was not about holding back established state. But I'm not impressed. You just allowed up to 21 segments to go past without being able to use some TCP options that you are still in the process of negotiating. > > > > In all the following examples, if the client wants to support > option X and the server can support X, the server would ideally > like to start using X on the first SYN/ACK, whether or not the > client is offering to delay moving into the established state for a round: > >If X was in the SYN, it can. If X wasn't in the SYN, it can't, >because it doesn't know that the client supports X, it'll have to >wait for the SYN/ACK to know if the client supports X. Yes. And that's why I'm not particularly impressed. > > * TCP-AO >TCP-AO is not negotiated. > > > * The following sub-options of the tcpcrypt CRYPT option: > DECLINE, PKCONF*, NEXTK1*, NEXTK2*, INIT1, INIT2, UNKNOWN, > SYNCOOOKIE, ACKCOOKIE, REKEY, REKEYSTREAM. > > * the tcpcrypt MAC option > > * MPTCP_JOIN, ADD_ADDR(2), DSS, MP_PRIO, MP_FAIL > > * SACK permitted > > * MSS > > * TFO > > * TS (if used for RTT calculation) > > * UTO > > > > The only ones that are meaningless on the first SYN/ACK are: > > * SACK (because the SACK block for zero previous ACKs would be > pretty uninteresting. However SACK would be useful on ACKs from the > client while still in SYN-RCVD) > > * TS (if used for PAWS, 'cos there's no risk of wrap on the first > few segments) > > * WS (The client can't use a large RWND until it has opened up > cwnd thru a few rounds of slow-start. However, this is arguable, > because there might be occasions where a connection can safely > inherit a large cwnd). > > > > Some option are only meaningful once data has started (e.g. UTO, > MPTCP-DSS, WS), but even those can be used prior to connection establishment. > > > > > We can't know which of these two lists yet-to-be-defined new > options will be in. If the past is a good predictor of the future, > the first list is more likely (ie. the ones tcp4way doesn't help much). > >I'm not quite sure what your point is with just an enumerated list. (Other than mistakenly including TCP-AO) I've divided up the options into those that make sense as early as the first SYN/ACK and those that could probably wait. So,... * A 4WHS client has to consider all the options it thinks might be needed and decide which can wait. I'm not convinced that it makes sense to wait for any of the options in the first list. For some of them, it certainly gets messy to start without them, then to add them. * All the particularly large options are in the first list. * The very large majority of connections only consists of a few segments. 4WHS provides extra space after most connections will have finished. So, in the large majority of connections, 4WHS doesn't solve any problem at all. >For each of them, the question is, if the option is not included in >the initial client SYN, can it make sense in the servers >SYN/ACK? For example, if a server doesn't receive TFO in the SYN, >it could still send TFO in the SYN/ACK, which would just be ignored >by non-TFO implementations. Directional options, where the servers >option is dependent on first knowing the contents of the clients >option, are not candidates. The example you have chosen illustrates my concern in a number of ways. TFO isn't a problem on the first connection in which it is used. It consumes 2B on the SYN, and 6-18B on the SYN/ACK. TFO hits the space problem when it is used on a subsequent connection. The client sends the cookie it got from the previous connection /in the SYN/. There is no TFO option in the SYN/ACK on the resumed connection. The whole point of TFO is for the client to prove to the server that it had a previous valid connection. Secondly, there is no point deferring TFO to the second SYN/ACK, because the 'F' in TFO means 'Fast'. Similarly for tcpcrypt. There's no point having sent up to 21 segments of data in the clear before any keys have been agreed. OK, you might argue that if you're using tcpcrypt you send no data until the keys have been agreed. However, the point of tcpcrypt is meant to be opportunistic encryption. I.e. it can be turned on for /all/ connections with zero config and minimal performance hit. If turning on tcpcrypt causes every connection to have to wait an extra round before it can send data, it will not be ubiquitous. It will be nobiquitous. >The 4WHS does not give the client a second chance to initiate option >negotiation, that would require a 5WHS. > > > > > 2) Latency > > > > Tcp4way always introduces latency. How much depends on which scenario: > > * TCP client sends request first (by far the majority of > connections): 1 RTT > > * TCP server sends data first (e.g. resuming a push connection): 0.5 RTT > > > > As JohnL said, "any added latency is nearly fatal". I strongly > agree with every word, except "nearly". > >If you are talking about latency of delivering user data, there >isn't any. See my message entitled "We already support multiple >versions of the TCP header", and look for the section entitled >"Delivering User Data". Those changes will be in the next revision >of the 4WHS draft. There is latency added to any user-data (or empty segments) that want the benefit of the TCP options we're trying to make space for. In 4WHS, it's the extra space that suffers the latency. It doesn't appear soon enough to be useful. > > 3) Firewalls & Intrusion Detection Systems >... > >I don't subscribe to the notion that today's deployed middle boxes >get to dictate all future development of the TCP protocol. Yes, >ignoring them would be silly, but kowtowing to them is equally silly. I'll substitute your corrected text for your next para... >We need to first decide what we want TCP to look like, and then find >a way to transition from current implementations to the new design, >which might include middle boxes having to change, rather than >letting current middle box implementations dictate how we can or >can't change TCP. With inner space, I also started from where we should want TCP to end up, and found a way to transition to it. Here's my starting principles: 1) Options should be in the TCP header. Extensions should be within the TCP Data. [I just submitted a paper to the IAB SEMI workshop that gives the rationale for that: . ] 2) Minimal delay before options can be used 3) Choice between fire-and-forget options and reliable-in-order options 4) Host control over which options and base header fields are available for interaction with middleboxes, and which are strictly e2e. 5) Enforcement of the above choice through authentication and/or encryption. 6) Incremental deployment (against legacy servers and legacy middleboxes) You say "transition ... might include middleboxes having to change". That earns you a patronising smile. Nonetheless, starting from principles is a sentiment I can wholeheartedly agree with. > > __________________ > > They are my 3 main criticisms. The rest are nits... > > > > 4) Nit: Reflection of Reserved Flags >... > >Did you miss sections 4.3.2 and 4.3.3 where I discussed why this is >not an issue? I read these sections and they have misunderstood the problem. There is an easy way to solve the problem tho. (which I suggested in the text that you've removed from the thread). > > 5) Nit: Remembering EDO support across connections > > > > S.7.3.2.1 says that server EDO support can be saved alongside a > TFO cookie. I don't believe this is safe. During an upgrade, there > might be some server replicas that support EDO and others that > don't. The legacy servers would then ignore the EDO option, but > still pass TCP options as a corrupt payload to the app. > > > > [BTW, it is safe for a client to hold solely the TFO capability > of a server in a cookie, because (unlike EDO) TFO doesn't put data > that is not intended for the app in the payload. So, if a replica > server that picks up the resumed connection does not support TFO, > it will simply ignore the cookie and just hold the data back until > the 3WHS completes.] > >Good points, I'll take that out. > > > > > 6) Nit: Unknown Option > > > > Altho it would be nice to think that this might help, there > doesn't seem to be a case where it will. Can you give an example > where the Unknown Options is useful? > >I did, UTO. It would also be useful for late enablement of >TS. Basically, it is useful for using any option which does not >require that use of that option be negotiated in the initial SYN exchange. > >The main purpose of the Unknown Option option is to provide a >generic way to inform the other side that you don't understand a >particular option, when that option first appears mid-stream, rather >than support for that option being negotiated in the initial SYN >exchange. Otherwise, if you send an option for the first time >mid-stream, the only way to know that the other side doesn't support >it is by lack of any response to that option. That requires >tracking what sequence number you first sent it with, and waiting >for the ACK for that sequence number to decide on a >non-response. But sequence number tracking doesn't work if you >don't have any new data to send, so you need another mechanism. If >you know the other side support the Unknown Option option, then you >know it'll tell you if you send any other options that it doesn't understand. You might want to say all that in the draft. It's impossible to infer all this without you having said it. BTW, this is why one of my starting principles was: "Choice between fire-and-forget options and reliable-in-order options" Inner-space-01 gives you the latter. Inner-space-02 (sitting on my machine waiting to send) gives you both. The Unknown Option option only solves the negative part of this problem, i.e. inferring /lack/ of support. Inner space solves the positive side as well, i.e. inferring both hosts support option X, and co-ordinating the point in each half-connection when X starts to become enabled. This makes it much easier to design and implement options that require co-ordination between both ends for when a change occurs (e.g. a re-key, or switching something on or off), precisely in the case you point out, when there is no new data. This relates to a point I was making to Yoshifumi: simplicity isn't just in the scheme itself, it also concerns improving how simple it is to design and implement new TCP options. > > 7) Nit: T/TCP is obsolete. > > > > T/TCP had vulnerabilities and was obsoleted by RFC6247. > >Yes, that's why the document says: > > Though now obsolete [RFC6247], this is a good > example of a directional TCP option. OK. My mistake. Cheers Bob > > Bob > > -David ________________________________________________________________ Bob Briscoe, BT From nobody Fri Nov 7 13:50: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 E92B51A1B59 for ; Fri, 7 Nov 2014 13:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 khSOMEjG4kI6 for ; Fri, 7 Nov 2014 13:50:51 -0800 (PST) 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 CF9871A1B4F for ; Fri, 7 Nov 2014 13:50:50 -0800 (PST) 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; Fri, 7 Nov 2014 21:50:48 +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; Fri, 7 Nov 2014 21:50:47 +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; Fri, 7 Nov 2014 21:50:46 +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 sA7LoisA003260; Fri, 7 Nov 2014 21:50:44 GMT Message-ID: <201411072150.sA7LoisA003260@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 7 Nov 2014 21:50:43 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <545910E8.40301@isi.edu> References: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> <201411041721.sA4HLpr8022330@bagheera.jungle.bt.co.uk> <545910E8.40301@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/mvDJRmzlOPDBzaVTVr8vUJLbZ4w Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" , David Borman 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, 07 Nov 2014 21:50:53 -0000 Joe, At 17:46 04/11/2014, Joe Touch wrote: >On 11/4/2014 8:52 AM, Bob Briscoe wrote: >... > > EDO, tcp4way, EOS, Inner Space /all/ use payload as option space, > > because if an option like EDO that extends the header is stripped, the > > data receiver thinks the data offset has reverted to DO, so the place > > where the options had been placed becomes payload. > > > > I explained to Joe in the posting pasted below, why there is a safety > > issue when header and payload do not necessarily share the same fate. > >That's also true for DO, FWIW. > >However, the issue of how the option is encoded is orthogonal to these >solutions. Bob's in-band encoding would work in any of them, but also >ends up "encoding TCP inside TCP", which can easily lead to escalation >(as I've pointed out on the list already). I am encoding TCP /options/ inside TCP Data, which is significantly different from encoding TCP inside TCP (which I agree would not be appropriate). >For that reason, I don't support the idea of in-band encoding, but >that's independent of the way in which the space itself is indicated and >coordinated. I believe TCP options should have always been within the TCP Data (as a design principle, not just as a hack for middlebox traversal). That's where I started from. See the couple of pages position paper I submitted to the IAB SEMI workshop: >... > > This is why Joe has updated EDO to now require an EDO option on every > > segment, even if no extra option space is needed. Then if the receiver > > sees the EDO option disappear at a certain point in the connection, it > > knows that the payload could be corrupt. > > > > This is still not as inherently safe as Inner Space. > >And neither would be as safe as running encrypted TCP inside TCP. > >The question is whether we need to deal with this issue, i.e., whether >such middlebox asymmetries can occur in practice. I definitely want to be able to use encryption of TCP data to also encrypt TCP options. Again, this is not TCP in TCP. It's TCP options in TCP. > > ...We need to agree > > whether latency is part of the design brief. > >+1 +2 Vote early, vote often. Bob >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Fri Nov 7 13:57: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 BBBA81A1B39 for ; Fri, 7 Nov 2014 13:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 OL3MChtLu9rY for ; Fri, 7 Nov 2014 13:57:40 -0800 (PST) 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 A9E931A1A80 for ; Fri, 7 Nov 2014 13:57:40 -0800 (PST) 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 sA7Lv5QT013957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Nov 2014 13:57:05 -0800 (PST) Message-ID: <545D4031.2050203@isi.edu> Date: Fri, 07 Nov 2014 13:57:05 -0800 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: <201411032343.sA3NhoGo018452@bagheera.jungle.bt.co.uk> <201411041721.sA4HLpr8022330@bagheera.jungle.bt.co.uk> <545910E8.40301@isi.edu> <201411072150.sA7LoisA003260@bagheera.jungle.bt.co.uk> In-Reply-To: <201411072150.sA7LoisA003260@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/Sk_CF_rVVusJ7eBhgH30zrq9tVE Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" , David Borman 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, 07 Nov 2014 21:57:41 -0000 On 11/7/2014 1:50 PM, Bob Briscoe wrote: > Joe, > > At 17:46 04/11/2014, Joe Touch wrote: > > >> On 11/4/2014 8:52 AM, Bob Briscoe wrote: >> ... >> > EDO, tcp4way, EOS, Inner Space /all/ use payload as option space, >> > because if an option like EDO that extends the header is stripped, the >> > data receiver thinks the data offset has reverted to DO, so the place >> > where the options had been placed becomes payload. >> > >> > I explained to Joe in the posting pasted below, why there is a safety >> > issue when header and payload do not necessarily share the same fate. >> >> That's also true for DO, FWIW. >> >> However, the issue of how the option is encoded is orthogonal to these >> solutions. Bob's in-band encoding would work in any of them, but also >> ends up "encoding TCP inside TCP", which can easily lead to escalation >> (as I've pointed out on the list already). > > I am encoding TCP /options/ inside TCP Data, which is significantly > different from encoding TCP inside TCP (which I agree would not be > appropriate). There's little difference to me. >> For that reason, I don't support the idea of in-band encoding, but >> that's independent of the way in which the space itself is indicated and >> coordinated. > > I believe TCP options should have always been within the TCP Data (as a > design principle, not just as a hack for middlebox traversal). That's > where I started from. Just as I start from the converse position. IMO, TCP has a header. It's either extensible or not. If it is, then anyone who interprets the header *and* knows it can't understand it KNOWS it's doing something wrong if it acts on it. Joe From nobody Fri Nov 7 20:27: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 6B8A41A00B2 for ; Fri, 7 Nov 2014 20:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 dmK5aTjS1r7U for ; Fri, 7 Nov 2014 20:27:30 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D731A0083 for ; Fri, 7 Nov 2014 20:27:30 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id va2so3575111obc.28 for ; Fri, 07 Nov 2014 20:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yvbeCd6/rQLEQx64GNAp/VUR73rg+E0ie+XvzxheII8=; b=FnAMR9tL6jA+CPI2PFaeHN3l8dtNcef2wXShGYb5zHQ31D+C1D1hztiT8mFqjd7hFp J5PxXukNK/9qiKioiw+3XG5ZDbHLj8lbce73hWGeUE3qCWAFSyJc3j9wR/Fzt4TIzEvB Of6hX752EcW9H40gdQDj3xJJ1xT4C/iZNIWwWc3MocWBoJVYPnqU0Z7ZYossWifbaL96 qI4CqReC9BH8YmSu3Se4FtUNNHhmnkU0EkAh51Wz0ScR5SCMUOB9drdU+5U24mTIembE XBsaodvWOYOXPexhsi6jgztCYbwQvw5bxvrRB+sMtombPfoxR2qnXTfMPxQGNXImpuIF Lugw== 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=yvbeCd6/rQLEQx64GNAp/VUR73rg+E0ie+XvzxheII8=; b=PeVXoCEVJoJUQfNYdBUe8Meh7Sa14hneGATMGukReHJsS64IiF1ad4AKjeYIzlOSv1 WdTEXf97QJpMDK1poOxWaJ3IRGH6FvFLNLAY0swQuc/K9dWX8fL0hWzMWuP6bU0DUnm1 A1tPTNVYpzUp/d4SzUNusLHyz9rhNg0ZJ2y9sjfpme/GoAqXIh4MLbS4IoK1SXqqen6q I7nre23omznRu7DotdjT9QTjGWyh8X4iD2CeTui0o9yNVsUs3iBUEqu94PKXDeFm5Dlg e9oH4vI1Gb3TTNbL+l9y/3q0y6iyG/QHubqCfECrxVGh9JsNiCcpw2PY1iVlGwrGGbKG Lmuw== X-Gm-Message-State: ALoCoQlCsW0HxfIPdH8X7fnYbHmmG0Eb3/xrK/OhAMW2B98xaCXUSBKs1fMgEm++d/WofIno6kxD MIME-Version: 1.0 X-Received: by 10.202.134.9 with SMTP id i9mr12718585oid.34.1415420849544; Fri, 07 Nov 2014 20:27:29 -0800 (PST) Received: by 10.202.67.6 with HTTP; Fri, 7 Nov 2014 20:27:29 -0800 (PST) In-Reply-To: <545D1FB8.2040505@isi.edu> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> <545D1FB8.2040505@isi.edu> Date: Fri, 7 Nov 2014 18:27:29 -1000 Message-ID: From: Andrew Mcgregor To: Joe Touch Content-Type: multipart/alternative; boundary=001a113e44b4f2012905075158a5 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LLeVFnVh9ZavOsb6b4dOJNWMGCg Cc: tcpm IETF list 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: Sat, 08 Nov 2014 04:27:32 -0000 --001a113e44b4f2012905075158a5 Content-Type: text/plain; charset=UTF-8 On 7 November 2014 09:38, Joe Touch wrote: > Hi, Bob, > > On 11/7/2014 11:26 AM, Bob Briscoe wrote: > > Joe, > > > > At 00:55 06/11/2014, Joe Touch wrote: > ... > >> You treat the OOB and SYN as a pair, and treat it with the same time-out > >> on both ends as far as giving up or retransmitting. How long you keep > >> queued copies to deal with reordering or other arrival-timing issues is > >> up to the receiver. > > > > Not so IMO. The OOB has to be sent a 'guard time' after the SYN, to > > minimise the chance of it getting reordered and then getting tangled up > > in a firewall before the SYN arrives; the firewall will chuck any > > segment for which it has not seen a prior SYN. > > Firewalls aren't the issue. NATs are, and unless reordering is prevalent > that won't be an issue. > > Reordering would mostly happen on multiple paths, but you'd need > multiple paths between the client and the NAT - i.e., in the private > side. That's rare if it happens at all. > It's rare right now, but there is lots of pressure to make reordering protection in 802.11 aggregation optional, which will make it quite common since I would expect it to be off by default on a lot of equipment with firmware shipping late 2015 and thereafter. > > I thus don't agree that guard times are needed, which means we don't > need to worry about determining them. > 50ms would certainly do it, although that's more than many RTTs. 5ms would be adequate in many cases. > > > So although the timeouts might be the same it doesn't seem sensible to > > start the timers at the same time. > > I currently believe that there should be one timer. If you need to > resend, you resend BOTH the SYN and OOB. The server side can cache to > deal with reordering that happens there, but that doesn't require > guard-time at client transmission. > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a113e44b4f2012905075158a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 7 November 2014 09:38, Joe Touch <touch@isi.edu> wrote:
Hi, Bob,

On 11/7/2014 11:26 AM, Bob Briscoe wrote:
> Joe,
>
> At 00:55 06/11/2014, Joe Touch wrote:
...
>> You treat the OOB and SYN as a pair, and treat it= with the same time-out
>> on both ends as far as giving up or retransmitting. How long you k= eep
>> queued copies to deal with reordering or other arrival-timing issu= es is
>> up to the receiver.
>
> Not so IMO. The OOB has to be sent a 'guard time' after the SY= N, to
> minimise the chance of it getting reordered and then getting tangled u= p
> in a firewall before the SYN arrives; the firewall will chuck any
> segment for which it has not seen a prior SYN.

Firewalls aren't the issue. NATs are, and unless reordering is p= revalent
that won't be an issue.

Reordering would mostly happen on multiple paths, but you'd need
multiple paths between the client and the NAT - i.e., in the private
side. That's rare if it happens at all.

=
It's rare right now, but there is lots of pressure to make reorder= ing protection in 802.11 aggregation optional, which will make it quite com= mon since I would expect it to be off by default on a lot of equipment with= firmware shipping late 2015 and thereafter.

I thus don't agree that guard times are needed, which means we don'= t
need to worry about determining them.

5= 0ms would certainly do it, although that's more than many RTTs. =C2=A05= ms would be adequate in many cases.
=C2=A0

> So although the timeouts might be the same it doesn't seem sensibl= e to
> start the timers at the same time.

I currently believe that there should be one timer. If you need to resend, you resend BOTH the SYN and OOB. The server side can cache to
deal with reordering that happens there, but that doesn't require
guard-time at client transmission.

Joe

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



--
=
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a113e44b4f2012905075158a5-- From nobody Fri Nov 7 20:32: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 CA8C81A0204 for ; Fri, 7 Nov 2014 20:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 J911KYIF7PEY for ; Fri, 7 Nov 2014 20:32:50 -0800 (PST) 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 B6AE01A016A for ; Fri, 7 Nov 2014 20:32:50 -0800 (PST) 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 sA84WQYv008324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Nov 2014 20:32:26 -0800 (PST) Message-ID: <545D9CDA.8060704@isi.edu> Date: Fri, 07 Nov 2014 20:32:26 -0800 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: Andrew Mcgregor References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> <545D1FB8.2040505@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/w3bgUiA3WbpDX2hy4HAiOnsw1Ws Cc: tcpm IETF list 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: Sat, 08 Nov 2014 04:32:52 -0000 On 11/7/2014 8:27 PM, Andrew Mcgregor wrote: > > > On 7 November 2014 09:38, Joe Touch > wrote: > > Hi, Bob, > > On 11/7/2014 11:26 AM, Bob Briscoe wrote: > > Joe, > > > > At 00:55 06/11/2014, Joe Touch wrote: > ... > >> You treat the OOB and SYN as a pair, and treat it with the same time-out > >> on both ends as far as giving up or retransmitting. How long you keep > >> queued copies to deal with reordering or other arrival-timing issues is > >> up to the receiver. > > > > Not so IMO. The OOB has to be sent a 'guard time' after the SYN, to > > minimise the chance of it getting reordered and then getting tangled up > > in a firewall before the SYN arrives; the firewall will chuck any > > segment for which it has not seen a prior SYN. > > Firewalls aren't the issue. NATs are, and unless reordering is prevalent > that won't be an issue. > > Reordering would mostly happen on multiple paths, but you'd need > multiple paths between the client and the NAT - i.e., in the private > side. That's rare if it happens at all. > > It's rare right now, but there is lots of pressure to make reordering > protection in 802.11 aggregation optional, which will make it quite > common since I would expect it to be off by default on a lot of > equipment with firmware shipping late 2015 and thereafter. Reordering protection isn't the same as whether reordering will typically happen. However, we're talking about the packets with the same src/dst addresses. Why would 802.11 aggregation affect their order? (I.e., I can see it affecting the relative order of packets to/from different destinations, but not the same ones)... Joe From nobody Fri Nov 7 20:50: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 B71241A01D6 for ; Fri, 7 Nov 2014 20:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 GpVbLPYZ6nu3 for ; Fri, 7 Nov 2014 20:50:35 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E8A1A01C6 for ; Fri, 7 Nov 2014 20:50:34 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id v63so3334489oia.18 for ; Fri, 07 Nov 2014 20:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FSa8ephBio7B0k3H4dxwmsSNEDrnojRMFOsVf6xzMLA=; b=egBahOnJtdZufpcuHntEBY/t5y6OoH7nDF8UXntSc79uUEb25VDCZ/j+HWTasGvLQ5 9INk6orqeOpw+7KHvFIssy5yDNFPLfTXBSu7k7Xuanq9q965b+NfCmVICmaKl4caiCkh Zsz5aZYIbQofjEKeB1QmZwmguc31AlxodQYEP3kQeBDZWt/JgiCUoptPhE3teqYWTyIU vYSpfYGKNjIKur6MMAbazHR+dllbyaICE1UqqTEazN2OoGeIWbz16O7TN9pojM2tk8OJ V9pk3ts658Ekmwa6jK8ROH4Lmz+4YE72TMl1C3vuUiVAyueXbqR9nNsyOFdlEVhXXbNm QEeQ== 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=FSa8ephBio7B0k3H4dxwmsSNEDrnojRMFOsVf6xzMLA=; b=OjE1O9SYXwQ3x3070vkrc2sq14UntebB4ayyT7ZdlhcFz5lDa7xFB1CXyHKOtz7a/V +i/mvo1+JOeVOeGNACGb/m/8+YU9HiBOXg4/tasrogTEFHHPn6DBLPVtGUF4Ru0mRWbZ u64Y0HEX11LXYHHzyWLYVwl2l2XXzyx866d8BosxFzPgrAWyOEbvOHvNj//9e4bvtY4J g+u6HrZ0NK+vsODWnuOYgT42y778VKdpoa4kaVDdZLm6JtV2y3l/s6MjVaXJhaBMj1Od E+aqq9yVZAVG3+mlsrF2f710VrAhkbSNwyUlKZ8qODlvQVTYD09DPk0WZ5P0cfnWSItL K0tg== X-Gm-Message-State: ALoCoQn7dO0iOiVg12EM2Uh3zZIMlCFVSjyQ+raiQW6YnPpgrgHH8BjaDe/RpbpszI1sNUz3OWQW MIME-Version: 1.0 X-Received: by 10.60.173.39 with SMTP id bh7mr13699833oec.32.1415422233964; Fri, 07 Nov 2014 20:50:33 -0800 (PST) Received: by 10.202.67.6 with HTTP; Fri, 7 Nov 2014 20:50:33 -0800 (PST) In-Reply-To: <545D9CDA.8060704@isi.edu> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> <545D1FB8.2040505@isi.edu> <545D9CDA.8060704@isi.edu> Date: Fri, 7 Nov 2014 18:50:33 -1000 Message-ID: From: Andrew Mcgregor To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bd6ba9a769651050751ab6d Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/tAuOAT33CNGvQvL4zWfHAPfDlSQ Cc: tcpm IETF list 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: Sat, 08 Nov 2014 04:50:36 -0000 --047d7bd6ba9a769651050751ab6d Content-Type: text/plain; charset=UTF-8 On 7 November 2014 18:32, Joe Touch wrote: > > > On 11/7/2014 8:27 PM, Andrew Mcgregor wrote: > > > > > It's rare right now, but there is lots of pressure to make reordering > > protection in 802.11 aggregation optional, which will make it quite > > common since I would expect it to be off by default on a lot of > > equipment with firmware shipping late 2015 and thereafter. > > Reordering protection isn't the same as whether reordering will > typically happen. > > However, we're talking about the packets with the same src/dst > addresses. Why would 802.11 aggregation affect their order? (I.e., I can > see it affecting the relative order of packets to/from different > destinations, but not the same ones)... > > Joe > The 802.11 MAC can aggregate multiple IP packets into what's called an AMPDU (and has to, in order to achieve decent performance). Individual packets within an AMPDU are checksummed separately, and can be retransmitted individually or as part of the next AMPDU. Right now, reordering protection requires that IP packets (strictly, ethernet frames) that have been correctly received but are behind (in link-layer sequence number space) one that has not been received or explicitly NAKed have to be buffered until receipt of the delaying frame or a NAK or a rather long timeout. Since the raw single-shot failure rate can be up to around 45%, this happens a lot, and experiment indicates that if the traffic is tolerant to a reasonable reordering window (as most current TCPs are, for example) end-to-end performance is significantly better with reordering protection disabled. So yes, if reordering protection is off, packets within a single flow will get reordered fairly frequently. -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --047d7bd6ba9a769651050751ab6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 November 2014 18:32, Joe Touch <touch@isi.edu> wrote:


On 11/7/2014 8:27 PM, Andrew Mcgregor wrote:
>

> It's rare right now, but there is lots of pressure to make reorder= ing
> protection in 802.11 aggregation optional, which will make it quite > common since I would expect it to be off by default on a lot of
> equipment with firmware shipping late 2015 and thereafter.

Reordering protection isn't the same as whether reordering will<= br> typically happen.

However, we're talking about the packets with the same src/dst
addresses. Why would 802.11 aggregation affect their order? (I.e., I can see it affecting the relative order of packets to/from different
destinations, but not the same ones)...

Joe

The 802.11 MAC can aggregate multiple = IP packets into what's called an AMPDU (and has to, in order to achieve= decent performance).=C2=A0 Individual packets within an AMPDU are checksum= med separately, and can be retransmitted individually or as part of the nex= t AMPDU.=C2=A0 Right now, reordering protection requires that IP packets (s= trictly, ethernet frames) that have been correctly received but are behind = (in link-layer sequence number space) one that has not been received or exp= licitly NAKed have to be buffered until receipt of the delaying frame or a = NAK or a rather long timeout.=C2=A0 Since the raw single-shot failure rate = can be up to around 45%, this happens a lot, and experiment indicates that = if the traffic is tolerant to a reasonable reordering window (as most curre= nt TCPs are, for example) end-to-end performance is significantly better wi= th reordering protection disabled.

So yes, if reordering protection is off, packe= ts within a single flow will get reordered fairly frequently.

--
Andrew McGregor= =C2=A0|=C2=A0SRE=C2= =A0|=C2=A0andrewmcgr@google.com=C2= =A0|=C2=A0+61 4 1071 = 2221
--047d7bd6ba9a769651050751ab6d-- From nobody Fri Nov 7 21:12: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 3759A1A0368 for ; Fri, 7 Nov 2014 21:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 WNpH2Zc3tBJs for ; Fri, 7 Nov 2014 21:12:33 -0800 (PST) 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 DD0371A0282 for ; Fri, 7 Nov 2014 21:12:32 -0800 (PST) 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 sA85BquB015188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Nov 2014 21:11:53 -0800 (PST) Message-ID: <545DA618.1040802@isi.edu> Date: Fri, 07 Nov 2014 21:11:52 -0800 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: Andrew Mcgregor References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> <545D1FB8.2040505@isi.edu> <545D9CDA.8060704@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/svxW_pP_f--l2KWu7CdMGt8YuYc Cc: tcpm IETF list 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: Sat, 08 Nov 2014 05:12:34 -0000 On 11/7/2014 8:50 PM, Andrew Mcgregor wrote: ... > Reordering protection isn't the same as whether reordering will > typically happen. > > However, we're talking about the packets with the same src/dst > addresses. Why would 802.11 aggregation affect their order? (I.e., I can > see it affecting the relative order of packets to/from different > destinations, but not the same ones)... > > Joe > > The 802.11 MAC can aggregate multiple IP packets into what's called an > AMPDU (and has to, in order to achieve decent performance). Individual > packets within an AMPDU are checksummed separately, and can be > retransmitted individually or as part of the next AMPDU. Right now, > reordering protection requires that IP packets (strictly, ethernet > frames) that have been correctly received but are behind (in link-layer > sequence number space) one that has not been received or explicitly > NAKed have to be buffered until receipt of the delaying frame or a NAK > or a rather long timeout. Since the raw single-shot failure rate can be > up to around 45%, this happens a lot, and experiment indicates that if > the traffic is tolerant to a reasonable reordering window (as most > current TCPs are, for example) end-to-end performance is significantly > better with reordering protection disabled. > > So yes, if reordering protection is off, packets within a single flow > will get reordered fairly frequently. The client can still get through a NAT a few different ways: - a gap (as suggested before) - bursting a small number of copies of SYN/OOB pairs the first SYN through a NAT would make way for a following OOB First, though, tt'd be useful to understand what the error properties are, esp. whether they're burst or uncorrellated. And - with a single-shot failure rate that high, why FEC isn't being considered. Joe From nobody Fri Nov 7 21:22: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 3F8E81A0377 for ; Fri, 7 Nov 2014 21:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 C0RvqWZYudpR for ; Fri, 7 Nov 2014 21:21:59 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B531A0372 for ; Fri, 7 Nov 2014 21:21:59 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id m8so3438908obr.8 for ; Fri, 07 Nov 2014 21:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HQs+UYhIKiX9y8kjIKBMCYM24gziuJxIV1mYPIcr1j8=; b=CSgTYxeHfcHYtVVzxidv91pKJ49n29ETdk6phPQi0H49Pbv3xLOat5wpJ8hRI+5v7U QmM6Dz/RJeDmzWvJ+3bJGfoRvGPoPZyAcIu+n5tgCj3kz0Ff4QAdfv9y6gNnQ/wD4595 AXpROi3gACQaZrc8W7wT1BEhXfPPipLcEyfHPaUXEMSwo2cSeAUo/+ROIQJJkAAXJJKH jMnYUc7LfuoKTz1MKu5QQZQPR0+VqAWOQet1eiM2J3/d2UxScpW1AU/5CBprVBvUIto3 8qDYY5pZ9Nd2yKLIC+puvVyZoEbX0ikHwaA15HuBIsZlzJZ8GwGhLxiChJJ7leY1v34N x6Kw== 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=HQs+UYhIKiX9y8kjIKBMCYM24gziuJxIV1mYPIcr1j8=; b=NczfgnlWcoqAi3iQnuHrX0a4jlTrlMxNdwFQKLJH2RvzbTQ/BnxguTrU+WaS4hcg// 2+oHr2NcY16x0zQTUNqYNNFPxgabUxiFI4GW9JvtjRq3oVGFawG1DdurOLsRzZeZgenS L5CaM2cKBh31wfNkphk4XUC3ap8uQrsMEGSWhlx015xx0DWYj7YIhefDOIl1CWEuBkUH Co7GS9Zg9uzM16WMIFOKGGdB3NvlN4sa07Y5f56v5qJuZyo0rfYS/mOchyksmoyutISN 8NPkKUWkLMAp+bgJiB9y3zm/1RxYlyw+FBTAhgbI72uFfFYvYHPwLFsd9FkctPmSQmG2 xNaA== X-Gm-Message-State: ALoCoQn8/K6YmkZv6kuFWHFsnqjGiig8LTw1BE28T0rQu0o6Fgff+srn/c0u8ZBpYi+FQuk/ZExH MIME-Version: 1.0 X-Received: by 10.202.214.19 with SMTP id n19mr12809797oig.9.1415424118212; Fri, 07 Nov 2014 21:21:58 -0800 (PST) Received: by 10.202.67.6 with HTTP; Fri, 7 Nov 2014 21:21:58 -0800 (PST) In-Reply-To: <545DA618.1040802@isi.edu> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> <545D1FB8.2040505@isi.edu> <545D9CDA.8060704@isi.edu> <545DA618.1040802@isi.edu> Date: Fri, 7 Nov 2014 19:21:58 -1000 Message-ID: From: Andrew Mcgregor To: Joe Touch Content-Type: multipart/alternative; boundary=001a113b0166c5e9580507521bbe Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BwDSYxy9TgRvXhJ5A4qcScnZ-kQ Cc: tcpm IETF list 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: Sat, 08 Nov 2014 05:22:01 -0000 --001a113b0166c5e9580507521bbe Content-Type: text/plain; charset=UTF-8 On 7 November 2014 19:11, Joe Touch wrote: > > > On 11/7/2014 8:50 PM, Andrew Mcgregor wrote: > ... > > Reordering protection isn't the same as whether reordering will > > typically happen. > > > > However, we're talking about the packets with the same src/dst > > addresses. Why would 802.11 aggregation affect their order? (I.e., I > can > > see it affecting the relative order of packets to/from different > > destinations, but not the same ones)... > > > > Joe > > > > The 802.11 MAC can aggregate multiple IP packets into what's called an > > AMPDU (and has to, in order to achieve decent performance). Individual > > packets within an AMPDU are checksummed separately, and can be > > retransmitted individually or as part of the next AMPDU. Right now, > > reordering protection requires that IP packets (strictly, ethernet > > frames) that have been correctly received but are behind (in link-layer > > sequence number space) one that has not been received or explicitly > > NAKed have to be buffered until receipt of the delaying frame or a NAK > > or a rather long timeout. Since the raw single-shot failure rate can be > > up to around 45%, this happens a lot, and experiment indicates that if > > the traffic is tolerant to a reasonable reordering window (as most > > current TCPs are, for example) end-to-end performance is significantly > > better with reordering protection disabled. > > > > So yes, if reordering protection is off, packets within a single flow > > will get reordered fairly frequently. > > The client can still get through a NAT a few different ways: > > - a gap (as suggested before) > > - bursting a small number of copies of SYN/OOB pairs > the first SYN through a NAT would make way for > a following OOB > > Indeed, those can work. > First, though, tt'd be useful to understand what the error properties > are, esp. whether they're burst or uncorrellated. > Tend to be bursty, there are some studies on this so data is available. > > And - with a single-shot failure rate that high, why FEC isn't being > considered. > > Joe > I don't know for sure, but if I had to speculate I'd say the answer would be 'patents'. -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a113b0166c5e9580507521bbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 November 2014 19:11, Joe Touch <touch@isi.edu> wrote:


On 11/7/2014 8:50 PM, Andrew Mcgregor wrote:
...
>=C2=A0 =C2=A0 =C2=A0Reordering protection isn't th= e same as whether reordering will
>=C2=A0 =C2=A0 =C2=A0typically happen.
>
>=C2=A0 =C2=A0 =C2=A0However, we're talking about the packets with t= he same src/dst
>=C2=A0 =C2=A0 =C2=A0addresses. Why would 802.11 aggregation affect thei= r order? (I.e., I can
>=C2=A0 =C2=A0 =C2=A0see it affecting the relative order of packets to/f= rom different
>=C2=A0 =C2=A0 =C2=A0destinations, but not the same ones)...
>
>=C2=A0 =C2=A0 =C2=A0Joe
>
> The 802.11 MAC can aggregate multiple IP packets into what's calle= d an
> AMPDU (and has to, in order to achieve decent performance).=C2=A0 Indi= vidual
> packets within an AMPDU are checksummed separately, and can be
> retransmitted individually or as part of the next AMPDU.=C2=A0 Right n= ow,
> reordering protection requires that IP packets (strictly, ethernet
> frames) that have been correctly received but are behind (in link-laye= r
> sequence number space) one that has not been received or explicitly > NAKed have to be buffered until receipt of the delaying frame or a NAK=
> or a rather long timeout.=C2=A0 Since the raw single-shot failure rate= can be
> up to around 45%, this happens a lot, and experiment indicates that if=
> the traffic is tolerant to a reasonable reordering window (as most
> current TCPs are, for example) end-to-end performance is significantly=
> better with reordering protection disabled.
>
> So yes, if reordering protection is off, packets within a single flow<= br> > will get reordered fairly frequently.

The client can still get through a NAT a few different ways:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - a gap (as suggested before)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - bursting a small number of copies of SYN/OOB = pairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the first SYN throu= gh a NAT would make way for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a following OOB

Indeed, those can work.
=C2=A0
First, though, tt'd be useful to understand what the error properties are, esp. whether they're burst or uncorrellated.
=
Tend to be bursty, there are some studies on this so data is= available.=C2=A0

And - with a single-shot failure rate that high, why FEC isn't being considered.

Joe

I don't know for sure, but if I ha= d to speculate I'd say the answer would be 'patents'.

--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|<= span style=3D"color:rgb(85,85,85);font-family:sans-serif;font-size:small;li= ne-height:1.5em;border-width:2px 0px 0px;border-style:solid;border-color:rg= b(0,153,57);padding-top:2px;margin-top:2px">=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a113b0166c5e9580507521bbe-- From nobody Sat Nov 8 12:58: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 77BD41A00BB for ; Sat, 8 Nov 2014 12:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 6RqmXL5GaBHt for ; Sat, 8 Nov 2014 12:58:18 -0800 (PST) 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 4A99E1A000A for ; Sat, 8 Nov 2014 12:58:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,341,1413270000"; d="scan'208";a="208988381" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx12-out.netapp.com with ESMTP; 08 Nov 2014 12:58:15 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 8 Nov 2014 12:58:15 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::38f3:c261:d32c:d223%21]) with mapi id 15.00.0995.031; Sat, 8 Nov 2014 12:58:15 -0800 From: "Zimmermann, Alexander" To: Joe Touch , "tcpm@ietf.org" Thread-Topic: Comments to draft-ietf-tcpm-tcp-edo-01 Thread-Index: AQHP+5a2cOj8sE61IEa95k8BL3Gntw== Date: Sat, 8 Nov 2014 20:58:14 +0000 Message-ID: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> 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.37] Content-Type: text/plain; charset="utf-8" Content-ID: <158C9F3107492D44BD9CDE22DB3B28F4@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/E_BR2YPUnZnxQGzxmTJVOSPYBYI Subject: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Sat, 08 Nov 2014 20:58:19 -0000 SGkgSm9lLA0KDQp5ZXN0ZXJkYXkgSSBmb3VuZCBzb21lIHRpbWUgdG8gcmUtcmVhZCB0aGUgZHJh ZnQuIEEgY291cGxlIG9mIHBvaW50cw0KDQoqKiogVGVjaG5pY2FsICoqKg0KDQoqIFRoZSB3aG9s ZSBkcmFmdHMgcmVhZHMgbGlrZSB3ZSBoYXZlICp0d28qIEVETyBvcHRpb25zLCBha2EgdGhlIOKA nlRDUCBFRE8NCnJlcXVlc3Qgb3B0aW9u4oCcIGFuZCB0aGUg4oCeVENQIEVETyBsZW5ndGggb3B0 aW9u4oCcLCBidXQgYWN0dWFsbHkgd2Ugb25seSBoYXZlDQpvbmUgb3B0aW9uLCB0aGUgRURPIG9w dGlvbi4gSSBmb3VuZCB0aGlzIGEgYml0IGNvbmZ1c2luZy4gU2F5aW5nIHRoaXMsIHdoeQ0KZG8g d2Ugbm90IGluY2x1ZGUgdGhlIEhlYWRlcl9sZW5ndGggZmllbGQgaW4gYW55IEVETyBmcmFtZSwg aS5lLiBhbHNvIGluDQp0aGUgU1lOLiBGb3Igc2lnbmFsaW5nIChFRE8gbmVnb3RpYXRpb24pIHdl IGNhbiB1c2UgdmFsdWVzIGZvciB0aGUNCkhlYWRlcl9sZW5ndGggdGhhdCBhcmUgbGVzcyB0aGFu IHRoZSBETyB2YWx1ZS4NCg0KKiBQYWdlIDQ6IOKAnkEgbnVsbCBFRE8gbGVuZ3RoIG9wdGlvbiBj b250YWlucyB0aGUgc2FtZSB2YWx1ZSBhcyB0aGUgRE8gZmllbGQsDQppLmUuLCBpdCBkb2VzIG5v dCBleHRlbmQgdGhlIFRDUCBvcHRpb24gc3BhY2XigJwgUGVyc29uYWxseSwgSSBkb27igJl0IGxp a2UgdGhlDQp0ZXJtIOKAnm51bGzigJwgYmVjYXVzZSBpdCBnaXZlcyAoYXQgbGVhc3QgbWUpIHRo ZSB3cm9uZyBpbXByZXNzaW9uIHRoYXQgdGhlDQpIZWFkZXJfbGVuZ3RoIGNvbnRhaW5zIDAuIENv dWxkIHdlIHNheSDigJ5uZXV0cmFs4oCcIGluc3RlYWQgb2Yg4oCebnVsbOKAnD8NCg0KKiBQYWdl IDU6IOKAnldoZW4gcHJvY2Vzc2luZyBhIHNlZ21lbnQsIEVETyBuZWVkcyB0byBiZSB2aXNpYmxl IHdpdGhpbiB0aGUNCmFyZWEgaW5kaWNhdGVkIGJ5IHRoZSBEYXRhIE9mZnNldCBmaWVsZOKAnC4g QmUgbW9yZSBleHBlY3QgaGVyZSwgYnkgc2F5aW5nDQp0aGF0IHRoZSBFRE8gb3B0aW9uIG11c3Qg YmUgaW4gdGhlIGZpcnN0IDQwIEJ5dGVzIGFmdGVyIHRoZSBmaXhlZCBUQ1ANCmhlYWRlci4gSU1P IGl0IG1ha2VzIGl0IGEgYml0IG1vcmUgY2xlYXJlci4NCg0KDQoqKiogRWRpdG9yaWFsICoqKg0K DQoqIFBhZ2UgNjogUGVyc29uYWxseSwgSSB3b3VsZCBzd2FwIHRoZSB0ZXh0IGFuZCBzcGVhayBm aXJzdCBhYm91dCB0aGUNCnBsYWNlbWVudCBvZiB0aGUgRURPIG9wdGlvbiBhbmQgdGhlbiBhYm91 dCB0aGUgYWxpZ25tZW50Lg0KDQoqIFNlY3Rpb24gNyBSZWxhdGVkIFdvcmsgLSBpbnRvIGFuIGFw cGVuZGl4Pw0KDQoNCioqKiBOaXRzICoqKg0KDQoqIHBhZ2UgMTM6IOKAnlRoZSBmb2xsb3dpbmcg ZGlzY3Vzc2VzIHRocmVlIG9mIHRoZSBtb3N0IG5vdGFibGUgcGFzdCDigKbigJwNCkFjdHVhbGx5 LCB5b3UgZGlzY3VzcyA0IGFwcHJvYWNoZXMuDQoNCiogU2VjLiAxMjogQWNrbm93bGVkZ21lbnRz LiBMYXN0IHdvcmQuIFRoZXJlIGlzIGEgbWlzc2luZyDigJ5u4oCcIGF0IHRoZQ0KZW5kIG9mIHRo ZSBuYW1lIDotKQ0KDQpBbGV4DQoNCg== From nobody Sat Nov 8 19:49: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 73F6D1A01F9 for ; Sat, 8 Nov 2014 19:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 2stT6gECL6Dg for ; Sat, 8 Nov 2014 19:49:48 -0800 (PST) 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 ED1031A0179 for ; Sat, 8 Nov 2014 19:49:47 -0800 (PST) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sA93nFDf014681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 8 Nov 2014 19:49:24 -0800 (PST) Message-ID: <545EE43D.6040401@isi.edu> Date: Sat, 08 Nov 2014 19:49:17 -0800 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: "Zimmermann, Alexander" , "tcpm@ietf.org" References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> In-Reply-To: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.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/BnDoB95r25XOuj1-qUXL2pp2cPM Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Sun, 09 Nov 2014 03:49:49 -0000 Hi, Alex, Thanks for the feedback. Some comments below. Joe On 11/8/2014 12:58 PM, Zimmermann, Alexander wrote: > Hi Joe, > > yesterday I found some time to re-read the draft. A couple of points > > *** Technical *** > > * The whole drafts reads like we have *two* EDO options, aka the „TCP EDO > request option“ and the „TCP EDO length option“, but actually we only have > one option, the EDO option. I found this a bit confusing. Saying this, why > do we not include the Header_length field in any EDO frame, i.e. also in > the SYN. For signaling (EDO negotiation) we can use values for the > Header_length that are less than the DO value. The SYN is the last place we want to burn space that has no purpose. That's why the option has two variants - the signal and the actual use. I'll see what I can do to clarify that. > * Page 4: „A null EDO length option contains the same value as the DO field, > i.e., it does not extend the TCP option space“ Personally, I don’t like the > term „null“ because it gives (at least me) the wrong impression that the > Header_length contains 0. Could we say „neutral“ instead of „null“? "redundant" might be more accurate; point taken. > * Page 5: „When processing a segment, EDO needs to be visible within the > area indicated by the Data Offset field“. Be more expect here, by saying > that the EDO option must be in the first 40 Bytes after the fixed TCP > header. IMO it makes it a bit more clearer. I will clarify, but it's not that it's just in the first 40 bytes. It's that it's within the space indicated by DO as well (DO can be less than 15 - and EDO needs to be visible within that area). > *** Editorial *** > > * Page 6: Personally, I would swap the text and speak first about the > placement of the EDO option and then about the alignment. > > * Section 7 Related Work - into an appendix? I don't have the draft in front of me; I'll take a look at these as well, but I'd like to hear from others before making such changes. > *** Nits *** > > * page 13: „The following discusses three of the most notable past …“ > Actually, you discuss 4 approaches. Agreed; this isn't a Monty Python skit ;-) > * Sec. 12: Acknowledgments. Last word. There is a missing „n“ at the > end of the name :-) Will fix, of course. --- From nobody Sun Nov 9 04:18: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 841D31A1A9F for ; Sun, 9 Nov 2014 04:18:11 -0800 (PST) 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 72yHXSeURo7Q for ; Sun, 9 Nov 2014 04:18:07 -0800 (PST) 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 A60CA1A1A9E for ; Sun, 9 Nov 2014 04:18:06 -0800 (PST) X-Spam-Processed: mail.kau.se, Sun, 09 Nov 2014 13:17:45 +0100 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 213.113.181.94 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <545F5B71.5090906@kau.se> Date: Sun, 09 Nov 2014 13:17:53 +0100 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, michael.scharf@alcatel-lucent.com References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> <544ED2B8.4020208@kau.se> <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TMq51kpCVfY5IVhJ7M4p5tH_T6o Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-04 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, 09 Nov 2014 12:18:11 -0000 Hi Michael, Thanks for your comments! Replies inline below. On 2014-11-03 00:33, Scharf, Michael (Michael) wrote: > Hi, > > I've read -04 and I have a couple of questions and suggestions: > > * Section 4: The "total number of outstanding and previously unsent seg= ments" in sum of two variables, right? If so, why not use the term "sum"?= Correct, so "sum" is better. We will update this. > > * Section 4: I also wonder if the text should define "previously unsent= segments". The term "previously unsent data" is very well-known in the R= FC series. A quick search revealed that "previously unsent segments" is u= sually only used to refer to situations when segments with this property = have indeed been transmitted. Is my understanding correct that draft-ietf= -tcpm-rtorestart-04 uses this term differently? I think it here refers to= data that will be sent *in future*. In that case, I wonder if it is real= ly clear how the sender can determine the number of "previously unsent se= gments". For instance, that number may depend on the segmentation strateg= y of the sender, in particular for applications that use many small write= () calls. In this case a TCP stack may e.g. decide to send partial segmen= ts. I am not sure if the actual number of segments created from the "unse= nt data" is really known in advance always. Or do I miss something? You are correct that "previously unsent segments" refers to data that=20 will be sent in the future. This is the same meaning as in RFC 3517 and=20 RFC 4653. A definition of this term could be added to Section 2, but I=20 am not sure if it is needed? To better understand the possible conflict=20 in terminology, could you point to some of RFCs that use the term to=20 refer to already transmitted segments? Intuitively that seems a bit=20 strange to me. As discussed in section 5.3, the number of unsent segments can be=20 estimated from the amount of unsent data and the SMSS. Note that we are=20 only talking about data that is already available in the send queue, and = later write calls can of course create additional segments. I guess a=20 TCP stack that has one SMSS of data in its send queue is free to send=20 this as multiple segments if it wants to, but I assume that would not be = the normal behavior. As the estimate is not very critical it is not=20 really a problem if this happens occasionally. The addition of "previously unsent segments" is there to capture a=20 corner case (see issue raised by Alex in=20 http://www.ietf.org/mail-archive/web/tcpm/current/msg08780.html), so it=20 will only be occasionally used. If we then get an incorrect estimate,=20 say a sender with one SMSS of data would instead send this as two SMSS,=20 and the algorithm triggers "incorrectly", this would be equivalent to=20 using a RTOR threshold of rrthresh + 1 so nothing critical happens. (In=20 some cases rrthresh + 1 may even be better.) > > * Section 5.1: "Given RTOR's ability to only work when it is beneficial= for the loss recovery process, it is suitable as a system-wide default m= echanism for TCP traffic." I think other text in the draft asks for furth= er experimentation regarding the actual trade-off between benefit and ris= k. Given that, I think another wording should be used (e.g., "Given that = RTOR is a mostly conservative algorithm", ...). Given that this is not a = PS document, I'd also prefer a more careful phrasing regarding the recomm= endation as system-wide default (e.g., "it is suitable for experimentatio= n as system-wide default"). Agreed, we will update the text. > * Section 5.2: As mentioned in the last face-to-face meeting, spurious = timeout negatively affect the network by needlessly sending data. This ne= gative effect is not mentioned in this section. Why? The initial intention was to focus on aspects of spurious timeouts that=20 were specific to RTOR. But looking at the text I see that this is not at = all clear in the current version. The best resolution is probably to not = try to scope it that way. We can add some text also about the increased=20 network load in the next version. > > * Section 5.2: Mobile networks have a variable RTT, including e.g. long= er delays during handovers (either without or with transient loss during = the handover). A lot of past work on spurious timeout recovery has been m= otivated by these delay spikes. Reducing the RTO almost certainly has an = impact in such environments; I think performance can both increase or dec= rease. If no data on that is available, mobile networks seem to me an are= a where more experimentation would be particularly useful, right? Yes, as the RTTs in mobile networks can be higher and are often variable = it is an interesting area. It could be mentioned as an example in 5.2. > > * Section 5.2: Is there any data on the risk of spurious timeouts in ne= tworks where RTT and the minimum RTO are of the same order of magnitude? = For instance, in satellite networks the RTT can be huge. Our Linux experiments over emulated networks cover RTTs that go beyond=20 the value of the minimum RTO, i.e. RTTs larger than 200 ms, see=20 http://riteproject.eu/resources/rto-restart/ for some sample results. I=20 am not aware of any real experiments in satellite networks or similar. A = general problem when experimenting with this is that spurious timeouts=20 happen only occasionally so a lot of data is needed before you can=20 determine any trends. > > * Section 5.2: "However, with respect to RTOR spurious timeouts are onl= y a problem for applications transmitting multiple bursts of data within = a single flow." I think this section should be reworded and it should mor= e explicitly discuss the impact of RTOR on HTTP/1.1 and HTTP/2.0 traffic,= including e.g. adaptive video streaming. They all transmit "multiple bur= sts of data within a single flow". To me, the current sentence could impl= y that RTOR would be a "problem" for a vast majority of Internet traffic.= A more explicit discussion on how RTOR affects HTTP/1.1 and HTTP/2.0 wou= ld IMHO make a lot of sense. Ok, we will work on the wording and use HTTP as an example. And also try = to better highlight the tradeoffs involved. In our experiments with=20 HTTP/1.1 traffic RTOR performs better than the baseline. > > * Section 5.3: Given that not all stacks are segment-based, this sectio= n seems really relevant. However, the description how to determine outsta= nding segments is vague ("it is possible to exactly determine..."). I thi= nk this could be reworded to provide more guidance to implementers. The s= ame applies to the calculation of "previously unsent segments"; for insta= nce, the text does not explain what happens if the "number of bytes in th= e send queue" is not a multiple of the SMSS (see also above regarding the= definition of this variable). OK, we can reuse the full discussion on how to determine outstanding=20 segments from RFC 5827 rather than summarizing and pointing to it. We=20 can of course also clarify the number of segments to be estimated when=20 the "number of bytes in the send queue" is not a multiple of the SMSS. I = somehow thought this was obvious. > > * Section 6: "In contrast, RTOR is trying to make the RTO more appropri= ate in cases where there is no need to be overly cautious." I think this = sentence should use a more neutral language. I think whether an RTO value= is "appropriate" is impossible to know (in advance), and whether a more = aggressive timeout is "cautious" or not may depend on the network under c= onsideration. For instance, an alternative would be to compare the comple= xity of RTOR and TLP. Ok. We will look over the wording in this part. > > * Section 9: I wonder if an attacker could try to send certain ACK patt= erns to increase the risk of timeouts e.g. at a Web Server, leveraging th= e smaller RTO value. If successful, the RTOs could significantly reduce a= pplication performance. Probably, such an attacker could cause much more = harm by other means, i.e., this may not be a significant security risk. B= ut the current security analysis is very short. The section is very short, but this is because we do not really see any=20 new security issues. If I understand your example above correctly, the receiver is trying=20 to somehow reduce performance for its own application by manipulating=20 the ACK pattern. But if you are trying to mess up things for your own=20 application you can deliver incorrect data, throw away any data received = or do whatever you want so I do not think trying to possibly slow down=20 the sender is the thing to worry about in this attack scenario. If=20 someone finds a relevant security issue it should of course be=20 documented, but I do not think it makes sense to put in something like=20 the above just to make the section longer. Thanks again for your comments! Cheers, Anna > > Thanks > > Michael > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Per Hurtig >> Sent: Tuesday, October 28, 2014 12:18 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-04.txt >> >> 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" <=3D= 0, >> to avoid that ACKs to previous retransmissions trigger premature >> timeouts. >> o Made minor adjustments throughout the document to adjust for th= e >> 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 TC= P >> 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 restar= t >> 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=3Ddraft-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 >>> >> _______________________________________________ >> 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 Sun Nov 9 11:54: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 5A0731A6FD4 for ; Sun, 9 Nov 2014 11:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 OkQSGtmkETgN for ; Sun, 9 Nov 2014 11:54:35 -0800 (PST) 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 24A001A6FCE for ; Sun, 9 Nov 2014 11:54:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,347,1413270000"; d="scan'208";a="209140150" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx12-out.netapp.com with ESMTP; 09 Nov 2014 11:54:34 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 9 Nov 2014 11:54:34 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5d98:1529:da8c:ea24%21]) with mapi id 15.00.0995.031; Sun, 9 Nov 2014 11:54:34 -0800 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: Comments to draft-ietf-tcpm-tcp-edo-01 Thread-Index: AQHP+5a2cOj8sE61IEa95k8BL3Gnt5xYLzSAgAENAIA= Date: Sun, 9 Nov 2014 19:54:33 +0000 Message-ID: <8C313EA6-C345-4E38-9D18-01F53F8AD9B8@netapp.com> References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> <545EE43D.6040401@isi.edu> In-Reply-To: <545EE43D.6040401@isi.edu> 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: <25301C09ECAC044DB6A528F11F56F95B@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ytE8I_bhbpxdz5h3NSGmk8H9AL8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Sun, 09 Nov 2014 19:54:36 -0000 SGkgSm9lLA0KDQo+IEFtIDA4LjExLjIwMTQgdW0gMTc6NDkgc2NocmllYiBKb2UgVG91Y2ggPHRv dWNoQGlzaS5lZHU+Og0KPiANCj4gSGksIEFsZXgsDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBmZWVk YmFjay4NCj4gDQo+IFNvbWUgY29tbWVudHMgYmVsb3cuDQo+IA0KPiBKb2UNCj4gDQo+IE9uIDEx LzgvMjAxNCAxMjo1OCBQTSwgWmltbWVybWFubiwgQWxleGFuZGVyIHdyb3RlOg0KPj4gSGkgSm9l LA0KPj4gDQo+PiB5ZXN0ZXJkYXkgSSBmb3VuZCBzb21lIHRpbWUgdG8gcmUtcmVhZCB0aGUgZHJh ZnQuIEEgY291cGxlIG9mIHBvaW50cw0KPj4gDQo+PiAqKiogVGVjaG5pY2FsICoqKg0KPj4gDQo+ PiAqIFRoZSB3aG9sZSBkcmFmdHMgcmVhZHMgbGlrZSB3ZSBoYXZlICp0d28qIEVETyBvcHRpb25z LCBha2EgdGhlIOKAnlRDUCBFRE8NCj4+IHJlcXVlc3Qgb3B0aW9u4oCcIGFuZCB0aGUg4oCeVENQ IEVETyBsZW5ndGggb3B0aW9u4oCcLCBidXQgYWN0dWFsbHkgd2Ugb25seSBoYXZlDQo+PiBvbmUg b3B0aW9uLCB0aGUgRURPIG9wdGlvbi4gSSBmb3VuZCB0aGlzIGEgYml0IGNvbmZ1c2luZy4gU2F5 aW5nIHRoaXMsIHdoeQ0KPj4gZG8gd2Ugbm90IGluY2x1ZGUgdGhlIEhlYWRlcl9sZW5ndGggZmll bGQgaW4gYW55IEVETyBmcmFtZSwgaS5lLiBhbHNvIGluDQo+PiB0aGUgU1lOLiBGb3Igc2lnbmFs aW5nIChFRE8gbmVnb3RpYXRpb24pIHdlIGNhbiB1c2UgdmFsdWVzIGZvciB0aGUNCj4+IEhlYWRl cl9sZW5ndGggdGhhdCBhcmUgbGVzcyB0aGFuIHRoZSBETyB2YWx1ZS4NCj4gDQo+IFRoZSBTWU4g aXMgdGhlIGxhc3QgcGxhY2Ugd2Ugd2FudCB0byBidXJuIHNwYWNlIHRoYXQgaGFzIG5vIHB1cnBv c2UuDQoNCk9LLCBJIHNlZS4gUG9pbnQgdGFrZW4uIEJ1dCB0aGUgc2FtZSBhcHBsaWVzIHRvIHRo ZSBTWU4vQUNLIHRvby4gU28sDQphZGRpdGlvbmFsIHF1ZXN0aW9uOiB3aHkgZG8gd2Ugbm90IHNl bmQg4oCeVENQIEVETyByZXF1ZXN0IG9wdGlvbuKAnCBiYWNrDQp0byB0aGUgY2xpZW50Pw0KDQpN b3Jlb3Zlciwgdy8gUkZDMjAxOCB3ZSBoYXZlIG1vcmUgb3IgbGVzcyB0aGUgc2FtZS4gU29tZSBu ZWdvdGlhdGlvbiBhbmQNCnRoZSBhY3R1YWwgdXNhZ2Ugb2YgdGhlIG9wdGlvbi4gQW55IGhhcm0g dG8gYnVybiB0d28g4oCea2luZHPigJwgbGlrZSBSRkMyMDE4Pw0KDQoNCj4gVGhhdCdzIHdoeSB0 aGUgb3B0aW9uIGhhcyB0d28gdmFyaWFudHMgLSB0aGUgc2lnbmFsIGFuZCB0aGUgYWN0dWFsIHVz ZS4NCj4gSSdsbCBzZWUgd2hhdCBJIGNhbiBkbyB0byBjbGFyaWZ5IHRoYXQuDQo+IA0KDQo= From nobody Sun Nov 9 12:01: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 9D2A81A6FEF for ; Sun, 9 Nov 2014 12:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 7tJTS3yFGDQE for ; Sun, 9 Nov 2014 12:01:01 -0800 (PST) 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 5A8971A6FE7 for ; Sun, 9 Nov 2014 12:01:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,347,1413270000"; d="scan'208";a="166264808" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx11-out.netapp.com with ESMTP; 09 Nov 2014 12:01:01 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 9 Nov 2014 12:01:00 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5d98:1529:da8c:ea24%21]) with mapi id 15.00.0995.031; Sun, 9 Nov 2014 12:01:00 -0800 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: Comments to draft-ietf-tcpm-tcp-edo-01 Thread-Index: AQHP+5a2cOj8sE61IEa95k8BL3Gnt5xYLzSAgAENs4A= Date: Sun, 9 Nov 2014 20:00:59 +0000 Message-ID: References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> <545EE43D.6040401@isi.edu> In-Reply-To: <545EE43D.6040401@isi.edu> 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.37] Content-Type: text/plain; charset="utf-8" Content-ID: <883CEC73EFD93C4EAF4059496F8B0CBD@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YHSmbmQFX9WfHSLq2tzZWFfROqI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Sun, 09 Nov 2014 20:01:02 -0000 SGkgSm9lLA0KDQo+IEFtIDA4LjExLjIwMTQgdW0gMTc6NDkgc2NocmllYiBKb2UgVG91Y2ggPHRv dWNoQGlzaS5lZHU+Og0KPiANCj4gSGksIEFsZXgsDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBmZWVk YmFjay4NCj4gDQo+IFNvbWUgY29tbWVudHMgYmVsb3cuDQo+IA0KPiBKb2UNCj4gDQo+IE9uIDEx LzgvMjAxNCAxMjo1OCBQTSwgWmltbWVybWFubiwgQWxleGFuZGVyIHdyb3RlOg0KPj4gSGkgSm9l LA0KPj4gDQo+PiB5ZXN0ZXJkYXkgSSBmb3VuZCBzb21lIHRpbWUgdG8gcmUtcmVhZCB0aGUgZHJh ZnQuIEEgY291cGxlIG9mIHBvaW50cw0KPj4gDQo+PiAqKiogVGVjaG5pY2FsICoqKg0KPj4gDQo+ PiAqIFRoZSB3aG9sZSBkcmFmdHMgcmVhZHMgbGlrZSB3ZSBoYXZlICp0d28qIEVETyBvcHRpb25z LCBha2EgdGhlIOKAnlRDUCBFRE8NCj4+IHJlcXVlc3Qgb3B0aW9u4oCcIGFuZCB0aGUg4oCeVENQ IEVETyBsZW5ndGggb3B0aW9u4oCcLCBidXQgYWN0dWFsbHkgd2Ugb25seSBoYXZlDQo+PiBvbmUg b3B0aW9uLCB0aGUgRURPIG9wdGlvbi4gSSBmb3VuZCB0aGlzIGEgYml0IGNvbmZ1c2luZy4gU2F5 aW5nIHRoaXMsIHdoeQ0KPj4gZG8gd2Ugbm90IGluY2x1ZGUgdGhlIEhlYWRlcl9sZW5ndGggZmll bGQgaW4gYW55IEVETyBmcmFtZSwgaS5lLiBhbHNvIGluDQo+PiB0aGUgU1lOLiBGb3Igc2lnbmFs aW5nIChFRE8gbmVnb3RpYXRpb24pIHdlIGNhbiB1c2UgdmFsdWVzIGZvciB0aGUNCj4+IEhlYWRl cl9sZW5ndGggdGhhdCBhcmUgbGVzcyB0aGFuIHRoZSBETyB2YWx1ZS4NCj4gDQo+IFRoZSBTWU4g aXMgdGhlIGxhc3QgcGxhY2Ugd2Ugd2FudCB0byBidXJuIHNwYWNlIHRoYXQgaGFzIG5vIHB1cnBv c2UuDQoNCk9LLCBJIHNlZS4gUG9pbnQgdGFrZW4uIEJ1dCB0aGUgc2FtZSBhcHBsaWVzIHRvIHRo ZSBTWU4vQUNLIHRvby4gU28sDQphZGRpdGlvbmFsIHF1ZXN0aW9uOiB3aHkgZG8gd2Ugbm90IHNl bmQg4oCeVENQIEVETyByZXF1ZXN0IG9wdGlvbuKAnCBiYWNrDQp0byB0aGUgY2xpZW50Pw0KDQpN b3Jlb3Zlciwgdy8gUkZDMjAxOCB3ZSBoYXZlIG1vcmUgb3IgbGVzcyB0aGUgc2FtZS4gU29tZSBu ZWdvdGlhdGlvbiBhbmQNCnRoZSBhY3R1YWwgdXNhZ2Ugb2YgdGhlIG9wdGlvbi4gQW55IGhhcm0g dG8gYnVybiB0d28g4oCea2luZHPigJwgbGlrZSBSRkMyMDE4Pw0KDQoNCj4gVGhhdCdzIHdoeSB0 aGUgb3B0aW9uIGhhcyB0d28gdmFyaWFudHMgLSB0aGUgc2lnbmFsIGFuZCB0aGUgYWN0dWFsIHVz ZS4NCj4gSSdsbCBzZWUgd2hhdCBJIGNhbiBkbyB0byBjbGFyaWZ5IHRoYXQuDQo+IA0KDQo= From nobody Sun Nov 9 12:04: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 0FE5B1A6FFC for ; Sun, 9 Nov 2014 12:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 veoSLCGAD-_9 for ; Sun, 9 Nov 2014 12:04:55 -0800 (PST) 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 E37D41A6FF9 for ; Sun, 9 Nov 2014 12:04:54 -0800 (PST) Received: from [192.168.1.5] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sA9K3dAa003179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 9 Nov 2014 12:03:49 -0800 (PST) Message-ID: <545FC89D.5090307@isi.edu> Date: Sun, 09 Nov 2014 12:03:41 -0800 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: "Zimmermann, Alexander" References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> <545EE43D.6040401@isi.edu> <8C313EA6-C345-4E38-9D18-01F53F8AD9B8@netapp.com> In-Reply-To: <8C313EA6-C345-4E38-9D18-01F53F8AD9B8@netapp.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/NQKqomamPn8kh49GcVGUIwRU3Oc Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Sun, 09 Nov 2014 20:04:56 -0000 Comments below... On 11/9/2014 11:54 AM, Zimmermann, Alexander wrote: > Hi Joe, > >> Am 08.11.2014 um 17:49 schrieb Joe Touch : >> >> Hi, Alex, >> >> Thanks for the feedback. >> >> Some comments below. >> >> Joe >> >> On 11/8/2014 12:58 PM, Zimmermann, Alexander wrote: >>> Hi Joe, >>> >>> yesterday I found some time to re-read the draft. A couple of points >>> >>> *** Technical *** >>> >>> * The whole drafts reads like we have *two* EDO options, aka the „TCP EDO >>> request option“ and the „TCP EDO length option“, but actually we only have >>> one option, the EDO option. I found this a bit confusing. Saying this, why >>> do we not include the Header_length field in any EDO frame, i.e. also in >>> the SYN. For signaling (EDO negotiation) we can use values for the >>> Header_length that are less than the DO value. >> >> The SYN is the last place we want to burn space that has no purpose. > > OK, I see. Point taken. But the same applies to the SYN/ACK too. Yes. The SYN/ACK either needs to similarly conserve space and use just the flag variant *if* EDO extension isn't allowed (that's how the current spec is written). If we allow use of the EDO extension space in the SYN/ACK (e.g., if we're not as worried about asymmetric middlebox corruption), then we'd use the regular EDO variant which would extend the space --- in that case, the space the option consumes isn't an issue. > So, > additional question: why do we not send „TCP EDO request option“ back > to the client? That's what the current draft says to do for SYN/ACK, for the reason above. > Moreover, w/ RFC2018 we have more or less the same. Some negotiation and > the actual usage of the option. Any harm to burn two „kinds“ like RFC2018? We've since learned better ;-) In specific, we want fate-sharing of the option kind. We don't want the impact of a bug that works on one kind but doesn't handle the other. There's also no benefit. The difference between the option types can be determined by the length of a single type. Joe From nobody Sun Nov 9 13:28: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 CC96F1A854D for ; Sun, 9 Nov 2014 13:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 W1v1FJNjjHcI for ; Sun, 9 Nov 2014 13:28:31 -0800 (PST) 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 BBE141A014E for ; Sun, 9 Nov 2014 13:28:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,347,1413270000"; d="scan'208";a="166269273" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx11-out.netapp.com with ESMTP; 09 Nov 2014 13:28:27 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 9 Nov 2014 13:28:26 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5d98:1529:da8c:ea24%21]) with mapi id 15.00.0995.031; Sun, 9 Nov 2014 13:28:26 -0800 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: Comments to draft-ietf-tcpm-tcp-edo-01 Thread-Index: AQHP+5a2cOj8sE61IEa95k8BL3Gnt5xYLzSAgAENAICAAAM+gIAAFbOA Date: Sun, 9 Nov 2014 21:28:25 +0000 Message-ID: <6A7ACDBB-16BF-478C-83D1-C27B8BBF1937@netapp.com> References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> <545EE43D.6040401@isi.edu> <8C313EA6-C345-4E38-9D18-01F53F8AD9B8@netapp.com> <545FC89D.5090307@isi.edu> In-Reply-To: <545FC89D.5090307@isi.edu> 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.37] Content-Type: text/plain; charset="utf-8" Content-ID: <979B6338DC57AD47AA267DEF5DA94B86@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/T8KFjJRbOLOfXhNgMa0wYWKO8xo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Sun, 09 Nov 2014 21:28:35 -0000 DQo+IEFtIDA5LjExLjIwMTQgdW0gMTA6MDMgc2NocmllYiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5l ZHU+Og0KPiANCj4gQ29tbWVudHMgYmVsb3figKYNCg0KRGl0bw0KDQo+IA0KPiBPbiAxMS85LzIw MTQgMTE6NTQgQU0sIFppbW1lcm1hbm4sIEFsZXhhbmRlciB3cm90ZToNCj4+IEhpIEpvZSwNCj4+ IA0KPj4+IEFtIDA4LjExLjIwMTQgdW0gMTc6NDkgc2NocmllYiBKb2UgVG91Y2ggPHRvdWNoQGlz aS5lZHU+Og0KPj4+IA0KPj4+IEhpLCBBbGV4LA0KPj4+IA0KPj4+IFRoYW5rcyBmb3IgdGhlIGZl ZWRiYWNrLg0KPj4+IA0KPj4+IFNvbWUgY29tbWVudHMgYmVsb3cuDQo+Pj4gDQo+Pj4gSm9lDQo+ Pj4gDQo+Pj4gT24gMTEvOC8yMDE0IDEyOjU4IFBNLCBaaW1tZXJtYW5uLCBBbGV4YW5kZXIgd3Jv dGU6DQo+Pj4+IEhpIEpvZSwNCj4+Pj4gDQo+Pj4+IHllc3RlcmRheSBJIGZvdW5kIHNvbWUgdGlt ZSB0byByZS1yZWFkIHRoZSBkcmFmdC4gQSBjb3VwbGUgb2YgcG9pbnRzDQo+Pj4+IA0KPj4+PiAq KiogVGVjaG5pY2FsICoqKg0KPj4+PiANCj4+Pj4gKiBUaGUgd2hvbGUgZHJhZnRzIHJlYWRzIGxp a2Ugd2UgaGF2ZSAqdHdvKiBFRE8gb3B0aW9ucywgYWthIHRoZSDigJ5UQ1AgRURPDQo+Pj4+IHJl cXVlc3Qgb3B0aW9u4oCcIGFuZCB0aGUg4oCeVENQIEVETyBsZW5ndGggb3B0aW9u4oCcLCBidXQg YWN0dWFsbHkgd2Ugb25seSBoYXZlDQo+Pj4+IG9uZSBvcHRpb24sIHRoZSBFRE8gb3B0aW9uLiBJ IGZvdW5kIHRoaXMgYSBiaXQgY29uZnVzaW5nLiBTYXlpbmcgdGhpcywgd2h5DQo+Pj4+IGRvIHdl IG5vdCBpbmNsdWRlIHRoZSBIZWFkZXJfbGVuZ3RoIGZpZWxkIGluIGFueSBFRE8gZnJhbWUsIGku ZS4gYWxzbyBpbg0KPj4+PiB0aGUgU1lOLiBGb3Igc2lnbmFsaW5nIChFRE8gbmVnb3RpYXRpb24p IHdlIGNhbiB1c2UgdmFsdWVzIGZvciB0aGUNCj4+Pj4gSGVhZGVyX2xlbmd0aCB0aGF0IGFyZSBs ZXNzIHRoYW4gdGhlIERPIHZhbHVlLg0KPj4+IA0KPj4+IFRoZSBTWU4gaXMgdGhlIGxhc3QgcGxh Y2Ugd2Ugd2FudCB0byBidXJuIHNwYWNlIHRoYXQgaGFzIG5vIHB1cnBvc2UuDQo+PiANCj4+IE9L LCBJIHNlZS4gUG9pbnQgdGFrZW4uIEJ1dCB0aGUgc2FtZSBhcHBsaWVzIHRvIHRoZSBTWU4vQUNL IHRvby4gDQo+IA0KPiBZZXMuIFRoZSBTWU4vQUNLIGVpdGhlciBuZWVkcyB0byBzaW1pbGFybHkg Y29uc2VydmUgc3BhY2UgYW5kIHVzZSBqdXN0DQo+IHRoZSBmbGFnIHZhcmlhbnQgKmlmKiBFRE8g ZXh0ZW5zaW9uIGlzbid0IGFsbG93ZWQgKHRoYXQncyBob3cgdGhlDQo+IGN1cnJlbnQgc3BlYyBp cyB3cml0dGVuKS4NCj4gDQo+IElmIHdlIGFsbG93IHVzZSBvZiB0aGUgRURPIGV4dGVuc2lvbiBz cGFjZSBpbiB0aGUgU1lOL0FDSyAoZS5nLiwgaWYNCj4gd2UncmUgbm90IGFzIHdvcnJpZWQgYWJv dXQgYXN5bW1ldHJpYyBtaWRkbGVib3ggY29ycnVwdGlvbiksIHRoZW4gd2UnZA0KPiB1c2UgdGhl IHJlZ3VsYXIgRURPIHZhcmlhbnQgd2hpY2ggd291bGQgZXh0ZW5kIHRoZSBzcGFjZSAtLS0gaW4g dGhhdA0KPiBjYXNlLCB0aGUgc3BhY2UgdGhlIG9wdGlvbiBjb25zdW1lcyBpc24ndCBhbiBpc3N1 ZS4NCj4gDQo+PiBTbywNCj4+IGFkZGl0aW9uYWwgcXVlc3Rpb246IHdoeSBkbyB3ZSBub3Qgc2Vu ZCDigJ5UQ1AgRURPIHJlcXVlc3Qgb3B0aW9u4oCcIGJhY2sNCj4+IHRvIHRoZSBjbGllbnQ/DQo+ IA0KPiBUaGF04oCZcyB3aGF0IHRoZSBjdXJyZW50IGRyYWZ0IHNheXMgdG8gZG8gZm9yIFNZTi9B Q0ssIGZvciB0aGUgcmVhc29uIGFib3ZlLg0KDQpJTU8sIHRoYXQgbm90IHRoZSBjYXNlLiBQYWdl IDQsIHNlYyA0LCBzZWNvbmQgcGFyYToNCg0K4oCeIElmIHJlY2VpdmVyIG9mIHRoYXQgU1lOIGFn cmVlcyB0byBzdXBwb3J0IEVETywgaXQgcmVzcG9uZHMgd2l0aCBhIG51bGwgRURPDQpsZW5ndGgg b3B0aW9uIGluIHRoZSBTWU4vQUNLLiBBIG51bGwgRURPIGxlbmd0aCBvcHRpb24gY29udGFpbnMg dGhlIHNhbWUgdmFsdWUNCmFzIHRoZSBETyBmaWVsZCwgaS5lLiwgaXQgZG9lcyBub3QgZXh0ZW5k IHRoZSBUQ1Agb3B0aW9uIHNwYWNlLuKAnA0KDQpJZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0 bHkgdGhlIHNlcnZlciBzZW5kcyBiYWNrIHRoZSDigJ5UQ1AgRURPIGxlbmd0aCBvcHRpb27igJwN Cm1lYW5pbmcgdGhhdCB0aGUg4oCeSGVhZGVyX2xlbmd0aOKAnCBpcyBub24gZW1wdHkuIElmIHdl IGFsbCBhZ3JlZSAoYW5kIEnigJltIG5vdCBzdXJlDQphYm91dCB0aGlzKSB0aGF0IGFzeW1tZXRy aWMgbWlkZGxlIGJveCBjb3JydXB0aW9uIGlzIGNvbW1vbiBhbmQgd2UgY2Fubm90DQpleHRlbnQg dGhlIG9wdGlvbiBzcGFjZSBpbiBhIFNZTi9BQ0sgdmlhIEVETywgd2h5IHdlIGNvdWxkIG5vdCBl Y2hvIGJhY2s6DQoNCistLS0tLS0tLSstLS0tLS0tLSsNCnwgIEtpbmQgIHwgTGVuZ3RoIHwNCist LS0tLS0tLSstLS0tLS0tLSsNCg0KZnJvbSB0aGUgc2VydmVyIHNpZGU/DQoNCkFsZXgNCg0KPiAN Cj4gDQo+PiBNb3Jlb3Zlciwgdy8gUkZDMjAxOCB3ZSBoYXZlIG1vcmUgb3IgbGVzcyB0aGUgc2Ft ZS4gU29tZSBuZWdvdGlhdGlvbiBhbmQNCj4+IHRoZSBhY3R1YWwgdXNhZ2Ugb2YgdGhlIG9wdGlv bi4gQW55IGhhcm0gdG8gYnVybiB0d28g4oCea2luZHPigJwgbGlrZSBSRkMyMDE4Pw0KPiANCj4g V2UndmUgc2luY2UgbGVhcm5lZCBiZXR0ZXIgOy0pDQo+IA0KPiBJbiBzcGVjaWZpYywgd2Ugd2Fu dCBmYXRlLXNoYXJpbmcgb2YgdGhlIG9wdGlvbiBraW5kLiBXZSBkb24ndCB3YW50IHRoZQ0KPiBp bXBhY3Qgb2YgYSBidWcgdGhhdCB3b3JrcyBvbiBvbmUga2luZCBidXQgZG9lc24ndCBoYW5kbGUg dGhlIG90aGVyLg0KPiANCj4gVGhlcmUncyBhbHNvIG5vIGJlbmVmaXQuIFRoZSBkaWZmZXJlbmNl IGJldHdlZW4gdGhlIG9wdGlvbiB0eXBlcyBjYW4gYmUNCj4gZGV0ZXJtaW5lZCBieSB0aGUgbGVu Z3RoIG9mIGEgc2luZ2xlIHR5cGUuDQo+IA0KPiBKb2UNCg0K From nobody Sun Nov 9 16: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 A3A4F1A700A for ; Sun, 9 Nov 2014 16:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 OdsSXgrcx0_2 for ; Sun, 9 Nov 2014 16:36:32 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B39FE1A86E6 for ; Sun, 9 Nov 2014 16:36:32 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8CA2D28540; Mon, 10 Nov 2014 00:36:31 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 79CC82853B; Mon, 10 Nov 2014 00:36:31 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 1D19E80047; Mon, 10 Nov 2014 00:36:31 +0000 (GMT) Message-ID: <5460088F.6080104@akamai.com> Date: Sun, 09 Nov 2014 19:36:31 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Sujeet Nayak A (sua)" , "tcpm@ietf.org" References: 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/_rs7Fz4RqefA5qfDJT4J_JBQQPs Subject: Re: [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: Mon, 10 Nov 2014 00:36:34 -0000 Hi Sujeet, I'm still concerned about whether there's enough space in the SYN header for this option. My concern is based mostly on a what I think is a flaw in the analysis from RFC5925 section 7.2, which leaves out the 4-byte MSS option. As the analysis from RFC6824 indicates, SYN packets typically include the MSS option, leaving only 21 bytes available in an option packed SYN and 16 in a worst-case unpacked SYN. TCP-AO with SHA1 works in either case, but SHA2 only works (just barely) in an option packed stack. Section 4 of your draft should probably be updated to account for the commonality of the MSS option and the related requirement either to drop one of the common SYN options or pack the option space. --Brandon On 10/28/2014 02:12 AM, Sujeet Nayak A (sua) wrote: > 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 > draft (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 -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Sun Nov 9 16:39: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 60EDA1A87C3 for ; Sun, 9 Nov 2014 16:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.594] 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 I8YdzEFC4pRo for ; Sun, 9 Nov 2014 16:39:48 -0800 (PST) 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 1578B1A87C0 for ; Sun, 9 Nov 2014 16:39:48 -0800 (PST) Received: from [192.168.1.7] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id sAA0dWVr008420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Nov 2014 16:39:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (12B411) In-Reply-To: <6A7ACDBB-16BF-478C-83D1-C27B8BBF1937@netapp.com> Date: Sun, 9 Nov 2014 16:39:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <26FE4757-1FA1-4B63-ACE4-A734E624F1B4@isi.edu> References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> <545EE43D.6040401@isi.edu> <8C313EA6-C345-4E38-9D18-01F53F8AD9B8@netapp.com> <545FC89D.5090307@isi.edu> <6A7ACDBB-16BF-478C-83D1-C27B8BBF1937@netapp.com> To: "Zimmermann, Alexander" 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/HD_HDqSpXBrGAFeLQnxcsgiykEk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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, 10 Nov 2014 00:39:49 -0000 > On Nov 9, 2014, at 1:28 PM, Zimmermann, Alexander wrote: >=20 >=20 >> Am 09.11.2014 um 10:03 schrieb Joe Touch : >>=20 >> Comments below=E2=80=A6 >=20 > Dito >=20 >>=20 >>> On 11/9/2014 11:54 AM, Zimmermann, Alexander wrote: >>> Hi Joe, >>>=20 >>>> Am 08.11.2014 um 17:49 schrieb Joe Touch : >>>>=20 >>>> Hi, Alex, >>>>=20 >>>> Thanks for the feedback. >>>>=20 >>>> Some comments below. >>>>=20 >>>> Joe >>>>=20 >>>>> On 11/8/2014 12:58 PM, Zimmermann, Alexander wrote: >>>>> Hi Joe, >>>>>=20 >>>>> yesterday I found some time to re-read the draft. A couple of points >>>>>=20 >>>>> *** Technical *** >>>>>=20 >>>>> * The whole drafts reads like we have *two* EDO options, aka the =E2=80= =9ETCP EDO >>>>> request option=E2=80=9C and the =E2=80=9ETCP EDO length option=E2=80=9C= , but actually we only have >>>>> one option, the EDO option. I found this a bit confusing. Saying this,= why >>>>> do we not include the Header_length field in any EDO frame, i.e. also i= n >>>>> the SYN. For signaling (EDO negotiation) we can use values for the >>>>> Header_length that are less than the DO value. >>>>=20 >>>> The SYN is the last place we want to burn space that has no purpose. >>>=20 >>> OK, I see. Point taken. But the same applies to the SYN/ACK too. >>=20 >> Yes. The SYN/ACK either needs to similarly conserve space and use just >> the flag variant *if* EDO extension isn't allowed (that's how the >> current spec is written). >>=20 >> If we allow use of the EDO extension space in the SYN/ACK (e.g., if >> we're not as worried about asymmetric middlebox corruption), then we'd >> use the regular EDO variant which would extend the space --- in that >> case, the space the option consumes isn't an issue. >>=20 >>> So, >>> additional question: why do we not send =E2=80=9ETCP EDO request option=E2= =80=9C back >>> to the client? >>=20 >> That=E2=80=99s what the current draft says to do for SYN/ACK, for the rea= son above. >=20 > IMO, that not the case. Page 4, sec 4, second para: Yes. I had thought about that after the revision and thought I changed it.=20= >=20 > =E2=80=9E If receiver of that SYN agrees to support EDO, it responds with a= null EDO > length option in the SYN/ACK. A null EDO length option contains the same v= alue > as the DO field, i.e., it does not extend the TCP option space.=E2=80=9C >=20 > If I understand this correctly the server sends back the =E2=80=9ETCP EDO l= ength option=E2=80=9C > meaning that the =E2=80=9EHeader_length=E2=80=9C is non empty. If we all a= gree (and I=E2=80=99m not sure > about this) that asymmetric middle box corruption is common and we cannot > extent the option space in a SYN/ACK via EDO, why we could not echo back: >=20 > +--------+--------+ > | Kind | Length | > +--------+--------+ >=20 > from the server side? Yes. That's what I had intended but missed in the revision. Sorry for the co= nfusion. I'll fix in the next rev.=20 Joe >=20 > Alex >=20 >>=20 >>=20 >>> Moreover, w/ RFC2018 we have more or less the same. Some negotiation and= >>> the actual usage of the option. Any harm to burn two =E2=80=9Ekinds=E2=80= =9C like RFC2018? >>=20 >> We've since learned better ;-) >>=20 >> In specific, we want fate-sharing of the option kind. We don't want the >> impact of a bug that works on one kind but doesn't handle the other. >>=20 >> There's also no benefit. The difference between the option types can be >> determined by the length of a single type. >>=20 >> Joe >=20 From nobody Mon Nov 10 08:00:11 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 740981A0022 for ; Mon, 10 Nov 2014 08:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 QlPAahTZrWVx for ; Mon, 10 Nov 2014 08:00:00 -0800 (PST) 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 AF72D1A0035 for ; Mon, 10 Nov 2014 07:59:57 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5B14218ADC642; Mon, 10 Nov 2014 15:59:53 +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 sAAFxtAq020836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 16:59:56 +0100 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; Mon, 10 Nov 2014 16:59:55 +0100 From: "Scharf, Michael (Michael)" To: Anna Brunstrom , "tcpm@ietf.org" Thread-Topic: [tcpm] draft-ietf-tcpm-rtorestart-04 Thread-Index: AQHP9vVqrXJrvR/Ze0yRRPU/kEN2LZxYL7CAgAHTccA= Date: Mon, 10 Nov 2014 15:59:55 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16699B3C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20141027231119.14539.21372.idtracker@ietfa.amsl.com> <544ED2B8.4020208@kau.se> <655C07320163294895BBADA28372AF5D1669053B@FR712WXCHMBA15.zeu.alcatel-lucent.com> <545F5B71.5090906@kau.se> In-Reply-To: <545F5B71.5090906@kau.se> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/B933CeAj3DBS-I6ZdU7vtQBWIaE Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-04 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, 10 Nov 2014 16:00:06 -0000 Hi Anna, Some follow-up comments. I omit the parts for which there seems to be agree= ment on the need for a document update. > > * Section 4: I also wonder if the text should define "previously > unsent segments". The term "previously unsent data" is very well-known > in the RFC series. A quick search revealed that "previously unsent > segments" is usually only used to refer to situations when segments > with this property have indeed been transmitted. Is my understanding > correct that draft-ietf-tcpm-rtorestart-04 uses this term differently? > I think it here refers to data that will be sent *in future*. In that > case, I wonder if it is really clear how the sender can determine the > number of "previously unsent segments". For instance, that number may > depend on the segmentation strategy of the sender, in particular for > applications that use many small write() calls. In this case a TCP > stack may e.g. decide to send partial segments. I am not sure if the > actual number of segments created from the "unsent data" is really > known in advance always. Or do I miss something? >=20 > You are correct that "previously unsent segments" refers to data that > will be sent in the future. This is the same meaning as in RFC 3517 and > RFC 4653. A definition of this term could be added to Section 2, but I > am not sure if it is needed? To better understand the possible conflict > in terminology, could you point to some of RFCs that use the term to > refer to already transmitted segments? Intuitively that seems a bit > strange to me. I didn't say that there is a conflict in terminology. I might be wrong, but= to me draft-ietf-tcpm-rtorestart-04 defines the term "previously unsent se= gments" as a *new* TCP state variable. The value of that variable may be obvious for certain architectures of a TC= P stack, in particular if segmentation into packets occurs on socket write(= ) calls, i.e., before data is actually sent to network. As far as I recall,= this is how the Linux stack works internally. But I'd like to avoid that a= n RFC describes an algorithm that can only be implemented for certain archi= tecture of a TCP stack. RFC 3517 and RFC 4653 either refer to the "amount of previously unsent data= " (which doesn't need to be further defined IMHO), or the "transmission of = previously unsent segments" (which is not what draft-ietf-tcpm-rtorestart-0= 4 refers to). For instance, here is the exact wording of the closest matche= s I could find in RFC 3517 and RFC 4563: RFC 3517 Section 5 Processing and Acting Upon SACK Information "(2) If no sequence number 'S2' per rule (1) exists but there exists available unsent data and the receiver's advertised window allows, the sequence range of one segment of up to SMSS octets of previously unsent data starting with sequence number HighData+1 MUST be returned." =3D> "previously unsent data", NOT segments RFC 3517 Section 5 Algorithm Details "Note: The first and second duplicate ACKs can also be used to trigger the transmission of previously unsent segments using the Limited Transmit algorithm [RFC3042]." =3D> "transmission of previously unsent segments", NOT the number of seg= ments queued RFC 4653 Section 2 NCR Description "The first Extended Limited Transmit variant, Careful Limited Transmit, calls for the transmission of one previously unsent segment, in response to duplicate acknowledgments, for every two segments that are known to have left the network." =3D> "transmission of previously unsent segments", NOT the number of seg= ments queued RFC 4653 Section 3.2 Terminating Extended Limited Transmit and Preventing B= ursts "(T.3) A TCP is now permitted to transmit previously unsent data as allowed by cwnd, FlightSize, application data availability, and the receiver's advertised window." =3D> "previously unsent data", NOT segments RFC 4653 Section 3.3. Extended Limited Transmit "(E.2) If the comparison in equation (1), below, holds and there are SMSS bytes of previously unsent data available for transmission, then the sender MUST transmit one segment of SMSS bytes." =3D> "previously unsent data", NOT segments Unless there is a definition of "number of previously unsent segments", I t= hink this variable has to be defined and it has to be explained how it is c= alculated. =20 > As discussed in section 5.3, the number of unsent segments can be > estimated from the amount of unsent data and the SMSS. Note that we are > only talking about data that is already available in the send queue, > and > later write calls can of course create additional segments. I guess a > TCP stack that has one SMSS of data in its send queue is free to send > this as multiple segments if it wants to, but I assume that would not > be > the normal behavior. As the estimate is not very critical it is not > really a problem if this happens occasionally. If Nagle's algorithm is disabled, sending out multiple segments would be th= e normal behavior in this case. I could imagine that disabling Nagle's algorithm could be pretty common amo= ng thin stream applications. This is why the draft should IMHO discuss if d= isabling Nagle's algorithm affects the method. > The addition of "previously unsent segments" is there to capture a > corner case (see issue raised by Alex in > http://www.ietf.org/mail-archive/web/tcpm/current/msg08780.html), so it > will only be occasionally used. If we then get an incorrect estimate, > say a sender with one SMSS of data would instead send this as two SMSS, > and the algorithm triggers "incorrectly", this would be equivalent to > using a RTOR threshold of rrthresh + 1 so nothing critical happens. (In > some cases rrthresh + 1 may even be better.) If a wrong parameter for the estimate is possible but not critical, this sh= ould be explained in the document. In general, the cited email from Alex stated: "* Sec 3: IMO the algo/doc is too much Linux driven. I would like to see a segment-based *and* byte-based version of the algo, like RFC 5827." I fully agree to this statement and I think it has not been completely addr= essed in -04 so far. =20 > > * Section 9: I wonder if an attacker could try to send certain ACK > patterns to increase the risk of timeouts e.g. at a Web Server, > leveraging the smaller RTO value. If successful, the RTOs could > significantly reduce application performance. Probably, such an > attacker could cause much more harm by other means, i.e., this may not > be a significant security risk. But the current security analysis is > very short. >=20 > The section is very short, but this is because we do not really see any > new security issues. >=20 > If I understand your example above correctly, the receiver is trying > to somehow reduce performance for its own application by manipulating > the ACK pattern. But if you are trying to mess up things for your own > application you can deliver incorrect data, throw away any data > received > or do whatever you want so I do not think trying to possibly slow down > the sender is the thing to worry about in this attack scenario. If > someone finds a relevant security issue it should of course be > documented, but I do not think it makes sense to put in something like > the above just to make the section longer. I was thinking e.g. about an off-path attacker that tries to inject ACKs in= to the TCP connection to trigger RTOs to harm application performance. I am= not arguing that this is really a relevant attack scenario, but it seems n= ot impossible to try that. Michael From nobody Mon Nov 10 08:38: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 93EA31A00E8 for ; Mon, 10 Nov 2014 08:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 F3i9w7SHaz83 for ; Mon, 10 Nov 2014 08:38:35 -0800 (PST) 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 419671A00A8 for ; Mon, 10 Nov 2014 08:38:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,353,1413270000"; d="scan'208,217";a="166437720" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx11-out.netapp.com with ESMTP; 10 Nov 2014 08:38:32 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 10 Nov 2014 08:38:31 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Mon, 10 Nov 2014 08:38:31 -0800 From: "Scheffenegger, Richard" To: Bob Briscoe , David Borman Thread-Topic: [tcpm] I-D Action: draft-borman-tcpm-tcp4way-00.txt Thread-Index: AQHP76aOj3Voxfk6ZkOwSbwZsagYNpxQILiAgAoEuEA= Date: Mon, 10 Nov 2014 16:38:30 +0000 Message-ID: <356d8ca2226f4567a77e20cab933fbde@hioexcmbx05-prd.hq.netapp.com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> In-Reply-To: <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.35] Content-Type: multipart/alternative; boundary="_000_356d8ca2226f4567a77e20cab933fbdehioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/CNwuUYy4unZ7SGHP5Mx8YD8Tj78 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Mon, 10 Nov 2014 16:38:41 -0000 --_000_356d8ca2226f4567a77e20cab933fbdehioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just to share some (one of the many test run results) of the actual data co= llected for port 80: I tested by sending a packet; the expected response for no= n-ECN would be a simple , and for ECN-enabled hosts, a . Live: 15210 (89.0255) [targets which actually established a connectio= n, regular + ECN] not-ECN: 8465 {55.6542} SA: 8214 {54.0039} [a regular SYN,ACK, RFC793] Bad_SAEC: 21 {0.138067} [the Nonce bit was not reflected, the other ECN b= its were] Bad_SAECN: 210 {1.38067} [all unknown flags are reflected ] Bad_SAC: 0 {0} [never observed a host with this combination ] Bad_SACN: 0 {0} [never observed a host with this combination ] Bad_SAEN: 0 {0} [never observed a host with this combination (RFC= 3540 Nonce) ] Bad_SAN: 20 {0.131492} [ECN flags cleared, but NS bit reflected] So, there are middleboxes that "understand" the ECN flags ECE and CWR (and = properly clear them), but still simply reflect the unknown NS flag (SAN). Other middleboxes (or paths) clear the "unknown" NS flag, but reflect both = ECE and CWR (SAEC); the majority of broken implementations simply reflect a= ll unknown flags (SAECN); Finally, SAEN is not strictly a forbidden combina= tion under ECN Nonce, but we have never seen ECN Nonce support in the wild = anyway. Another note to make: On port 80, more broken behavior was seen than on por= t 21, probably due to a the higher number of paths featuring some kind of w= eb-enhancing device (load balancer, proxy, ...); Overall, the use of new flags will have to deal with a population of up to = 2.0% of paths/hosts which won't deal with unknown flags properly. Richard Scheffenegger 4) Nit: Reflection of Reserved Flags Simple reflection of Reserved flags cannot be used to confirm that the serv= er agrees with the client. There are TCP implementations that just reflect = whatever Reserved flags the client sends, whether or not they support them. This is fairly easy to work-round. Similar to ECN negotiation [RFC3168, Sec= 6.1.1.2] you just define the confirmation as a different pattern of flags = (but this burns more flags). Richard Scheffenegger was testing the Alexa top 1M Web servers in Apr with = flags on SYN as follows: > CWR ECE SYN The correct response of ECN-capable servers was: < ECE SYN ACK I know he found a fair number (sorry I don't have the %) that just dumbly r= eflected: < CWR ECE SYN ACK And when he set the nonce flag on a SYN sent to these same broken Web serve= rs, all of them just dumbly reflected back the new pattern: > NS CWR ECE SYN < NS CWR ECE SYN ACK --_000_356d8ca2226f4567a77e20cab933fbdehioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Just to sh= are some (one of the many test run results) of the actual data collected fo= r port 80:

 = ;

I tested b= y sending a <SYN,ECE,CWR,NS> packet; the expected response for non-EC= N would be a simple <SYN,ACK>, and for ECN-enabled hosts, a <SYN,A= CK,ECE>.

 = ;

 = ;

 

Live:  15210 (89.0255)&= nbsp;     [targets which actually established a connect= ion, regular + ECN]

not-ECN: 8465 {55.6542}=

SA:    &= nbsp;   8214 {54.0039} [a regular SYN,ACK, RFC793]

Bad_SAEC:  21 {0.138067= }  [the Nonce bit was not reflected, the other ECN bits were]

Bad_SAECN: 210 {1.38067}&nbs= p; [all unknown flags are reflected ]

Bad_SAC:   0 {0}&n= bsp;         [never observed a host= with this combination ]

Bad_SACN:  0 {0} &= nbsp;        [never observed a host with= this combination ]

Bad_SAEN:  0 {0} &= nbsp;        [never observed a host with= this combination (RFC 3540 Nonce) ]

Bad_SAN:   20 {0.1= 31492}  [ECN flags cleared, but NS bit reflected]

 

 = ;

So, there = are middleboxes that “understand” the ECN flags ECE and CWR (an= d properly clear them), but still simply reflect the unknown NS flag (SAN).=

Other midd= leboxes (or paths) clear the “unknown” NS flag, but reflect bot= h ECE and CWR (SAEC); the majority of broken implementations simply reflect all unknown flags (SAECN); Finally, SAEN is not strictly a forbidden combi= nation under ECN Nonce, but we have never seen ECN Nonce support in the wil= d anyway.

 = ;

Another no= te to make: On port 80, more broken behavior was seen than on port 21, prob= ably due to a the higher number of paths featuring some kind of web-enhancing device (load balancer, proxy, …);

 = ;

Overall, t= he use of new flags will have to deal with a population of up to 2.0% of pa= ths/hosts which won’t deal with unknown flags properly.

 = ;

 = ;

Richard Scheffenegger

4) Nit: Reflection of Reserved Flags

Simple reflection of Reserved flags cannot be used to confirm that = the server agrees with the client. There are TCP implementations that just reflect whatever Reserved fl= ags the client sends, whether or not they support them.

This is fairly easy to work-round. Similar to ECN negotiation [RFC3168, Sec= 6.1.1.2] you just define the confirmation as a different pattern of flags = (but this burns more flags).

Richard Scheffenegger was testing the Alexa top 1M Web servers in Apr with = flags on SYN as follows:
        > CWR ECE SYN
The correct response of ECN-capable servers was:
         <   &nbs= p; ECE SYN ACK
I know he found a fair number (sorry I don't have the %) that just dumbly r= eflected:
        < CWR ECE SYN ACK
And when he set the nonce flag on a SYN sent to these same broken Web serve= rs, all of them just dumbly reflected back the new pattern:
        > NS CWR ECE SYN
        < NS CWR ECE SYN ACK


 

--_000_356d8ca2226f4567a77e20cab933fbdehioexcmbx05prdhqnetappc_-- From nobody Mon Nov 10 09:01: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 AFCB91A00A8; Mon, 10 Nov 2014 09:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 4TGGBebpDhyw; Mon, 10 Nov 2014 09:01:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 32B901A0167; Mon, 10 Nov 2014 09:01:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AE2B5181C67; Mon, 10 Nov 2014 09:01:12 -0800 (PST) To: mtaylor@unicoi.com, mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141110170112.AE2B5181C67@rfc-editor.org> Date: Mon, 10 Nov 2014 09:01:12 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uuS8PM1WLCNJJkB8h2zAJtzlEN0 Cc: mls.ietf@gmail.com, tcpm@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Errata Held for Document Update] RFC5681 (4068) 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, 10 Nov 2014 17:01:39 -0000 The following errata report has been held for document update for RFC5681, "TCP Congestion Control". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5681&eid=4068 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Michael Taylor Date Reported: 2014-08-04 Held by: Martin Stiemerling (IESG) Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- The problem is the use of the phrase "new data" in an imprecise manner to sometimes mean "previously unacknowledged data" and other times mean "never before sent data". For example, in Section 3.1 During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data. This should read During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges previously unacknowledged data. I believe that throughout Section 3.1 "new data" refers to "previously unacknowledged data". However, in Section 3.2 we have After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives. I believe that here "new data" refers to "previously unsent data". This is clearer in the following paragraph from Section 3.2 1. On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total FlightSize would remain less than or equal to cwnd plus 2*SMSS, and that new data is available for transmission. Here we can see the use of "previously unsent data" followed by "new data" which refers to the aforementioned "previously unsent data". While the meaning of "new data" might be clear to those with extensive experience in TCP it is imprecise and therefore may be quite confusing to those who are learning about the protocol. -------------------------------------- RFC5681 (draft-ietf-tcpm-rfc2581bis-07) -------------------------------------- Title : TCP Congestion Control Publication Date : September 2009 Author(s) : M. Allman, V. Paxson, E. Blanton Category : DRAFT STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Nov 10 10:13: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 F2D571A1BD2 for ; Mon, 10 Nov 2014 10:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 diTljISFPEeE for ; Mon, 10 Nov 2014 10:13:14 -0800 (PST) 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 BB0351A19FC for ; Mon, 10 Nov 2014 10:13:06 -0800 (PST) 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; Mon, 10 Nov 2014 18:13:01 +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, 10 Nov 2014 18:13:03 +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, 10 Nov 2014 18:13:03 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.26.64]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sAAICvDr018283; Mon, 10 Nov 2014 18:12:59 GMT Message-ID: <201411101812.sAAICvDr018283@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Nov 2014 18:12:54 +0000 To: "Scheffenegger, Richard" From: Bob Briscoe In-Reply-To: <356d8ca2226f4567a77e20cab933fbde@hioexcmbx05-prd.hq.netapp .com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> <356d8ca2226f4567a77e20cab933fbde@hioexcmbx05-prd.hq.netapp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1463462211==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BvJ_lFeUOq0I8OYPki3yK5XejyQ Cc: David Borman , "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Mon, 10 Nov 2014 18:13:17 -0000 --=====================_1463462211==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Richard, Thank you - so useful to have actual data! However, I'm having trouble understanding a couple of points about the= table. * I assume the first number in each row is the number of responses observed. * However, I'm not sure what the second numbers=20 are - the ones in () or {}. They seem to add up=20 to a little over 200, so they can't be=20 percentages. The ones in {} are 2.11 times the=20 percentage. The one in () is 1.88 times the percentage}. * Also, I'm not sure what the difference between=20 the two rows tagged not-ECN and SA is meant to be. Surely SA /is/ not-ECN? Bob At 16:38 10/11/2014, Scheffenegger, Richard wrote: >Hi, > >Just to share some (one of the many test run=20 >results) of the actual data collected for port 80: > >I tested by sending a packet;=20 >the expected response for non-ECN would be a=20 >simple , and for ECN-enabled hosts, a . > > > >Live: 15210 (89.0255) [targets which=20 >actually established a connection, regular + ECN] >not-ECN: 8465 {55.6542} >SA: 8214 {54.0039} [a regular SYN,ACK, RFC793] >Bad_SAEC: 21 {0.138067} [the Nonce bit was not=20 >reflected, the other ECN bits were] >Bad_SAECN: 210 {1.38067} [all unknown flags are reflected ] >Bad_SAC: 0 {0} [never observed a host with this combination ] >Bad_SACN: 0 {0} [never observed a host with this combination ] >Bad_SAEN: 0 {0} [never observed a host=20 >with this combination (RFC 3540 Nonce) ] >Bad_SAN: 20 {0.131492} [ECN flags cleared, but NS bit reflected] > > >So, there are middleboxes that =93understand=94 the=20 >ECN flags ECE and CWR (and properly clear them),=20 >but still simply reflect the unknown NS flag (SAN). >Other middleboxes (or paths) clear the =93unknown=94=20 >NS flag, but reflect both ECE and CWR (SAEC);=20 >the majority of broken implementations simply=20 >reflect all unknown flags (SAECN); Finally, SAEN=20 >is not strictly a forbidden combination under=20 >ECN Nonce, but we have never seen ECN Nonce support in the wild anyway. > >Another note to make: On port 80, more broken=20 >behavior was seen than on port 21, probably due=20 >to a the higher number of paths featuring some=20 >kind of web-enhancing device (load balancer, proxy, =85); > >Overall, the use of new flags will have to deal=20 >with a population of up to 2.0% of paths/hosts=20 >which won=92t deal with unknown flags properly. > > >Richard Scheffenegger > > >4) Nit: Reflection of Reserved Flags > >Simple reflection of Reserved flags cannot be=20 >used to confirm that the server agrees with the=20 >client. There are TCP implementations that just=20 >reflect whatever Reserved flags the client=20 >sends, whether or not they support them. > >This is fairly easy to work-round. Similar to=20 >ECN negotiation [RFC3168, Sec 6.1.1.2] you just=20 >define the confirmation as a different pattern=20 >of flags (but this burns more flags). > >Richard Scheffenegger was testing the Alexa top=20 >1M Web servers in Apr with flags on SYN as follows: > > CWR ECE SYN >The correct response of ECN-capable servers was: > < ECE SYN ACK >I know he found a fair number (sorry I don't=20 >have the %) that just dumbly reflected: > < CWR ECE SYN ACK >And when he set the nonce flag on a SYN sent to=20 >these same broken Web servers, all of them just=20 >dumbly reflected back the new pattern: > > NS CWR ECE SYN > < NS CWR ECE SYN ACK > > > ________________________________________________________________ Bob Briscoe, BT=20 --=====================_1463462211==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard,

Thank you - so useful to have actual data!

However, I'm having trouble understanding a couple of points about the table.

* I assume the first number in each row is the number of responses observed.

* However, I'm not sure what the second numbers are - the ones in () or {}. They seem to add up to a little over 200, so they can't be percentages. The ones in {} are 2.11 times the percentage. The one in () is 1.88 times the percentage}.

* Also, I'm not sure what the difference between the two rows tagged not-ECN and SA is meant to be. Surely SA /is/ not-ECN?



Bob

At 16:38 10/11/2014, Scheffenegger, Richard wrote:
Hi,
 
Just to share some (one of the many test run results) of the actual data collected for port 80:
 
I tested by sending a <SYN,ECE,CWR,NS> packet; the expected response for non-ECN would be a simple <SYN,ACK>, and for ECN-enabled hosts, a <SYN,ACK,ECE>.
 
 
 
Live:  15210 (89.0255)      [targets which actually established a connection, regular + ECN]
not-ECN: 8465 {55.6542}
SA:        8214 {54.0039} [a regular SYN,ACK, RFC793]
Bad_SAEC:  21 {0.138067}  [the Nonce bit was not reflected, the other ECN bits were]
Bad_SAECN: 210 {1.38067}  [all unknown flags are reflected ]
Bad_SAC:   0 {0}          [never observed a host with this combination ]
Bad_SACN:  0 {0}          [never observed a host with this combination ]
Bad_SAEN:  0 {0}          [never observed a host with this combination (RFC 3540 Nonce) ]
Bad_SAN:   20 {0.131492}  [ECN flags cleared, but NS bit reflected]
 
 
So, there are middleboxes that =93understand=94 the ECN flags ECE and CWR (and properly clear them), but still simply reflect the unknown NS flag (SAN).
Other middleboxes (or paths) clear the =93unknown=94 NS flag, but reflect both ECE and CWR (SAEC); the majority of broken implementations simply reflect all unknown flags (SAECN); Finally, SAEN is not strictly a forbidden combination under ECN Nonce, but we have never seen ECN Nonce support in the wild anyway.
 
Another note to make: On port 80, more broken behavior was seen than on port 21, probably due to a the higher number of paths featuring some kind of web-enhancing device (load balancer, proxy, =85);
 
Overall, the use of new flags will have to deal with a population of up to 2.0% of paths/hosts which won=92t deal with unknown flags properly.
 
 
Richard Scheffenegger


4) Nit: Reflection of Reserved Flags

Simple reflection of Reserved flags cannot be used to confirm that the server agrees with the client. There are TCP implementations that just reflect whatever Reserved flags the client sends, whether or not they support them.

This is fairly easy to work-round. Similar to ECN negotiation [RFC3168, Sec 6.1.1.2] you just define the confirmation as a different pattern of flags (but this burns more flags).

Richard Scheffenegger was testing the Alexa top 1M Web servers in Apr with flags on SYN as follows:
        > CWR ECE SYN
The correct response of ECN-capable servers was:
         <     ECE SYN ACK
I know he found a fair number (sorry I don't have the %) that just dumbly reflected:
        < CWR ECE SYN ACK
And when he set the nonce flag on a SYN sent to these same broken Web servers, all of them just dumbly reflected back the new pattern:
        > NS CWR ECE SYN
        < NS CWR ECE SYN ACK


 

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_1463462211==.ALT-- From nobody Mon Nov 10 10:33: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 424DD1A701A for ; Mon, 10 Nov 2014 10:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 jAqYvPN-3Q5D for ; Mon, 10 Nov 2014 10:33:37 -0800 (PST) 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 7C1571A6F3C for ; Mon, 10 Nov 2014 10:32:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,354,1413270000"; d="scan'208,217";a="209344455" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx12-out.netapp.com with ESMTP; 10 Nov 2014 10:32:13 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 10 Nov 2014 10:32:11 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Mon, 10 Nov 2014 10:32:11 -0800 From: "Scheffenegger, Richard" To: Bob Briscoe Thread-Topic: [tcpm] I-D Action: draft-borman-tcpm-tcp4way-00.txt Thread-Index: AQHP76aOj3Voxfk6ZkOwSbwZsagYNpxQILiAgAoEuECAAB8/EIAAAqDg Date: Mon, 10 Nov 2014 18:32:11 +0000 Message-ID: <7cf5e18e16ea4d6186dd6227dab9db5d@hioexcmbx05-prd.hq.netapp.com> References: <20141024160137.27218.68002.idtracker@ietfa.amsl.com> <3885D312-2D24-4E5D-BE87-A4F877CB64D2@weston.borman.com> <201411032321.sA3NLu9p018412@bagheera.jungle.bt.co.uk> <356d8ca2226f4567a77e20cab933fbde@hioexcmbx05-prd.hq.netapp.com> <201411101812.sAAICvDr018283@bagheera.jungle.bt.co.uk> In-Reply-To: <201411101812.sAAICvDr018283@bagheera.jungle.bt.co.uk> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.30] Content-Type: multipart/alternative; boundary="_000_7cf5e18e16ea4d6186dd6227dab9db5dhioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RlVh5kdok9JDpR1H23WBUAgTL1Q Cc: David Borman , "tcpm@ietf.org \(tcpm@ietf.org\)" 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: Mon, 10 Nov 2014 18:33:49 -0000 --_000_7cf5e18e16ea4d6186dd6227dab9db5dhioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bob, yes, that list excludes the ECN-enabled sessions. The ()-bracket behind "Live" is the percentage of responsive IP servers (20= k IPs were sampled in this instance) The {}-bracket are the relative percentages of all live hosts, that behaved= in a particular way, ie. 54% would be non-ECN, regular SA (not mirroring = unknown flags), 0.14, 1.38 and 0.13 % would not properly handle unknown TC= P header flags in some way, and the remainder were ECN-capable TCP stacks. = Which, by the way is not the same as stating that these sessions (44,35%) w= ould actually constitute actually working ECN paths - only a small fraction= of internet paths which have ECN-capable TCP stacks on both ends deal prop= erly with the IP-ECN part at this time... I believe something like 2% of pa= ths (all live hosts) would be supportive of AQM/ECN at an congestion point = at this time overall - ie. a ECN mark would get through on the IP layer and= dealt with properly on the TCP layer. That was omitted here, as the ECN-sessions were broken down further during = these tests, ie. if the path would properly handle IP-ECN flags, mirror or = normalize IP-ECN flags, keep the "TOS" flag of the SYN for the session, if= ECT(1) and CE would elicit proper responses actually etc; As Brian stated early on during this campaign, there are many more ways of = brokenness than one would think of... Richard Scheffenegger From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: Montag, 10. November 2014 08:13 To: Scheffenegger, Richard Cc: David Borman; tcpm@ietf.org (tcpm@ietf.org) Subject: RE: [tcpm] I-D Action: draft-borman-tcpm-tcp4way-00.txt Richard, Thank you - so useful to have actual data! However, I'm having trouble understanding a couple of points about the tabl= e. * I assume the first number in each row is the number of responses observed= . * However, I'm not sure what the second numbers are - the ones in () or {}.= They seem to add up to a little over 200, so they can't be percentages. Th= e ones in {} are 2.11 times the percentage. The one in () is 1.88 times the= percentage}. * Also, I'm not sure what the difference between the two rows tagged not-EC= N and SA is meant to be. Surely SA /is/ not-ECN? Bob At 16:38 10/11/2014, Scheffenegger, Richard wrote: Hi, Just to share some (one of the many test run results) of the actual data co= llected for port 80: I tested by sending a packet; the expected response for no= n-ECN would be a simple , and for ECN-enabled hosts, a . Live: 15210 (89.0255) [targets which actually established a connectio= n, regular + ECN] not-ECN: 8465 {55.6542} SA: 8214 {54.0039} [a regular SYN,ACK, RFC793] Bad_SAEC: 21 {0.138067} [the Nonce bit was not reflected, the other ECN b= its were] Bad_SAECN: 210 {1.38067} [all unknown flags are reflected ] Bad_SAC: 0 {0} [never observed a host with this combination ] Bad_SACN: 0 {0} [never observed a host with this combination ] Bad_SAEN: 0 {0} [never observed a host with this combination (RFC= 3540 Nonce) ] Bad_SAN: 20 {0.131492} [ECN flags cleared, but NS bit reflected] So, there are middleboxes that "understand" the ECN flags ECE and CWR (and = properly clear them), but still simply reflect the unknown NS flag (SAN). Other middleboxes (or paths) clear the "unknown" NS flag, but reflect both = ECE and CWR (SAEC); the majority of broken implementations simply reflect a= ll unknown flags (SAECN); Finally, SAEN is not strictly a forbidden combina= tion under ECN Nonce, but we have never seen ECN Nonce support in the wild = anyway. Another note to make: On port 80, more broken behavior was seen than on por= t 21, probably due to a the higher number of paths featuring some kind of w= eb-enhancing device (load balancer, proxy, ...); Overall, the use of new flags will have to deal with a population of up to = 2.0% of paths/hosts which won't deal with unknown flags properly. Richard Scheffenegger 4) Nit: Reflection of Reserved Flags Simple reflection of Reserved flags cannot be used to confirm that the serv= er agrees with the client. There are TCP implementations that just reflect = whatever Reserved flags the client sends, whether or not they support them. This is fairly easy to work-round. Similar to ECN negotiation [RFC3168, Sec= 6.1.1.2] you just define the confirmation as a different pattern of flags = (but this burns more flags). Richard Scheffenegger was testing the Alexa top 1M Web servers in Apr with = flags on SYN as follows: > CWR ECE SYN The correct response of ECN-capable servers was: < ECE SYN ACK I know he found a fair number (sorry I don't have the %) that just dumbly r= eflected: < CWR ECE SYN ACK And when he set the nonce flag on a SYN sent to these same broken Web serve= rs, all of them just dumbly reflected back the new pattern: > NS CWR ECE SYN < NS CWR ECE SYN ACK ________________________________________________________________ Bob Briscoe, BT --_000_7cf5e18e16ea4d6186dd6227dab9db5dhioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Hi  B= ob,

 = ;

yes, that = list excludes the ECN-enabled sessions.

 = ;

The ()-bra= cket behind “Live” is the percentage of responsive IP servers (= 20k IPs were sampled in this instance)

The {}-bra= cket are the relative percentages of all live hosts, that behaved in a part= icular way, ie.  54% would be non-ECN, regular SA (not mirroring unknown flags),  0.14, 1.38 and 0.13 % would not properly handle unkn= own TCP header flags in some way, and the remainder were ECN-capable TCP st= acks. Which, by the way is not the same as stating that these sessions (44,= 35%) would actually constitute actually working ECN paths – only a small fraction of internet paths which ha= ve ECN-capable TCP stacks on both ends deal properly with the IP-ECN part a= t this time… I believe something like 2% of paths (all live hosts) wo= uld be supportive of AQM/ECN at an congestion point at this time overall – ie. a ECN mark would get through on the= IP layer and dealt with properly on the TCP layer.

 = ;

That was o= mitted here, as the ECN-sessions were broken down further during these test= s, ie. if the path would properly handle IP-ECN flags, mirror or normalize IP-ECN flags, keep the “TOS” flag of the SYN for = the session,  if ECT(1) and CE would elicit proper responses actually = etc;

 = ;

As Brian s= tated early on during this campaign, there are many more ways of brokenness= than one would think of…

 = ;

Richard Scheffenegger



 <= /p>

From: Bob Briscoe [mailto:bob.briscoe@bt.com]
Sent: Montag, 10. November 2014 08:13
To: Scheffenegger, Richard
Cc: David Borman; tcpm@ietf.org (tcpm@ietf.org)
Subject: RE: [tcpm] I-D Action: draft-borman-tcpm-tcp4way-00.txt

 

Richard,

Thank you - so useful to have actual data!

However, I'm having trouble understanding a couple of points about the tabl= e.

* I assume the first number in each row is the number of responses observed= .

* However, I'm not sure what the second numbers are - the ones in () or {}.= They seem to add up to a little over 200, so they can't be percentages. Th= e ones in {} are 2.11 times the percentage. The one in () is 1.88 times the= percentage}.

* Also, I'm not sure what the difference between the two rows tagged not-EC= N and SA is meant to be. Surely SA /is/ not-ECN?



Bob

At 16:38 10/11/2014, Scheffenegger, Richard wrote:

Hi,
 
Just to share some (one of the many test run results) of the actual data co= llected for port 80:
 
I tested by sending a <SYN,ECE,CWR,NS> packet; the expected response = for non-ECN would be a simple <SYN,ACK>, and for ECN-enabled hosts, a= <SYN,ACK,ECE>.
 
 
 
Live:  15210 (89.0255)      [targets which ac= tually established a connection, regular + ECN]
not-ECN: 8465 {55.6542}
SA:        8214 {54.0039} [a regular SYN= ,ACK, RFC793]
Bad_SAEC:  21 {0.138067}  [the Nonce bit was not reflected, the o= ther ECN bits were]
Bad_SAECN: 210 {1.38067}  [all unknown flags are reflected ]
Bad_SAC:   0 {0}        &= nbsp; [never observed a host with this combination ]
Bad_SACN:  0 {0}         = [never observed a host with this combination ]
Bad_SAEN:  0 {0}         = [never observed a host with this combination (RFC 3540 Nonce) ]
Bad_SAN:   20 {0.131492}  [ECN flags cleared, but NS bit ref= lected]
 
 
So, there are middleboxes that “understand” the ECN flags ECE a= nd CWR (and properly clear them), but still simply reflect the unknown NS f= lag (SAN).
Other middleboxes (or paths) clear the “unknown” NS flag, but r= eflect both ECE and CWR (SAEC); the majority of broken implementations simp= ly reflect all unknown flags (SAECN); Finally, SAEN is not strictly a forbi= dden combination under ECN Nonce, but we have never seen ECN Nonce support in the wild anyway.
 
Another note to make: On port 80, more broken behavior was seen than on por= t 21, probably due to a the higher number of paths featuring some kind of w= eb-enhancing device (load balancer, proxy, …);
 
Overall, the use of new flags will have to deal with a population of up to = 2.0% of paths/hosts which won’t deal with unknown flags properly.
 
 
Richard Scheffenegger


4) Nit: Reflection of Reserved Flags

Simple reflection of Reserved flags cannot be used to confirm that = the server agrees with the client. There are TCP implementations that just = reflect whatever Reserved flags the client sends, whether or not they suppo= rt them.

This is fairly easy to work-round. Similar to ECN negotiation [RFC3168, Sec= 6.1.1.2] you just define the confirmation as a different pattern of flags = (but this burns more flags).

Richard Scheffenegger was testing the Alexa top 1M Web servers in Apr with = flags on SYN as follows:
        > CWR ECE SYN
The correct response of ECN-capable servers was:
         <   &nbs= p; ECE SYN ACK
I know he found a fair number (sorry I don't have the %) that just dumbly r= eflected:
        < CWR ECE SYN ACK
And when he set the nonce flag on a SYN sent to these same broken Web serve= rs, all of them just dumbly reflected back the new pattern:
        > NS CWR ECE SYN
        < NS CWR ECE SYN ACK


 

________________________________________________________________
Bob Briscoe,          &nb= sp;            =             &nb= sp;            =   BT

--_000_7cf5e18e16ea4d6186dd6227dab9db5dhioexcmbx05prdhqnetappc_-- From nobody Mon Nov 10 13:24: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 04F901A1BA3 for ; Mon, 10 Nov 2014 13:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 9BoMkTshm3ai for ; Mon, 10 Nov 2014 13:24:19 -0800 (PST) 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 8B62D1A1BA0 for ; Mon, 10 Nov 2014 13:24:18 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 10 Nov 2014 21:24:16 +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, 10 Nov 2014 21:24:13 +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, 10 Nov 2014 21:24:13 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.28.192]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sAALOAqg018839; Mon, 10 Nov 2014 21:24:11 GMT Message-ID: <201411102124.sAALOAqg018839@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Nov 2014 21:24:08 +0000 To: "Zimmermann, Alexander" 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/PqojH-kiYHA1RujrEBWRTilKMLw Cc: tcpm IETF list Subject: [tcpm] Dual SYN and binding to an explicit port 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, 10 Nov 2014 21:24:23 -0000 Alex, I punted this question to the list, so here's the answer... See S.4.3. Interaction with the Pre-Existing TCP API Here's the relevant text: " Binding to an explicit port: If an application specifies that it wants the TCP client to use a specific port, the Inner Space capability MUST be disabled, because the dual handshake has to try two ports. Use of a specific port might be necessary, for example in a port-testing application or if the application wants to explicitly control all the handshaking logic of the Inner Space protocol itself. " I realise I need this text is actually too strong. The app doesn't need to disable Inner Space. It only needs to disable the dual handshake, so that it becomes a serial handshake. I.e. it tries an upgraded SYN, and only if the SYN/ACK comes back showing the server is legacy does it send a RST. Then it uses the same client port for a legacy SYN. I'll change the text. Bob ________________________________________________________________ Bob Briscoe, BT From nobody Mon Nov 10 14:34: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 7CBC31ACF15 for ; Mon, 10 Nov 2014 14:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 i5pLys5_9bBV for ; Mon, 10 Nov 2014 14:34:56 -0800 (PST) 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 56A721ACEFC for ; Mon, 10 Nov 2014 14:34:56 -0800 (PST) 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 sAAMYEXA024758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Nov 2014 14:34:14 -0800 (PST) Message-ID: <54613D67.6070203@isi.edu> Date: Mon, 10 Nov 2014 14:34:15 -0800 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: Brandon Williams , "Sujeet Nayak A (sua)" , "tcpm@ietf.org" References: <5460088F.6080104@akamai.com> In-Reply-To: <5460088F.6080104@akamai.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/s7WQFo4b3MNw-KqKAA25JnkWt5g Subject: Re: [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: Mon, 10 Nov 2014 22:34:57 -0000 On 11/9/2014 4:36 PM, Brandon Williams wrote: > Hi Sujeet, > > I'm still concerned about whether there's enough space in the SYN header > for this option. My concern is based mostly on a what I think is a flaw > in the analysis from RFC5925 section 7.2, which leaves out the 4-byte > MSS option. Yes, that was an oversight. However, there were 9 SYN option bytes available with the lengths of the hashes defined at the time, so that's not a problem. > As the analysis from RFC6824 indicates, SYN packets > typically include the MSS option, leaving only 21 bytes available in an > option packed SYN and 16 in a worst-case unpacked SYN. Options are not required to be (4-byte) word-aligned; they must *end* on such a boundary only. If they don't otherwise fit, they should be placed to fit. > TCP-AO with SHA1 > works in either case, but SHA2 only works (just barely) in an option > packed stack. "barely" means it works. Option word alignment is an optimization that clearly is inappropriate if the options won't otherwise fit. > Section 4 of your draft should probably be updated to account for the > commonality of the MSS option and the related requirement either to drop > one of the common SYN options or pack the option space. Pack the options space or (IMO) use a shorter hash. It's not viable for any one option to declare whether to drop other options. Joe From nobody Mon Nov 10 20:32: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 DE1E41AD3CA for ; Mon, 10 Nov 2014 20:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 FXYAPyfBAq_p for ; Mon, 10 Nov 2014 20:32:09 -0800 (PST) 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 6DA2B1ACF67 for ; Mon, 10 Nov 2014 20:32:08 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 11 Nov 2014 04:32:06 +0000 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; Tue, 11 Nov 2014 04:32:05 +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; Tue, 11 Nov 2014 04:32:02 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.230.140]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sAB4Vu7g020269; Tue, 11 Nov 2014 04:31:58 GMT Message-ID: <201411110431.sAB4Vu7g020269@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Nov 2014 04:31:54 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <545D1FB8.2040505@isi.edu> References: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk> <544EDB38.3050600@mti-systems.com> <544EDCF1.4000200@isi.edu> <544F1E9F.3060108@mti-systems.com> <545AC718.4010407@isi.edu> <201411071926.sA7JQ5fg002953@bagheera.jungle.bt.co.uk> <545D1FB8.2040505@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/Plz86RX0B2vBHeftfGTtgSVsyGM Cc: tcpm IETF list 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, 11 Nov 2014 04:32:12 -0000 Joe, At 19:38 07/11/2014, Joe Touch wrote: >Hi, Bob, > >On 11/7/2014 11:26 AM, Bob Briscoe wrote: > > Joe, > > > > At 00:55 06/11/2014, Joe Touch wrote: >... > >> You treat the OOB and SYN as a pair, and treat it with the same time-out > >> on both ends as far as giving up or retransmitting. How long you keep > >> queued copies to deal with reordering or other arrival-timing issues is > >> up to the receiver. > > > > Not so IMO. The OOB has to be sent a 'guard time' after the SYN, to > > minimise the chance of it getting reordered and then getting tangled up > > in a firewall before the SYN arrives; the firewall will chuck any > > segment for which it has not seen a prior SYN. > >Firewalls aren't the issue. NATs are, and unless reordering is prevalent >that won't be an issue. Just because NAT is an issue, doesn't mean a firewall won't be an issue as well. >Reordering would mostly happen on multiple paths, but you'd need >multiple paths between the client and the NAT - i.e., in the private >side. That's rare if it happens at all. Once 2 back-to-back segments have got through a local NAT, they can get reordered over an access network (e.g. link aggregation group) before arriving at a firewall at the other end. Also, TCP is used (and might be used in future) in rather more circumstances than just where a NAT is in the next room over a small LAN: - There could be an access network (with link aggregation) then a carrier-grade NAT. - The TCP client might be on a server in a data centre, opening a connection to a back-end database in another data centre over a WAN with ECMP in between. - And so on... Bob >I thus don't agree that guard times are needed, which means we don't >need to worry about determining them. > > > So although the timeouts might be the same it doesn't seem sensible to > > start the timers at the same time. > >I currently believe that there should be one timer. If you need to >resend, you resend BOTH the SYN and OOB. The server side can cache to >deal with reordering that happens there, but that doesn't require >guard-time at client transmission. > >Joe ________________________________________________________________ Bob Briscoe, BT From nobody Mon Nov 10 20:40: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 7244D1AD512 for ; Mon, 10 Nov 2014 20:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 Fu93ThCv86ik for ; Mon, 10 Nov 2014 20:40:17 -0800 (PST) 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 6FB121AD50F for ; Mon, 10 Nov 2014 20:40:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,358,1413270000"; d="scan'208";a="209447437" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx12-out.netapp.com with ESMTP; 10 Nov 2014 20:40:07 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 10 Nov 2014 20:40:05 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5d98:1529:da8c:ea24%21]) with mapi id 15.00.0995.031; Mon, 10 Nov 2014 20:40:05 -0800 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: Making TCP robust against reordering - a step forward Thread-Index: AQHP/WmPtSZqZSdPVEeZUQguIdx6TQ== Date: Tue, 11 Nov 2014 04:40:04 +0000 Message-ID: <177E41C4-4099-4BDB-8836-948728EB44D6@netapp.com> 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.37] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HgqxAkQfI1PVVphEIuD8yMWAe3w Subject: [tcpm] Making TCP robust against reordering - a step forward 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, 11 Nov 2014 04:40:18 -0000 SGkgYWxsLA0KDQpzaW5jZSB0aGUgbGFzdCBJRVRGIHdlIGEgc3Ryb25nIGNvbnNlbnN1cyB0aGF0 IHdlIHNob3VsZCBtYWtlIFRDUCBtb3JlDQpyb2J1c3QgYWdhaW5zdCBwYWNrZXQgcmVvcmRlcmlu Zy4gSSBiZWxpZXZlIGFzIGEgZmlyc3Qgc3RlcCB3ZSBwcm9iYWJseQ0Kc2hvdWxkIHNwZWNpZnkg aG93IHdlIGNhbiBkZXRlY3RlZCBhbmQgcXVhbGlmeSByZW9yZGVyaW5nIHcvIFRDUC4gSXQNCmdp dmVzIHVzIHRoZSBvcHBvcnR1bml0eSB0byBsZWFybiBtb3JlIGFib3V0IHRoZSByZW9yZGVyaW5n IGluIHRoZSB3aWxkDQphbmQsIGF0IHRoZSBlbmQsIGFueSByZWFjdGlvbiBhbGdvcml0aG0gLSB3 aGF0ZXZlciBpdCBsb29rcyBsaWtlIC0gY2FuDQpiZW5lZml0IGZyb20gYSBwcm9wZXIgZGV0ZWN0 aW9uL3F1YW50aWZpY2F0aW9uLg0KDQpNb3Jlb3ZlciBJIGFsc28gYmVsaWV2ZSB0aGF0IGRyYWZ0 LXppbW1lcm1hbm4tdGNwbS1yZW9yZGVyaW5nLWRldGVjdGlvbg0KaXMgYSBnb29kIHN0YXJ0aW5n IHBvaW50LiBXZSBqdXN0IHVwZGF0ZWQgdGhlIGRyYWZ0IGluIHRoYXQgd2F5IHRoYXQgd2UNCmRl dGVjdGVkIG5vdyBhbHNvIHJlb3JkZXJpbmcgPiAxIFJUVC4gSSBrbm93IGZyb20gc2V2ZXJhbCBw ZW9wbGUgdGhhdA0KdGhleSBhcmUgcmVhZCB0aGUgZHJhZnQuIFVuZm9ydHVuYXRlbHksIHdlIGhh dmVu4oCZdCByZWNlaXZlZCBtdWNoIGNvbW1lbnRzLg0KU28sIHBsZWFzZSByZXZpZXcgdGhlIGRv YyBhbmQgbWFrZSBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQuDQoNClRoYW5rcw0KQWxleA== From nobody Tue Nov 11 09:10: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 D00091A1BC9 for ; Tue, 11 Nov 2014 09:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 xcUK8RnsGAED for ; Tue, 11 Nov 2014 09:09:56 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794D71A00B5 for ; Tue, 11 Nov 2014 09:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1905; q=dns/txt; s=iport; t=1415725595; x=1416935195; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ICzO4Gh4e4OiiyRDsN4Vr+CsGIurBOTbDSMBo4y4bnI=; b=ZGDZHnmpanBb4gbtLgBD3qs70HjtOOG+TSOPfO1kB2K7TAodwQCi2zPo lWNvA+XmVusEiMB7WsOdDgIAMiyu5lHt7a5mPW9P6dN2ClLu2w+VEg/3f 6Q8lLln9h1s3Iige9Ir5dP17uTfqBlu6j2glHrjIp5ITurlHHpkpP723V 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMZBYlStJV2R/2dsb2JhbABcDoMAgS0E03ICgRgWAQEBAQF9hAMBAQQ6TwIBCBgVCRAyJQIEARKIQc5oAQEBAQEBAQECAQEBAQEBARuRGwqEQQEEkjGLdIE0kSKECoIAAh6BGkBsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208";a="95521138" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 11 Nov 2014 17:06:34 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sABH6Y2d010758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 17:06:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.91]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 11:06:34 -0600 From: "Sujeet Nayak A (sua)" To: Joe Touch , Brandon Williams , "tcpm@ietf.org" Thread-Topic: [tcpm] Updated SHA-2 AO draft Thread-Index: AQHP8nYrPM6bJff4oUqZ0Bc1WuqHwZxZfGeAgAFwK4CAAZL2AA== Date: Tue, 11 Nov 2014 17:06:34 +0000 Message-ID: References: <5460088F.6080104@akamai.com> <54613D67.6070203@isi.edu> In-Reply-To: <54613D67.6070203@isi.edu> 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.65.37.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <8BF12F0E9DE36643A26E3702A06249C6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0DhaPgeqrgbN-ICObDdiVPvwnMY Subject: Re: [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, 11 Nov 2014 17:09:59 -0000 Hi Brandon, Joe, Thanks a lot for your quick and useful comments. I will expand section 4 further, with options packing recommendation. If we cut down on the hash size, that could compromise on the security of algorithm implementation by increasing the probability of successful birthday attacks (which could defeat the very purpose of the ask for SHA2). Regards, Sujeet On 11/11/14 4:04 AM, "Joe Touch" wrote: > > >On 11/9/2014 4:36 PM, Brandon Williams wrote: >> Hi Sujeet, >>=20 >> I'm still concerned about whether there's enough space in the SYN header >> for this option. My concern is based mostly on a what I think is a flaw >> in the analysis from RFC5925 section 7.2, which leaves out the 4-byte >> MSS option. > >Yes, that was an oversight. However, there were 9 SYN option bytes >available with the lengths of the hashes defined at the time, so that's >not a problem. > >> As the analysis from RFC6824 indicates, SYN packets >> typically include the MSS option, leaving only 21 bytes available in an >> option packed SYN and 16 in a worst-case unpacked SYN. > >Options are not required to be (4-byte) word-aligned; they must *end* on >such a boundary only. If they don't otherwise fit, they should be placed >to fit. > >> TCP-AO with SHA1 >> works in either case, but SHA2 only works (just barely) in an option >> packed stack. > >"barely" means it works. Option word alignment is an optimization that >clearly is inappropriate if the options won't otherwise fit. > >> Section 4 of your draft should probably be updated to account for the >> commonality of the MSS option and the related requirement either to drop >> one of the common SYN options or pack the option space. > >Pack the options space or (IMO) use a shorter hash. It's not viable for >any one option to declare whether to drop other options. > >Joe > From nobody Tue Nov 11 11:07: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 D5CC11A1A6F for ; Tue, 11 Nov 2014 11:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 FVfRFkv51EFp for ; Tue, 11 Nov 2014 11:07:46 -0800 (PST) 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 43BB61A1A7D for ; Tue, 11 Nov 2014 11:07:38 -0800 (PST) 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 sABJ7aYZ010459 for ; Tue, 11 Nov 2014 13:07:36 -0600 (CST) From: David Borman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 11 Nov 2014 13:07:36 -0600 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/x2jEad6r4NqQREOL3icRc-rNd5s Subject: [tcpm] Other places for extended TCP options in SYN-only packets 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, 11 Nov 2014 19:07:49 -0000 I=E2=80=99ve been trying to figure out some other place to put extended = TCP options in a SYN-only packet. For a standard IPv4/TCP packet, = because there is only one length field, there is only one place to put = additional TCP option space that will be ignored by legacy systems: = encode it into a new IPv4 option. But I=E2=80=99ll be the first to = admit this isn=E2=80=99t a great solution: 1) IPv4 is also limited to just 40 bytes of option space 2) IPv4 options get looked at by every hop on the path 3) The presence of IPv4 options would probably cause slow path = processing in routers. The slow path processing is mitigated by the fact that this only applies = to SYN-only packets. But providing less than 40 additional bytes makes = this very uninteresting. If only TCP had an explicit length field, we could put extended option = space after the TCP data. And there is a way to do that: encapsulate = the IPv4/TCP packet, such that the outer IPv4 header had a length that = included both the inner IPv4/TCP packet, plus the extended options, and = the inner IPv4/TCP packet length excluded the extended options. Systems = that don=E2=80=99t understand the extended options would just see the = inner IPv4/TCP header, and ignore the trailing data from the outer IPv4 = packet. The obvious problem with this is that I wouldn=E2=80=99t expect = it to work with legacy systems, because it depends on systems already = having IPv4-in-IPv4 support, which I doubt, since IPv4-in-IPv4 is mainly = used to create tunnels. But then I started thinking about IPv6/TCP. Additional TCP option space = could be encoded into an IPv6 Destination Options header. The = advantages of this over IPv4 are: 1) There is almost 2K of space; though each option is limited to 255 = bytes, multiple options could be allowed if that became necessary. 2) Destination Options headers are not processed at intermediate hops. 3) With the top 2 bits of the option type set to zero, it will be = ignored by hosts that don=E2=80=99t understand it. 4) Hosts that don=E2=80=99t understand it will just see it as a normal = TCP SYN-only packet. So for IPv6, it is possible to transmit the expanded TCP option space in = the same packet in a manner that won't confuse legacy IPv6/TCP = implementations. A solution for extended TCP option space in SYN-only packets doesn=E2=80=99= t need to be the same for IPv4/TCP and IPv6/TCP. If we can have a clean = solution for IPv6, we should do that rather than force a less-than = desireable IPv4 solution on IPv6 connections. -David Borman= From nobody Tue Nov 11 11:20: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 94F211A6F29 for ; Tue, 11 Nov 2014 11:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 W4t6pDhJR22R for ; Tue, 11 Nov 2014 11:20:44 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B79A61A1AE0 for ; Tue, 11 Nov 2014 11:20:44 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9E095289D8; Tue, 11 Nov 2014 19:20:43 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 94A81289DB; Tue, 11 Nov 2014 19:20:43 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8CDEF203D; Tue, 11 Nov 2014 19:20:43 +0000 (GMT) Message-ID: <5462618B.7010602@akamai.com> Date: Tue, 11 Nov 2014 14:20:43 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Joe Touch , "Sujeet Nayak A (sua)" , "tcpm@ietf.org" References: <5460088F.6080104@akamai.com> <54613D67.6070203@isi.edu> In-Reply-To: <54613D67.6070203@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HIVWTxYj3Avxrr3V3eJBXvQqna4 Subject: Re: [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, 11 Nov 2014 19:20:46 -0000 On 11/10/2014 05:34 PM, Joe Touch wrote: > > > On 11/9/2014 4:36 PM, Brandon Williams wrote: >> Hi Sujeet, >> >> I'm still concerned about whether there's enough space in the SYN header >> for this option. My concern is based mostly on a what I think is a flaw >> in the analysis from RFC5925 section 7.2, which leaves out the 4-byte >> MSS option. > > Yes, that was an oversight. However, there were 9 SYN option bytes > available with the lengths of the hashes defined at the time, so that's > not a problem. > >> As the analysis from RFC6824 indicates, SYN packets >> typically include the MSS option, leaving only 21 bytes available in an >> option packed SYN and 16 in a worst-case unpacked SYN. > > Options are not required to be (4-byte) word-aligned; they must *end* on > such a boundary only. If they don't otherwise fit, they should be placed > to fit. Agreed. But considering how common word alignment was (I don't know whether it still _is_ common), it might still be worth pointing out the potential compatibility problem. > >> TCP-AO with SHA1 >> works in either case, but SHA2 only works (just barely) in an option >> packed stack. > > "barely" means it works. Option word alignment is an optimization that > clearly is inappropriate if the options won't otherwise fit. > "barely" also means that it consumes all of the remaining space. I think that's an important consideration. >> Section 4 of your draft should probably be updated to account for the >> commonality of the MSS option and the related requirement either to drop >> one of the common SYN options or pack the option space. > > Pack the options space or (IMO) use a shorter hash. It's not viable for > any one option to declare whether to drop other options. > Agreed. Option packing or a shorter hash seem the reasonable choices. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Nov 11 11:42: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 F2A561A1A36 for ; Tue, 11 Nov 2014 11:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 AoC7FapbDtdK for ; Tue, 11 Nov 2014 11:41:55 -0800 (PST) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6D01A88A9 for ; Tue, 11 Nov 2014 11:41:55 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1XoHK4-0002m8-6P; Tue, 11 Nov 2014 20:41:52 +0100 Date: Tue, 11 Nov 2014 20:41:52 +0100 From: Florian Westphal To: David Borman Message-ID: <20141111194152.GA10619@breakpoint.cc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/K4NZX6lv8tKRMzTY7D4BhaxOGWQ Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Other places for extended TCP options in SYN-only packets 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, 11 Nov 2014 19:42:01 -0000 David Borman wrote: > But then I started thinking about IPv6/TCP. Additional TCP option space could be encoded into an IPv6 Destination Options header. Yes, but unfortunately ipv6 extension headers do not work. See e.g. https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01 Tables on page 6. From nobody Tue Nov 11 12:39: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 0B7441A1BCE for ; Tue, 11 Nov 2014 12:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 YFV4Z4M7oV7B for ; Tue, 11 Nov 2014 12:39:31 -0800 (PST) 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 3B7C41A1AEF for ; Tue, 11 Nov 2014 12:39:30 -0800 (PST) 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 sABKdSb6011687; Tue, 11 Nov 2014 14:39:29 -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: <20141111194152.GA10619@breakpoint.cc> Date: Tue, 11 Nov 2014 14:39:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141111194152.GA10619@breakpoint.cc> To: Florian Westphal X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/CaTsmRc0b1QripO8SI7gIVty084 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Other places for extended TCP options in SYN-only packets 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, 11 Nov 2014 20:39:33 -0000 > On Nov 11, 2014, at 1:41 PM, Florian Westphal wrote: >=20 > David Borman wrote: >> But then I started thinking about IPv6/TCP. Additional TCP option = space could be encoded into an IPv6 Destination Options header. >=20 > Yes, but unfortunately ipv6 extension headers do not work. >=20 > See e.g. > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-01 >=20 > Tables on page 6. Which doesn=E2=80=99t say that extension headers don=E2=80=99t work, it = says that for their test, when using a Destination Header with a PadN = option, roughly 12%-21% of the connections didn=E2=80=99t succeed. I=E2=80=99m getting tired of the =E2=80=9Cit won=E2=80=99t pass through = 100% of todays middle boxes=E2=80=9D being the first or only thing that = gets considered. As I said before: We need to first decide what we want TCP to look = like, and then find a way to transition from current implementations to = the new design, which might include middle boxes having to change, = rather than letting current middle box implementations dictate how we = can or can=E2=80=99t change TCP. -David Borman From nobody Tue Nov 11 16:41: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 0A10A1A1BFC for ; Tue, 11 Nov 2014 16:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 2PgZpf5kSycx for ; Tue, 11 Nov 2014 16:41:51 -0800 (PST) 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 78B311A1A2C for ; Tue, 11 Nov 2014 16:41:51 -0800 (PST) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id sAC0fL3D001160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 16:41:31 -0800 (PST) Message-ID: <5462ACB4.4000300@isi.edu> Date: Tue, 11 Nov 2014 16:41:24 -0800 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/la25PXa4AE5W3prPlNMpInqWp2c Subject: Re: [tcpm] Other places for extended TCP options in SYN-only packets 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, 12 Nov 2014 00:41:53 -0000 On 11/11/2014 11:07 AM, David Borman wrote: > I’ve been trying to figure out some other place to put extended TCP > options in a SYN-only packet. For a standard IPv4/TCP packet, > because there is only one length field, there is only one place to > put additional TCP option space that will be ignored by legacy > systems: encode it into a new IPv4 option. But I’ll be the first to > admit this isn’t a great solution: > 1) IPv4 is also limited to just 40 bytes of option space > 2) IPv4 options get looked at by every hop on the path > 3) The presence of IPv4 options would probably cause slow path processing in routers. We've pushed ourselves into a corner by not pushing back on these optimizations. All our option spaces are getting killed in the name of profit. These are the times I wish we had both of the following: - an IAB worthy of the name - a compliance process > The slow path processing is mitigated by the fact that this only > applies to SYN-only packets. But providing less than 40 additional > bytes makes this very uninteresting. +1 AFAICT, the key motivation for larger option space isn't "a little more", but rather "an order of magnitude more" - e.g., I'd love to have that so I can use a decent-sized Diffie-Hellman exchange in TCP-AO-encrypt. > If only TCP had an explicit length field, we could put extended > option space after the TCP data. Agreed. However, the NCP->TCP/IP split design wasn't really a complete split. TCP isn't completely separate from IP, and the reuse of the pseudoheader fields from IP in TCP causes us many problems: - no length field for TCP - forwarding ID == transport connection ID > And there is a way to do that: encapsulate the IPv4/TCP packet, such > that the outer IPv4 header had a length that included both the inner > IPv4/TCP packet, plus the extended options, and the inner IPv4/TCP > packet length excluded the extended options. This is a simpler way to achieve the same result as "Innerspace" - i.e., it's going directly towards encapsulation. It's basically TCP-in-TCP as I suggested. However, at that point, why do anything so complex? Just run the simplest, plainest existing features on the outer TCP and use the inner one to support options that ONLY the endpoint is supposed to know about. That said, until we're willing to say that some middlebox behavior is incorrect, we're just pushing off the inevitable - a middlebox that parses the packets two levels deep, and then messes things up again. ... > But then I started thinking about IPv6/TCP. Additional TCP option > space could be encoded into an IPv6 Destination Options header. Same problem. Slow path, and you also have to deal with OPS and SEC folk who are (IMO) trying to deprecate every "feature" of these protocols without going through INTAREA. (I've already noted that on both of their lists). IMO, a feature that's expensive to deploy is a responsibility - not a security risk or operational problem. Again, IMO, the companies that make money on designing Internet products should not be trying to dumb-down our protocols by this slippery-slope approach; they should either swim or sink due on the capability of the devices they sell. However, on that point: > 1) There is almost 2K of space; though each option is limited to 255 > bytes, multiple options could be allowed if that became necessary. Maybe, but that was before OPS and SEC got involved. They've been trying to say that the chain of nested headers should be limited (less work == more $$). > 2) Destination Options headers are not processed at intermediate hops. TCP isn't supposed to be either, and look where we are with that. So you'll just be shouting at router vendors who think they can sell "advanced capabilities" by having their routers process those options anyway. > 3) With the top 2 bits of the option type set to zero, it will be > ignored by hosts that don’t understand it. As with the "dest opts" values, these too are ignored by router vendors who want to sell operators "features" they think are useful. > 4) Hosts that don’t understand it will just see it as a normal TCP > SYN-only packet. We like to think that these things are true, but in general, even when a spec says to ignore such things we already find endpoints that don't. So we need to validate that first. > So for IPv6, it is possible to transmit the expanded TCP option > space in the same packet in a manner that won't confuse legacy IPv6/TCP > implementations. > > A solution for extended TCP option space in SYN-only packets doesn’t > need to be the same for IPv4/TCP and IPv6/TCP. If we can have a clean > solution for IPv6, we should do that rather than force a less-than > desireable IPv4 solution on IPv6 connections. In principle, I agree, but I don't think you've found anything but a different way to have middleboxes mess things up. Joe From nobody Wed Nov 12 15:56: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 0EBA11A0065 for ; Wed, 12 Nov 2014 15:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 CPkgt38uZ2n8 for ; Wed, 12 Nov 2014 15:56:08 -0800 (PST) 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 A565E1A0053 for ; Wed, 12 Nov 2014 15:56:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="209967434" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx12-out.netapp.com with ESMTP; 12 Nov 2014 15:56:08 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 12 Nov 2014 15:56:07 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Wed, 12 Nov 2014 15:56:07 -0800 From: "Scheffenegger, Richard" To: "Jakob Heitz (jheitz)" , "tcpm@ietf.org" Thread-Topic: [tcpm] FW: New Version Notification for draft-heitzhe-tcpm-vm-rto-00.txt Thread-Index: AQHP6/e/GE8jE6PowUuTOG76K4IJ05w4ImxwgCWoZwA= Date: Wed, 12 Nov 2014 23:56:06 +0000 Message-ID: References: <20141019235228.23107.88305.idtracker@ietfa.amsl.com> <075DE01702BBC249BE1357EFD20DCFE50D93B959@xmb-aln-x02.cisco.com> In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE50D93B959@xmb-aln-x02.cisco.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/bXbt103uXwTkmepjGCz8qnGodaI Cc: Chuan He Subject: Re: [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: Wed, 12 Nov 2014 23:56:12 -0000 Hi Jakob, I read your draft; the references section is imho missing a reference to H.= Ekstr=F6m, R. Ludwig, "The Peak-Hopper", INFOCOM 2004;=20 http://www.cs.helsinki.fi/u/gurtov/reiner/PeakHopper_draft0207.pdf as is a detailed discussion why that modification or rfc6298 is not applica= ble. =20 A comparison of this new mechanism with the (adjusted) EDWA of RFC6298 or = other schemes should be given. Also, although the introduction clearly stat= es that this mechanism is mostly for virtulized environments, a formal appl= icability statement might be good. Ie. can that algorithm applied safely fo= r non-VM environments? What is the impact of omitting the RTT variance sign= al into the RTO calculation? (And, was the baseline truly RFC6298, or the Linux RTO algorithm, which is = subtly different and adjust much quicker to lower RTOs once the lower limit= is removed) Technically: the last sentence of section 2 say: "A window of data is the l= argest ever advertised window of a session." First, I think this definition= should be moved to point 2 above; but even then, it's not clear to me if t= his really is a sensible choice; with many TCPs advertising many 100 kB or = even MB of window for application-limited flows, the interval (20*advertise= d window) could be many seconds or even minutes, when the RTO would be adju= sted down... In particular, for latency-sensitive, low-bandwidth and application-limited= flows, that announce a comparatively large window, this appears to artific= ially delay the completion time of that kind of transactions. Also, taking = an spurious RTO, with the changes to the CC state not being unwound by ie. = Eiffel-reaction, is much less critical in that circumstances than for bulk = transfers. The draft is also not clear on its interaction with per-packet RTT measurem= ent vs. one-per-window (send window, not advertised window) RTT measurement= . Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Jakob Heitz > (jheitz) > Sent: Sonntag, 19. Oktober 2014 14:41 > To: tcpm@ietf.org > Cc: Chuan He > Subject: [tcpm] FW: New Version Notification for draft-heitzhe-tcpm-vm- > rto-00.txt >=20 > Hi TCPM, >=20 > We were experimenting with TCP code in a VM setting. > We reduced the minimum RTO, because average RTT should be much lower than > 1 second. > We got lots of spurious retransmissions in a heavily loaded host. > As a result, we developed an alternative to the exponential weighted > moving average algorithm to determine the RTO. It operates well without > any minimum RTO setting. >=20 > Please take a look and comment. >=20 > --Jakob >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, October 19, 2014 4:52 PM > To: Jakob Heitz (jheitz); Chuan He; Chuan He; Jakob Heitz (jheitz) > Subject: New Version Notification for draft-heitzhe-tcpm-vm-rto-00.txt >=20 >=20 > A new version of I-D, draft-heitzhe-tcpm-vm-rto-00.txt has been > successfully submitted by Jakob Heitz and posted to the IETF repository. >=20 > Name: draft-heitzhe-tcpm-vm-rto > Revision: 00 > Title: TCP Retransmission Timer for Virtual Machines > Document date: 2014-10-19 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-heitzhe-tcpm-vm= - > rto-00.txt > Status: https://datatracker.ietf.org/doc/draft-heitzhe-tcpm-vm- > rto/ > Htmlized: http://tools.ietf.org/html/draft-heitzhe-tcpm-vm-rto-00 >=20 >=20 > Abstract: > A Round Trip Time (RTT) estimate that decays performs badly in a > bursty environment. A round trip time estimator that does not decay > for a period of time is proposed. >=20 > It does not require a minimum value to be configured. It works > equally well when the typical RTT is 100uS as when it is 10 seconds. >=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 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Nov 12 17:09: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 656551A00AD for ; Wed, 12 Nov 2014 17:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 6Qt0iJIBZZa3 for ; Wed, 12 Nov 2014 17:09:47 -0800 (PST) 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 6B1101A0089 for ; Wed, 12 Nov 2014 17:09:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,372,1413270000"; d="scan'208";a="209985339" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx12-out.netapp.com with ESMTP; 12 Nov 2014 17:09:44 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 12 Nov 2014 17:09:44 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Wed, 12 Nov 2014 17:09:44 -0800 From: "Scheffenegger, Richard" To: "Zimmermann, Alexander" , Joe Touch , "tcpm@ietf.org" Thread-Topic: Comments to draft-ietf-tcpm-tcp-edo-01 Thread-Index: AQHP+5a2cOj8sE61IEa95k8BL3Gnt5xdwCoA Date: Thu, 13 Nov 2014 01:09:43 +0000 Message-ID: <2699810435114b7c8e9befda4255eb38@hioexcmbx05-prd.hq.netapp.com> References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> In-Reply-To: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jQCwWDDk34I4QeC8ns2x6CkMvMs Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Thu, 13 Nov 2014 01:09:49 -0000 DQpBbm90aGVyIHBvaW50Og0KDQoqIFBhZ2UgNDog4oCeQSBudWxsIEVETyBsZW5ndGggb3B0aW9u IGNvbnRhaW5zIHRoZSBzYW1lIHZhbHVlIGFzIHRoZSBETyBmaWVsZCwgaS5lLiwgaXQgZG9lcyBu b3QgZXh0ZW5kIHRoZSBUQ1Agb3B0aW9uIHNwYWNl4oCcDQoNCiJETyBmaWVsZCIgaXMgbm90IGZv cm1hbGx5IG1lbnRpb25lZCBwcmlvciB0byB0aGlzIGluc3RhbmNlIGluIHRoZSBkcmFmdDsgSWYg dGhlIC0wMiBtZW50aW9uZXMgaXQgaW4gb3RoZXIgcGxhY2VzLCBJIHN1Z2dlc3QgdG8gaW50cm9k dWNlIGl0IHNvbWV3aGVyZSAiLi4uIHRoZSBUQ1AgaGVhZGVyIGRhdGEgb2Zmc2V0IGZpZWxkIChE TyBmaWVsZCkiLCBvciBhbHRlcm5hdGl2ZWx5IHNpbXBseSByZWZlciB0byBpdCBpbiBmdWxsIHdv cmRzLg0KDQoNCg0KDQoiV2hlbiB0aGUgRURPIGxlbmd0aCBpcyBpbnZhbGlkLCB0aGUgVENQCXNl Z21lbnQgTVVTVCBiZSBzaWxlbnRseSBkcm9wcGVkIg0KDQpXaGVuIGlzIEVETyBsZW5ndGggaW52 YWxpZD8gSXMgdGhhdCBtZWFudCB0byByZWZlciB0byB0aGUgbGVuZ3RoIGZpZWxkIG9mIHRoZSBF RE8gb3B0aW9uICg0KSwgb3IgdGhlICJlZG8gbGVuZ3RoIG9wdGlvbiIgYXMgYSB3aG9sZSwgaWUu IHdoZW4gdGhlIEhlYWRlcl9sZW5ndGggaXMgPCBETywgKGluY2x1c2l2ZSkgb3IgPiBTZWdlbWVu dF9MZW5ndGg/DQoNCiANCkJlc3QgcmVnYXJkcywNCg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGNwbSBbbWFpbHRvOnRjcG0t Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFppbW1lcm1hbm4sDQo+IEFsZXhhbmRlcg0K PiBTZW50OiBTYW1zdGFnLCAwOC4gTm92ZW1iZXIgMjAxNCAxMDo1OA0KPiBUbzogSm9lIFRvdWNo OyB0Y3BtQGlldGYub3JnDQo+IFN1YmplY3Q6IFt0Y3BtXSBDb21tZW50cyB0byBkcmFmdC1pZXRm LXRjcG0tdGNwLWVkby0wMQ0KPiANCj4gSGkgSm9lLA0KPiANCj4geWVzdGVyZGF5IEkgZm91bmQg c29tZSB0aW1lIHRvIHJlLXJlYWQgdGhlIGRyYWZ0LiBBIGNvdXBsZSBvZiBwb2ludHMNCj4gDQo+ ICoqKiBUZWNobmljYWwgKioqDQo+IA0KPiAqIFRoZSB3aG9sZSBkcmFmdHMgcmVhZHMgbGlrZSB3 ZSBoYXZlICp0d28qIEVETyBvcHRpb25zLCBha2EgdGhlIOKAnlRDUCBFRE8NCj4gcmVxdWVzdCBv cHRpb27igJwgYW5kIHRoZSDigJ5UQ1AgRURPIGxlbmd0aCBvcHRpb27igJwsIGJ1dCBhY3R1YWxs eSB3ZSBvbmx5IGhhdmUNCj4gb25lIG9wdGlvbiwgdGhlIEVETyBvcHRpb24uIEkgZm91bmQgdGhp cyBhIGJpdCBjb25mdXNpbmcuIFNheWluZyB0aGlzLCB3aHkNCj4gZG8gd2Ugbm90IGluY2x1ZGUg dGhlIEhlYWRlcl9sZW5ndGggZmllbGQgaW4gYW55IEVETyBmcmFtZSwgaS5lLiBhbHNvIGluDQo+ IHRoZSBTWU4uIEZvciBzaWduYWxpbmcgKEVETyBuZWdvdGlhdGlvbikgd2UgY2FuIHVzZSB2YWx1 ZXMgZm9yIHRoZQ0KPiBIZWFkZXJfbGVuZ3RoIHRoYXQgYXJlIGxlc3MgdGhhbiB0aGUgRE8gdmFs dWUuDQo+IA0KPiAqIFBhZ2UgNDog4oCeQSBudWxsIEVETyBsZW5ndGggb3B0aW9uIGNvbnRhaW5z IHRoZSBzYW1lIHZhbHVlIGFzIHRoZSBETw0KPiBmaWVsZCwgaS5lLiwgaXQgZG9lcyBub3QgZXh0 ZW5kIHRoZSBUQ1Agb3B0aW9uIHNwYWNl4oCcIFBlcnNvbmFsbHksIEkgZG9u4oCZdA0KPiBsaWtl IHRoZSB0ZXJtIOKAnm51bGzigJwgYmVjYXVzZSBpdCBnaXZlcyAoYXQgbGVhc3QgbWUpIHRoZSB3 cm9uZyBpbXByZXNzaW9uDQo+IHRoYXQgdGhlIEhlYWRlcl9sZW5ndGggY29udGFpbnMgMC4gQ291 bGQgd2Ugc2F5IOKAnm5ldXRyYWzigJwgaW5zdGVhZCBvZg0KPiDigJ5udWxs4oCcPw0KPiANCj4g KiBQYWdlIDU6IOKAnldoZW4gcHJvY2Vzc2luZyBhIHNlZ21lbnQsIEVETyBuZWVkcyB0byBiZSB2 aXNpYmxlIHdpdGhpbiB0aGUNCj4gYXJlYSBpbmRpY2F0ZWQgYnkgdGhlIERhdGEgT2Zmc2V0IGZp ZWxk4oCcLiBCZSBtb3JlIGV4cGVjdCBoZXJlLCBieSBzYXlpbmcNCj4gdGhhdCB0aGUgRURPIG9w dGlvbiBtdXN0IGJlIGluIHRoZSBmaXJzdCA0MCBCeXRlcyBhZnRlciB0aGUgZml4ZWQgVENQDQo+ IGhlYWRlci4gSU1PIGl0IG1ha2VzIGl0IGEgYml0IG1vcmUgY2xlYXJlci4NCj4gDQo+IA0KPiAq KiogRWRpdG9yaWFsICoqKg0KPiANCj4gKiBQYWdlIDY6IFBlcnNvbmFsbHksIEkgd291bGQgc3dh cCB0aGUgdGV4dCBhbmQgc3BlYWsgZmlyc3QgYWJvdXQgdGhlDQo+IHBsYWNlbWVudCBvZiB0aGUg RURPIG9wdGlvbiBhbmQgdGhlbiBhYm91dCB0aGUgYWxpZ25tZW50Lg0KPiANCj4gKiBTZWN0aW9u IDcgUmVsYXRlZCBXb3JrIC0gaW50byBhbiBhcHBlbmRpeD8NCj4gDQo+IA0KPiAqKiogTml0cyAq KioNCj4gDQo+ICogcGFnZSAxMzog4oCeVGhlIGZvbGxvd2luZyBkaXNjdXNzZXMgdGhyZWUgb2Yg dGhlIG1vc3Qgbm90YWJsZSBwYXN0IOKApuKAnA0KPiBBY3R1YWxseSwgeW91IGRpc2N1c3MgNCBh cHByb2FjaGVzLg0KPiANCj4gKiBTZWMuIDEyOiBBY2tub3dsZWRnbWVudHMuIExhc3Qgd29yZC4g VGhlcmUgaXMgYSBtaXNzaW5nIOKAnm7igJwgYXQgdGhlIGVuZA0KPiBvZiB0aGUgbmFtZSA6LSkN Cj4gDQo+IEFsZXgNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo= From nobody Wed Nov 12 21:21: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 5683E1A1B7A for ; Wed, 12 Nov 2014 21:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 ra7GTe_PWVKq for ; Wed, 12 Nov 2014 21:21:09 -0800 (PST) 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 17D831A1B82 for ; Wed, 12 Nov 2014 21:21:09 -0800 (PST) Received: from [192.168.1.10] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id sAD5Kson010298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Nov 2014 21:21:04 -0800 (PST) Message-ID: <54643FB6.7040209@isi.edu> Date: Wed, 12 Nov 2014 21:20:54 -0800 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: "Scheffenegger, Richard" , "Zimmermann, Alexander" , "tcpm@ietf.org" References: <792DFDE0-4E55-4538-9122-98D66D9FDF0A@netapp.com> <2699810435114b7c8e9befda4255eb38@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <2699810435114b7c8e9befda4255eb38@hioexcmbx05-prd.hq.netapp.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/FMeGvdcrjPtxFOZD2esBuU2e-rQ Subject: Re: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-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: Thu, 13 Nov 2014 05:21:10 -0000 Hi, Richard, Thanks for the additional comments. Notes below... Joe On 11/12/2014 5:09 PM, Scheffenegger, Richard wrote: > > Another point: > > * Page 4: „A null EDO length option contains the same value as the > DO field, i.e., it does not extend the TCP option space“ > > "DO field" is not formally mentioned prior to this instance in the > draft; If the -02 mentiones it in other places, I suggest to introduce > it somewhere "... the TCP header data offset field (DO field)", or > alternatively simply refer to it in full words. Will fix (in the first sentence of the Intro). > "When the EDO length is invalid, the TCP segment MUST be silently > dropped" > > When is EDO length invalid? Is that meant to refer to the length > field of the EDO option (4), or the "edo length option" as a whole, > ie. when the Header_length is < DO, (inclusive) or > > Segment_Length? There are two different issues for validity, as you point out: a well-formed EDO option a meaningful EDO length field value I'll revise and clarify accordingly. --- From nobody Thu Nov 13 11:27: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 847201ACDF4 for ; Thu, 13 Nov 2014 11:27:33 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gRudRQzsvJ56 for ; Thu, 13 Nov 2014 11:27:31 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B8A1ACDC0 for ; Thu, 13 Nov 2014 11:25:20 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so593139wiw.4 for ; Thu, 13 Nov 2014 11:25:18 -0800 (PST) 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=R0J7i/gnrPJtV+LJWFt1w29zNlQCAmVTT/KPwEC3WxE=; b=P3pHSfFFm73+pJTDzIRt/Dd7Sf2sdcytKeoscTgFjjhbtLY5LJXADGcJBGtNcTczVt 9yVWw8fxYkCm343HUPdya4nwC97aBXCkaTW4N+iVDS7kZeHiXq/5s0gAjBcVA7JdCl7v I+LayHwC3yD90qPUptXmvJ4j0xikrA9H/ijXvl0P5EWSIVP/f5fPFjtsxKWkZCMdwNTM fnmf32UzyJVBV9R9EoFtMg6PU1OwhNKnyV4sl+hpOtgesNtMtvcH/CDdwLhGimM8nvZv fGVWzUvuCIhhD+QNRzJcV5Vv7jNi8NHcQ7L2IV5ke3H9TdEI19MLGGw0X1ADIjisbMF6 eV/w== X-Gm-Message-State: ALoCoQlIspTHipCKwwDvdLYp8ua4PVV8BHYkiuvrO91TkrkvogEAnHsBXnNJ44SHqs9Bh1gDgu6p MIME-Version: 1.0 X-Received: by 10.180.93.233 with SMTP id cx9mr1151762wib.48.1415906718781; Thu, 13 Nov 2014 11:25:18 -0800 (PST) Received: by 10.194.72.129 with HTTP; Thu, 13 Nov 2014 11:25:18 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 20:25:18 +0100 Message-ID: From: Olivier Bonaventure To: David Borman Content-Type: multipart/alternative; boundary=f46d043894810223de0507c27943 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lvEcd3At0e4uzoK3zZuzWk9UfO4 Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Other places for extended TCP options in SYN-only packets 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, 13 Nov 2014 19:27:34 -0000 --f46d043894810223de0507c27943 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David, > But then I started thinking about IPv6/TCP. Additional TCP option space > could be encoded into an IPv6 Destination Options header. The advantages > of this over IPv4 are: > 1) There is almost 2K of space; though each option is limited to 255 > bytes, multiple options could be allowed if that became necessary. > 2) Destination Options headers are not processed at intermediate hops. > 3) With the top 2 bits of the option type set to zero, it will be > ignored by hosts that don=E2=80=99t understand it. > 4) Hosts that don=E2=80=99t understand it will just see it as a normal = TCP > SYN-only packet. > > So for IPv6, it is possible to transmit the expanded TCP option space in > the same packet in a manner that won't confuse legacy IPv6/TCP > implementations > I think that this is the cleanest possible solution with regular TCP. For MPTCP, we adopt a similar approach as the control stream draft to encode options in the payload https://tools.ietf.org/html/draft-paasch-mptcp-control-stream-00 > A solution for extended TCP option space in SYN-only packets doesn=E2=80= =99t need > to be the same for IPv4/TCP and IPv6/TCP. If we can have a clean solutio= n > for IPv6, we should do that rather than force a less-than desireable IPv4 > solution on IPv6 connections. > I completely agree. If we can solve the issue for IPv6, we are future proof. We cannot live forever with all the IPv4 problems and IPv6 is being widely deployed Olivier --f46d043894810223de0507c27943 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,


But then I started thinking about IPv6/TCP.=C2=A0 Additional TCP option spa= ce could be encoded into an IPv6 Destination Options header.=C2=A0 The adva= ntages of this over IPv4 are:
=C2=A0 1) There is almost 2K of space; though each option is limited to 255= bytes, multiple options could be allowed if that became necessary.
=C2=A0 2) Destination Options headers are not processed at intermediate hop= s.
=C2=A0 3) With the top 2 bits of the option type set to zero, it will be ig= nored by hosts that don=E2=80=99t understand it.
=C2=A0 4) Hosts that don=E2=80=99t understand it will just see it as a norm= al TCP SYN-only packet.

So for IPv6, it is possible to transmit the expanded TCP option space in th= e same packet in a manner that won't confuse legacy IPv6/TCP implementa= tions

I think that this is the cleanest= possible solution with regular TCP. For MPTCP, we adopt a similar approach= as the control stream draft to encode options in the payload
h= ttps://tools.ietf.org/html/draft-paasch-mptcp-control-stream-00
=C2=A0
A solution for extended TCP option space in SYN-only packets doesn=E2=80=99= t need to be the same for IPv4/TCP and IPv6/TCP.=C2=A0 If we can have a cle= an solution for IPv6, we should do that rather than force a less-than desir= eable IPv4 solution on IPv6 connections.

I completely agree. If we can solve the issue for IPv6, we are future pro= of. We cannot live forever with all the IPv4 problems and IPv6 is being wid= ely deployed


Olivier
--f46d043894810223de0507c27943-- From nobody Thu Nov 13 11:57: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 BC2C01ACE96 for ; Thu, 13 Nov 2014 11:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 NOx7AGMVKKtX for ; Thu, 13 Nov 2014 11:57:10 -0800 (PST) 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 A0E231ACEFC for ; Thu, 13 Nov 2014 11:57:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,379,1413270000"; d="scan'208,217";a="167298129" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx11-out.netapp.com with ESMTP; 13 Nov 2014 11:57:10 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 13 Nov 2014 11:57:09 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Thu, 13 Nov 2014 11:57:09 -0800 From: "Scheffenegger, Richard" To: Olivier Bonaventure , David Borman Thread-Topic: [tcpm] Other places for extended TCP options in SYN-only packets Thread-Index: AQHP/eLPe4yItSjICEmFvAUkpQ0/iZxfeXQA//+BQ1A= Date: Thu, 13 Nov 2014 19:57:08 +0000 Message-ID: <33951b2f1fa441c8902c1d129faadd19@hioexcmbx05-prd.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.36] Content-Type: multipart/alternative; boundary="_000_33951b2f1fa441c8902c1d129faadd19hioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/k9EYSGtxbfgDrI9zrykUTl-JmBo Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Other places for extended TCP options in SYN-only packets 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, 13 Nov 2014 19:57:16 -0000 --_000_33951b2f1fa441c8902c1d129faadd19hioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIE1pY2hpbyBIb25kYeKAmXMgd29yayBwb2ludGVkIG91dCwgdGhhdCBJUHY2IERl c3RPcHQgY3VycmVudGx5IGRvZXMgbm90IHdvcmsgb24gMTYtMTclIElQdjYgcGF0aHMgaW4gdGhl IGludGVybmV04oCmDQoNCkZpbmFsbHksIGl0IHNlZW1zIHRoZXJlIGlzICBhIGxhcmdlIG51bWJl ciBvZiBwcm9wb3NhbHMgbWFraW5nIHVzZSBvZiBEZXN0T3B0IGZvciB2YXJpb3VzIHB1cnBvc2Vz IGN1cnJlbnRseS4NCg0KSSB3b25kZXIgaG93IG11Y2ggYWN0dWFsbHkgdXNlZnVsIGRhdGEgY2Fu IGV2ZW50dWFsbHkgYmUgZGVsaXZlcmVkIHBlciBzZWdtZW50IGlmIGFsbCB0aGVzZSBEZXN0T3B0 IHVzZXMgd291bGQgYmUgZGVwbG95ZWTigKYNCg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCg0K RnJvbTogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9s aXZpZXIgQm9uYXZlbnR1cmUNClNlbnQ6IERvbm5lcnN0YWcsIDEzLiBOb3ZlbWJlciAyMDE0IDA5 OjI1DQpUbzogRGF2aWQgQm9ybWFuDQpDYzogdGNwbUBpZXRmLm9yZyAodGNwbUBpZXRmLm9yZykN ClN1YmplY3Q6IFJlOiBbdGNwbV0gT3RoZXIgcGxhY2VzIGZvciBleHRlbmRlZCBUQ1Agb3B0aW9u cyBpbiBTWU4tb25seSBwYWNrZXRzDQoNCkRhdmlkLA0KDQoNCkJ1dCB0aGVuIEkgc3RhcnRlZCB0 aGlua2luZyBhYm91dCBJUHY2L1RDUC4gIEFkZGl0aW9uYWwgVENQIG9wdGlvbiBzcGFjZSBjb3Vs ZCBiZSBlbmNvZGVkIGludG8gYW4gSVB2NiBEZXN0aW5hdGlvbiBPcHRpb25zIGhlYWRlci4gIFRo ZSBhZHZhbnRhZ2VzIG9mIHRoaXMgb3ZlciBJUHY0IGFyZToNCiAgMSkgVGhlcmUgaXMgYWxtb3N0 IDJLIG9mIHNwYWNlOyB0aG91Z2ggZWFjaCBvcHRpb24gaXMgbGltaXRlZCB0byAyNTUgYnl0ZXMs IG11bHRpcGxlIG9wdGlvbnMgY291bGQgYmUgYWxsb3dlZCBpZiB0aGF0IGJlY2FtZSBuZWNlc3Nh cnkuDQogIDIpIERlc3RpbmF0aW9uIE9wdGlvbnMgaGVhZGVycyBhcmUgbm90IHByb2Nlc3NlZCBh dCBpbnRlcm1lZGlhdGUgaG9wcy4NCiAgMykgV2l0aCB0aGUgdG9wIDIgYml0cyBvZiB0aGUgb3B0 aW9uIHR5cGUgc2V0IHRvIHplcm8sIGl0IHdpbGwgYmUgaWdub3JlZCBieSBob3N0cyB0aGF0IGRv buKAmXQgdW5kZXJzdGFuZCBpdC4NCiAgNCkgSG9zdHMgdGhhdCBkb27igJl0IHVuZGVyc3RhbmQg aXQgd2lsbCBqdXN0IHNlZSBpdCBhcyBhIG5vcm1hbCBUQ1AgU1lOLW9ubHkgcGFja2V0Lg0KDQpT byBmb3IgSVB2NiwgaXQgaXMgcG9zc2libGUgdG8gdHJhbnNtaXQgdGhlIGV4cGFuZGVkIFRDUCBv cHRpb24gc3BhY2UgaW4gdGhlIHNhbWUgcGFja2V0IGluIGEgbWFubmVyIHRoYXQgd29uJ3QgY29u ZnVzZSBsZWdhY3kgSVB2Ni9UQ1AgaW1wbGVtZW50YXRpb25zDQoNCkkgdGhpbmsgdGhhdCB0aGlz IGlzIHRoZSBjbGVhbmVzdCBwb3NzaWJsZSBzb2x1dGlvbiB3aXRoIHJlZ3VsYXIgVENQLiBGb3Ig TVBUQ1AsIHdlIGFkb3B0IGEgc2ltaWxhciBhcHByb2FjaCBhcyB0aGUgY29udHJvbCBzdHJlYW0g ZHJhZnQgdG8gZW5jb2RlIG9wdGlvbnMgaW4gdGhlIHBheWxvYWQNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1wYWFzY2gtbXB0Y3AtY29udHJvbC1zdHJlYW0tMDANCg0KQSBzb2x1 dGlvbiBmb3IgZXh0ZW5kZWQgVENQIG9wdGlvbiBzcGFjZSBpbiBTWU4tb25seSBwYWNrZXRzIGRv ZXNu4oCZdCBuZWVkIHRvIGJlIHRoZSBzYW1lIGZvciBJUHY0L1RDUCBhbmQgSVB2Ni9UQ1AuICBJ ZiB3ZSBjYW4gaGF2ZSBhIGNsZWFuIHNvbHV0aW9uIGZvciBJUHY2LCB3ZSBzaG91bGQgZG8gdGhh dCByYXRoZXIgdGhhbiBmb3JjZSBhIGxlc3MtdGhhbiBkZXNpcmVhYmxlIElQdjQgc29sdXRpb24g b24gSVB2NiBjb25uZWN0aW9ucy4NCg0KSSBjb21wbGV0ZWx5IGFncmVlLiBJZiB3ZSBjYW4gc29s dmUgdGhlIGlzc3VlIGZvciBJUHY2LCB3ZSBhcmUgZnV0dXJlIHByb29mLiBXZSBjYW5ub3QgbGl2 ZSBmb3JldmVyIHdpdGggYWxsIHRoZSBJUHY0IHByb2JsZW1zIGFuZCBJUHY2IGlzIGJlaW5nIHdp ZGVseSBkZXBsb3llZA0KDQoNCk9saXZpZXINCg== --_000_33951b2f1fa441c8902c1d129faadd19hioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkRFLUFUIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSBNaWNoaW8gSG9u ZGHigJlzIHdvcmsgcG9pbnRlZCBvdXQsIHRoYXQgSVB2NiBEZXN0T3B0IGN1cnJlbnRseSBkb2Vz IG5vdCB3b3JrIG9uIDE2LTE3JSBJUHY2IHBhdGhzIGluIHRoZSBpbnRlcm5ldOKApjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GaW5hbGx5LCBpdCBzZWVtcyB0aGVyZSBpcyZu YnNwOyBhIGxhcmdlIG51bWJlciBvZiBwcm9wb3NhbHMgbWFraW5nIHVzZSBvZiBEZXN0T3B0IGZv ciB2YXJpb3VzIHB1cnBvc2VzIGN1cnJlbnRseS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIHdvbmRlciBob3cgbXVjaCBhY3R1YWxseSB1c2VmdWwgZGF0YSBjYW4gZXZl bnR1YWxseSBiZSBkZWxpdmVyZWQgcGVyIHNlZ21lbnQgaWYgYWxsIHRoZXNlIERlc3RPcHQgdXNl cyB3b3VsZCBiZSBkZXBsb3llZOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJpY2hhcmQgU2No ZWZmZW5lZ2dlcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+T2xpdmllciBCb25hdmVudHVyZTxicj4NCjxi PlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAxMy4gTm92ZW1iZXIgMjAxNCAwOToyNTxicj4NCjxiPlRv OjwvYj4gRGF2aWQgQm9ybWFuPGJyPg0KPGI+Q2M6PC9iPiB0Y3BtQGlldGYub3JnICh0Y3BtQGll dGYub3JnKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIE90aGVyIHBsYWNlcyBmb3Ig ZXh0ZW5kZWQgVENQIG9wdGlvbnMgaW4gU1lOLW9ubHkgcGFja2V0czxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZCw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQnV0IHRoZW4gSSBz dGFydGVkIHRoaW5raW5nIGFib3V0IElQdjYvVENQLiZuYnNwOyBBZGRpdGlvbmFsIFRDUCBvcHRp b24gc3BhY2UgY291bGQgYmUgZW5jb2RlZCBpbnRvIGFuIElQdjYgRGVzdGluYXRpb24gT3B0aW9u cyBoZWFkZXIuJm5ic3A7IFRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgb3ZlciBJUHY0IGFyZTo8YnI+ DQombmJzcDsgMSkgVGhlcmUgaXMgYWxtb3N0IDJLIG9mIHNwYWNlOyB0aG91Z2ggZWFjaCBvcHRp b24gaXMgbGltaXRlZCB0byAyNTUgYnl0ZXMsIG11bHRpcGxlIG9wdGlvbnMgY291bGQgYmUgYWxs b3dlZCBpZiB0aGF0IGJlY2FtZSBuZWNlc3NhcnkuPGJyPg0KJm5ic3A7IDIpIERlc3RpbmF0aW9u IE9wdGlvbnMgaGVhZGVycyBhcmUgbm90IHByb2Nlc3NlZCBhdCBpbnRlcm1lZGlhdGUgaG9wcy48 YnI+DQombmJzcDsgMykgV2l0aCB0aGUgdG9wIDIgYml0cyBvZiB0aGUgb3B0aW9uIHR5cGUgc2V0 IHRvIHplcm8sIGl0IHdpbGwgYmUgaWdub3JlZCBieSBob3N0cyB0aGF0IGRvbuKAmXQgdW5kZXJz dGFuZCBpdC48YnI+DQombmJzcDsgNCkgSG9zdHMgdGhhdCBkb27igJl0IHVuZGVyc3RhbmQgaXQg d2lsbCBqdXN0IHNlZSBpdCBhcyBhIG5vcm1hbCBUQ1AgU1lOLW9ubHkgcGFja2V0Ljxicj4NCjxi cj4NClNvIGZvciBJUHY2LCBpdCBpcyBwb3NzaWJsZSB0byB0cmFuc21pdCB0aGUgZXhwYW5kZWQg VENQIG9wdGlvbiBzcGFjZSBpbiB0aGUgc2FtZSBwYWNrZXQgaW4gYSBtYW5uZXIgdGhhdCB3b24n dCBjb25mdXNlIGxlZ2FjeSBJUHY2L1RDUCBpbXBsZW1lbnRhdGlvbnM8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhh dCB0aGlzIGlzIHRoZSBjbGVhbmVzdCBwb3NzaWJsZSBzb2x1dGlvbiB3aXRoIHJlZ3VsYXIgVENQ LiBGb3IgTVBUQ1AsIHdlIGFkb3B0IGEgc2ltaWxhciBhcHByb2FjaCBhcyB0aGUgY29udHJvbCBz dHJlYW0gZHJhZnQgdG8gZW5jb2RlIG9wdGlvbnMgaW4gdGhlIHBheWxvYWQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWFzY2gtbXB0Y3AtY29udHJvbC1zdHJlYW0tMDAi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWFzY2gtbXB0Y3AtY29udHJvbC1z dHJlYW0tMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkEgc29sdXRpb24gZm9yIGV4dGVuZGVkIFRDUCBvcHRpb24gc3BhY2Ug aW4gU1lOLW9ubHkgcGFja2V0cyBkb2VzbuKAmXQgbmVlZCB0byBiZSB0aGUgc2FtZSBmb3IgSVB2 NC9UQ1AgYW5kIElQdjYvVENQLiZuYnNwOyBJZiB3ZSBjYW4gaGF2ZSBhIGNsZWFuIHNvbHV0aW9u IGZvciBJUHY2LCB3ZSBzaG91bGQgZG8gdGhhdCByYXRoZXIgdGhhbiBmb3JjZSBhIGxlc3MtdGhh biBkZXNpcmVhYmxlIElQdjQgc29sdXRpb24gb24gSVB2Ng0KIGNvbm5lY3Rpb25zLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBj b21wbGV0ZWx5IGFncmVlLiBJZiB3ZSBjYW4gc29sdmUgdGhlIGlzc3VlIGZvciBJUHY2LCB3ZSBh cmUgZnV0dXJlIHByb29mLiBXZSBjYW5ub3QgbGl2ZSBmb3JldmVyIHdpdGggYWxsIHRoZSBJUHY0 IHByb2JsZW1zIGFuZCBJUHY2IGlzIGJlaW5nIHdpZGVseSBkZXBsb3llZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9saXZpZXI8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_33951b2f1fa441c8902c1d129faadd19hioexcmbx05prdhqnetappc_-- From nobody Thu Nov 13 20:25: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 1C5271A6F20 for ; Thu, 13 Nov 2014 20:25:26 -0800 (PST) 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 2jyrleAsl6bR for ; Thu, 13 Nov 2014 20:25:23 -0800 (PST) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 49B4E1A6EFE for ; Thu, 13 Nov 2014 20:25:23 -0800 (PST) Received: from [10.14.11.136] (173.197.107.11) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5462939B00427277 for tcpm@ietf.org; Fri, 14 Nov 2014 06:25:22 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8C3175E8-9A3A-4DF5-81D2-763ADC61B930@iki.fi> Date: Thu, 13 Nov 2014 18:25:18 -1000 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/JmA5x47PkopPcjVOy2XYGIkFoDE Subject: [tcpm] Meeting minutes 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, 14 Nov 2014 04:25:26 -0000 Hi, Draft TCPM meeting minutes from Monday are available at = http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm . Please send = any corrections to tcpm-chairs. Many thanks to Mirja and Richard for taking notes! - Pasi From nobody Thu Nov 13 22:15: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 4255F1A6FD4 for ; Thu, 13 Nov 2014 22:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 Evqzzg3nvJsP for ; Thu, 13 Nov 2014 22:15:18 -0800 (PST) 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 5CC6C1A0144 for ; Thu, 13 Nov 2014 22:15:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,384,1413270000"; d="scan'208";a="210291695" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx12-out.netapp.com with ESMTP; 13 Nov 2014 22:15:11 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 13 Nov 2014 22:15:10 -0800 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5d98:1529:da8c:ea24%21]) with mapi id 15.00.0995.031; Thu, 13 Nov 2014 22:15:11 -0800 From: "Zimmermann, Alexander" To: Pasi Sarolahti Thread-Topic: [tcpm] Meeting minutes Thread-Index: AQHP/8MVeBiFukjMbUKiuHcJUGWsOZxgK0SA Date: Fri, 14 Nov 2014 06:15:10 +0000 Message-ID: References: <8C3175E8-9A3A-4DF5-81D2-763ADC61B930@iki.fi> In-Reply-To: <8C3175E8-9A3A-4DF5-81D2-763ADC61B930@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.120.60.34] Content-Type: text/plain; charset="utf-8" Content-ID: <5EDAA65186677F469E9751BCA3F67AE5@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/88N0SKPr5uU1OTVTnjQVJCTgFKE Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Meeting minutes 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, 14 Nov 2014 06:15:20 -0000 aW4gdGhlIEN1YmljIFNlY3Rpb246IGhpZ2ggc3RhcnQg4oCUPiBIeVN0YXJ0DQoNCj4gQW0gMTMu MTEuMjAxNCB1bSAxODoyNSBzY2hyaWViIFBhc2kgU2Fyb2xhaHRpIDxwYXNpLnNhcm9sYWh0aUBp a2kuZmk+Og0KPiANCj4gSGksDQo+IA0KPiBEcmFmdCBUQ1BNIG1lZXRpbmcgbWludXRlcyBmcm9t IE1vbmRheSBhcmUgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTEvbWludXRlcy9taW51dGVzLTkxLXRjcG0gLiBQbGVhc2Ugc2VuZCBhbnkgY29ycmVjdGlvbnMg dG8gdGNwbS1jaGFpcnMuDQo+IA0KPiBNYW55IHRoYW5rcyB0byBNaXJqYSBhbmQgUmljaGFyZCBm b3IgdGFraW5nIG5vdGVzIQ0KPiANCj4gLSBQYXNpDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3Bt QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K DQo= From nobody Fri Nov 14 14:47: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 8170E1AD1A3 for ; Fri, 14 Nov 2014 14:47:40 -0800 (PST) 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, 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 6axRK3tYG2pj for ; Fri, 14 Nov 2014 14:47:38 -0800 (PST) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA841AD1BA for ; Fri, 14 Nov 2014 14:47:38 -0800 (PST) Received: from dhcp-b766.meeting.ietf.org (31.133.183.102) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 54629344005C0A63; Sat, 15 Nov 2014 00:47:35 +0200 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: Fri, 14 Nov 2014 12:47:28 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4A3C319D-A607-480F-8429-2C9422C95523@iki.fi> References: <8C3175E8-9A3A-4DF5-81D2-763ADC61B930@iki.fi> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Id64QygQbQ4S0QplX2QQRuOyq8g Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Meeting minutes 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, 14 Nov 2014 22:47:40 -0000 Thanks, fixed in my local copy. I will upload a new version after a = couple of days, giving a bit time for other possible comments. - Pasi On 13 Nov 2014, at 20:15, Zimmermann, Alexander = wrote: > in the Cubic Section: high start =97> HyStart >=20 >> Am 13.11.2014 um 18:25 schrieb Pasi Sarolahti = : >>=20 >> Hi, >>=20 >> Draft TCPM meeting minutes from Monday are available at = http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm . Please send = any corrections to tcpm-chairs. >>=20 >> Many thanks to Mirja and Richard for taking notes! >>=20 >> - Pasi >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Sun Nov 16 12:16: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 83DC01A1AD9 for ; Sun, 16 Nov 2014 12:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 7zZ3dXr9eury for ; Sun, 16 Nov 2014 12:15:38 -0800 (PST) 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 94BFF1A1ADF for ; Sun, 16 Nov 2014 12:15:38 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 16 Nov 2014 20:15:36 +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; Sun, 16 Nov 2014 20:15:35 +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; Sun, 16 Nov 2014 20:15:34 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.16.8]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id sAGKFVcm023350; Sun, 16 Nov 2014 20:15:32 GMT Message-ID: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Nov 2014 19:24:20 +0000 To: Ted Hardie 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/lARdYxUg2YwZn1eeVPeGCO9mZPg Cc: tcpm IETF list Subject: [tcpm] Inner Space and MTU 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, 16 Nov 2014 20:15:41 -0000 Ted, Thx for the point you raised about when I presented Inner Space in tcpinc. As Martin Stiemerling requested, some issues were not specific to tcpinc, so I am moving them to tcpm. When resolved, I will send a digest to tcpinc. Regarding the MTU issue you raised, I don't think it requires a redesign, but it is a valid concern. Therefore, I propose to add the following to the section "Interaction with the Pre-Existing TCP API" "Some applications interrogate the TCP stack to determine the path max transmission unit (PMTU), e.g. in order to optimize application message boundaries within the datastream. From the viewpoint of such applications, TCP options subtract the same amount from the PMTU whether they are Outer or Inner Options. However, the 8 (or 12) octet InSpace header and the alignment padding represent extra overhead. Therefore, for such applications, the TCP stack as seem through the socket API will seem similar to a tunnel that reduces the useful size of the PMTU. This could lead to fragmentation until such applications are updated. Nonetheless, most such applications already include code to adapt to PMTU reduction by tunnels." Is this an acceptable resolution? Bob ________________________________________________________________ Bob Briscoe, BT From nobody Sun Nov 16 20:31: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 90D2E1A00BB for ; Sun, 16 Nov 2014 20:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 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.594, 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 rZ5MnT_q7yIJ for ; Sun, 16 Nov 2014 20:31:39 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379431A00BE for ; Sun, 16 Nov 2014 20:31:39 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so1640018ieb.23 for ; Sun, 16 Nov 2014 20:31:38 -0800 (PST) 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=FlSjdCFHkwnscrtTIp7HsBWHZBSQdeR8OKpwf1COCsc=; b=FmODYNrETyMuGMu5wrHX8HqBgBKPxEnsZA02CO9Q0l60nhacN6TN5+fbinB3RLYIXw TF9IBDvRJPVyfY0nIbVr26r+2rJvOr9jzs3B8dYldblpcoMMcK0r4TFpl946xG7+gZ3j nM0c5STo7Xob0RfBqadSbRSlR5xKHksZzoZMymIZReePUV5Whi8kZzH/Gb5QkAFvnFZF YG093YLKj49vqAlD9DM4FCUjF1PAZe+95hJ7lA0/w89Lxd0G8cCvJ3GMNl4xkVXlxbOU BECwT5QKPsgea107igsYYthuPQHuDDDnDxYhPu9l9pSinhwhIyqXcIWrjeg92pFYb5e/ Pe7Q== 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=FlSjdCFHkwnscrtTIp7HsBWHZBSQdeR8OKpwf1COCsc=; b=BFaWilukoO9tnCoWCIGLd4w8hurqHyr98zHCkDE9Bz6XIEPXpmDWeig0I5rFbimDge aalnf7wbizN4TsmoVQYmATUN2FDuxstXY1wVL9XkHDtPSsPxaGm+mVbtqz0dNkBLhGGU r8ZdP653Y2sKG+qGzLCCRL4fTi4vJXkiuewtjBSLCkAaBOPvsUEhs8EdwVQoHXm5aZEQ Dh8//X6PQ4ohAx09OKf//RyaNpMkv1Ve6EEPSa3d9PLEbNttTU5HIS8aB+jvH3tXA26I YmvwJizH8q4Sn8AcGm3X9ajgOi7K/T6bCUOE2ausN9CGWErtC7jayDEkEEOYRPzV+Yge RKUw== X-Gm-Message-State: ALoCoQn83C7lJd5sRkuLRD0S3d76UsLmye6HIDjR5fJ6x8r/epIaE2lS4uB34P286rpBvnC8UlqQ X-Received: by 10.107.10.16 with SMTP id u16mr3951408ioi.46.1416198698314; Sun, 16 Nov 2014 20:31:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.24.45 with HTTP; Sun, 16 Nov 2014 20:30:58 -0800 (PST) In-Reply-To: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> From: Yuchung Cheng Date: Mon, 17 Nov 2014 12:30:58 +0800 Message-ID: To: Bob Briscoe Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/01hiZ79wB0OFG29GcxxCq7JAhZk Cc: Ted Hardie , tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 17 Nov 2014 04:31:41 -0000 On Mon, Nov 17, 2014 at 3:24 AM, Bob Briscoe wrote: > Ted, > > Thx for the point you raised about when I presented Inner Space in tcpinc. > As Martin Stiemerling requested, some issues were not specific to tcpinc, so > I am moving them to tcpm. When resolved, I will send a digest to tcpinc. > > Regarding the MTU issue you raised, I don't think it requires a redesign, > but it is a valid concern. Therefore, I propose to add the following to the > section "Interaction with the Pre-Existing TCP API" > > "Some applications interrogate the TCP stack to determine the path max > transmission unit (PMTU), e.g. in order to optimize application message > boundaries within the datastream. From the viewpoint of such applications, > TCP options subtract the same amount from the PMTU whether they are Outer or > Inner Options. However, the 8 (or 12) octet InSpace header and the alignment > padding represent extra overhead. Therefore, for such applications, the TCP > stack as seem through the socket API will seem similar to a tunnel that > reduces the useful size of the PMTU. This could lead to fragmentation until > such applications are updated. Nonetheless, most such applications already > include code to adapt to PMTU reduction by tunnels. Reasonable but I'd remove the last sentence. IMO it's app's own risk doing these kind of optimizations. The particular fragmentation issue has motivated the Linux auto-corking feature: http://lwn.net/Articles/576263/ However an interesting question is for implementation that exports the MSS to the application (e.g., Linux TCP info tcpi*mss fields): should it include or exclude the inner-space option? > > Is this an acceptable resolution? > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Nov 16 22:12: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 6D6691A0108 for ; Sun, 16 Nov 2014 22:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 JF8tqSOJUp1h for ; Sun, 16 Nov 2014 22:11:57 -0800 (PST) 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 91F291A011E for ; Sun, 16 Nov 2014 22:11:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,401,1413270000"; d="scan'208,217";a="210847285" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx12-out.netapp.com with ESMTP; 16 Nov 2014 22:11:57 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sun, 16 Nov 2014 22:11:56 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Sun, 16 Nov 2014 22:11:56 -0800 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [tcpm] another basic option question - can TCP enable options on the SYN/ACK? Thread-Index: AQHP7avSTZtF6N5UCEqlSNQozv5Z/pw+YlwAgAAkDQCAJbCZgA== Date: Mon, 17 Nov 2014 06:11:56 +0000 Message-ID: <02254C94-D7BA-4D51-9164-CF4779493A1B@netapp.com> References: <544709B5.3030605@isi.edu> <54493668.8090301@isi.edu> <20141023191902.GD525@verdi> In-Reply-To: <20141023191902.GD525@verdi> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_02254C94D7BA4D519164CF4779493A1Bnetappcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QYOT3kShqyoPk5a50ErpIl_3foI 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: Mon, 17 Nov 2014 06:12:01 -0000 --_000_02254C94D7BA4D519164CF4779493A1Bnetappcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KV2l0aG91dCBhbnkgY2xhaW0gb2YgY29tcGxldG5lc3Mgb3IgcmVjZW50bmVz czoNCg0KbGl1bnggKGF0IGxlYXN0IHVzZWQgdG8pIHN0YXJ0IHRhbGtpbmcgLyByZWZsZWN0aW5n IHRpbWVzdGFtcHMgd2hlbiB0aGV5IHN0YXJ0IGFwcGVhcmluZyBpbiBtaWQtc2Vzc2lvbi4gU2lt dWx0YW5lb3VzbHksIGEgY29ubmVjdGlvbiB3aWxsIG5vdCBmYWlsIHdoZW4gdGltZXN0YW1wcyBz dWRkZW5seSBkaXNhcHBlYXIgKHdoaWNoIGlzLCBhdCBsZWFzdCBpbiA3MzIzLCBpbiB2aW9sYXRp b24gb2YgUEFXUy4gQnV0IGkgZGlkIHNvbWUgbW9yZSBleHRlbnNpdmUgdGVzdHMsIHdoaWNoIGFs c28gcG9pbnRlZCBpbiB0aGUgZGlyZWN0aW9uIHRoYXQgcGF3cyBpcyBhY3R1YWxseSBub3QgYWN0 aXZlIGluIGxpbnV4LCBhbmQgdGhlIHBlci1zZWdtZW50IHJ0dCBzYW1wbGluZyBpcyBkb25lIHVz aW5nIHBlci1zZWdtZW50IHN0YXRlIGluIHRoZSBzZXJ2ZXIuIFNvIGluIGNvbmNsdXNpb24sIHRp bWVzdGFtcHMgYXBwZWFyIHRvIHNlcnZlIG5vIHB1cnBvc2Ugb24gbGludXguLi4NCg0KU29ycnkg dHJpZWQgdG8gcHJ1bmUgdGhlIG9yaWdpbmFsDQpNYWlsIHRvIHRoZSBwYXJ0IGkgcmVzcG9uZCB0 bywgYnV0IHRoaXMgY2xpZW50IGN1dCB0aGF0IHBhcnQgb3V0IGluc3RlYWQgKGlwaG9uZSkNCg0K QmVzdCByZWdhcmRzLA0KICAgUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCkFtIDI0LjEwLjIwMTQg dW0gMDQ6MTggc2NocmllYiAiSm9obiBMZXNsaWUiIDxqb2huQGpsYy5uZXQ8bWFpbHRvOmpvaG5A amxjLm5ldD4+Og0KDQpKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU8bWFpbHRvOnRvdWNoQGlzaS5l ZHU+PiB3cm90ZToNCk9uIDEwLzIxLzIwMTQgODo1NCBQTSwgWW9zaGlmdW1pIE5pc2hpZGEgd3Jv dGU6DQoNCkknbSB3b25kZXJpbmcgaWYgYWxsIG5lZ290aWF0aW9ucyBuZWVkIHRvIGJlIG5lZ290 aWF0ZWQuDQoNClRoZSBvbmVzIHNwZWNpZmllZCBpbiBSRkM3OTMgZG8gbm90Lg0KDQogIChPZiBj b3Vyc2UhKQ0KDQpBbGwgb3RoZXJzIG5lZWQgdG8gYmUgbmVnb3RpYXRlZCAqaWYqIHlvdSBjYXJl IHRoYXQgdGhlIG90aGVyIGVuZA0Kc3VwcG9ydHMgaXQuDQoNCiAgUXVpdGUgdHJ1ZS4gQnV0IG5v dGUgdGhhdCBpdCdzIGVhc3kgdG8gaW1hZ2luZSBvcHRpb25zIHdoZXJlIG9uZQ0KZW5kcG9pbnQg X2RvZXNuJ3RfIGNhcmUgaWYgdGhlIG90aGVyIGVuZHBvaW50IHN1cHBvcnRzIGl0Lg0KDQogIElu IGZhY3QsIEkgZXhwZWN0IHRvIHNob3J0bHkgc3VibWl0IGEgZHJhZnQgd2hlcmUgdGhpcyBpcyB0 aGUgY2FzZS4NCkFuIGVuZHBvaW50IHNlbmRpbmcgaXQgYW5ub3VuY2VzIGl0cyBvd24gc3VwcG9y dCBmb3IgaXQ7IGJ1dCB1bmxlc3MNCnRoZSBvdGhlciBlbmRwb2ludCBhbHNvIHNlbmRzIGl0LCB0 aGUgZmlyc3QgZW5kcG9pbnQgd29uJ3Qga25vdyB3aGV0aGVyDQppdCBoYXMgYmVlbiBhY3RlZCBv biBpbiBhbnkgd2F5Lg0KDQpUaGF0IG5lZ290aWF0aW9uIGNhbiBoYXBwZW4gYXQgYW55IHBvaW50 IGluIHRoZSBjb25uZWN0aW9uLA0KDQogIEN1cnJlbnRseSwgbW9zdCBvcHRpb25zIF9hcmVfIG5v dGVkIGluIHRoZSBvcmlnaW5hdGluZyBTWU4sIGZvcg0Kc2V2ZXJhbCBkaWZmZXJlbnQgcmVhc29u cy4gRmlyc3QsIHRoZSBTWU4gYW5kIFNZTi1BQ0sgYXJlIHRoZSBvbmx5DQpwbGFjZSBpbiBhIFRD UCBjb25uZWN0aW9uIHRoYXQgeW91IGtub3cgdGhlIG9wdGlvbnMgd29uJ3QgYmUgcXVpZXRseQ0K ZHJvcHBlZCBkdWUgdG8gY29uZ2VzdGlvbi4gSSBhbSBub3QgYXdhcmUNCm9mIG11Y2ggZXZpZGVu Y2UgZWl0aGVyIHdheSBvbiB0aGF0LikNCg0KYnV0IGlmIGl0IGRvZXNuJ3QgaGFwcGVuIGR1cmlu ZyB0aGUgb3BlbmluZyBoYW5kc2hha2UgdGhlbiB0aGUgb3B0aW9uDQpuZWVkcyB0byBiZSBzcGVj aWZpZWQgd2l0aCBpdHMgb3duIDNXSFMgbWVjaGFuaXNtIHRoYXQgY2FuIG9wZXJhdGUNCmluZGVw ZW5kZW50bHkgb2Ygc2VnbWVudCBsb3NzIGFuZCByZXRyYW5zbWlzc2lvbiAod2hpY2gsIElNTywg aXMgYSBiYWQNCmlkZWEpLg0KDQogIEkgZG9uJ3QgYWdyZWUgaXQncyBhICJiYWQiIGlkZWEsIGJ1 dCBpdCBzdXJlbHkgaXMgbW9yZSBjb21wbGljYXRlZC4NCg0KICBQbGVhc2Ugbm90ZSwgaG93ZXZl ciwgdGhhdCBhIDMtd2F5IEhhbmRTaGFrZSBpc24ndCB0aGUgb25seSB3YXkgdG8NCnN5bmNocm9u aXplIHNlbmRlcidzIGFuZCByZWNlaXZlcidzIHZpZXdzIG9mIGFuIG9wdGlvbiBiZWluZyBlbmFi bGVkLg0KKEl0IGlzIHVzdWFsbHkgdGhlIGJlc3QsIGJ1dCBub3QgdGhlIG9ubHkuLi4pDQoNClNv bWUgYXJlIGNvbmZpcm1lZCBpbiBib3RoIGRpcmVjdGlvbnMgKHN1Y2ggYXMgVFMgYW5kIFdTKSwg YnV0IG90aGVycw0KbWF5IG5lZWQgdG8gaGF2ZSBhICJyZXNwb25zZSIgdG8gYSBzcGVjaWZpYyAi cmVxdWVzdCIuDQoNCiAgVGhhdCBpbmRlZWQgaXMgY29tbW9uOyBhbmQgaXQgYmVjb21lcyBjb21w bGljYXRlZCBiZWNhdXNlIGVpdGhlciB0aGUNCnJlcXVlc3Qgb3IgdGhlIHJlc3BvbnNlIGNhbiBn ZXQgZHJvcHBlZC4NCg0KRmluYWxseSwgdGhlcmUgYXJlIG9wdGlvbnMgdGhhdCBhcmVuJ3QgYXMg bXVjaCBuZWdvdGlhdGVkIGFzIHRoZXkgYXJlDQplaXRoZXIgc3VwcG9ydGVkIG9yIG5vdCwgZS5n LiwgTUQ1IGFuZCBBTy4gVGhlcmUncyBubyBoYW5kc2hha2UuIElmIHRoZQ0Kb3B0aW9uIGlzIHJl cXVpcmVkIG9uIHRoYXQgY29ubmVjdGlvbiBhbmQgaXNuJ3QgcHJlc2VudCwgc2VnbWVudHMgYXJl DQppZ25vcmVkIGFueXdheS4NCg0KICBUcnVlLiBBbmQsIElNSE8sIHRoaXMgaXMgYSByYXRoZXIg aW1wb3J0YW50IGNhc2UuDQoNCkkuZS4sIGEgdGF4b25vbXkgc2hvdWxkIGluY2x1ZGUsIGF0IGEg bWluaW11bToNCg0KICAgLSBhbHdheXMgc3VwcG9ydGVkDQogICAgICAgZW5kLW9mLWxpc3QNCiAg ICAgICBOT1ANCiAgICAgICBNU1MNCg0KICAgLSBzdXBwb3J0ZWQgaWYgZW5hYmxlZCBpbiBib3Ro IGRpcmVjdGlvbnMgZHVyaW5nIHRoZSAzV0hTDQogICAgICAgVFMsIFdTDQoNCiAgIC0gcmVxdWVz dC9yZXNwb25zZQ0KICAgICAgIFRGTywgTVBUQ1AsIFNBQ0sNCg0KICAgLSBzdXBwb3J0ZWQgaWYg ZW5hYmxlZCB0aHJvdWdob3V0IHRoZSBjb25uZWN0aW9uDQogICAgICAgTUQ1LCBBTw0KDQogIEkn bSBoZXNpdGFudCB0byBtYWtlIHN0YXRlbWVudHMgbGlrZSB0aGlzOiBFYWNoIG9wdGlvbiBzaG91 bGQgYmUNCmRlZmluZWQgdG8gZGV0YWlsIGl0cyBydWxlczsgYW5kIHdlIGNhbiBuZXZlciBob3Bl IHRvIGNvdmVyIHRoZSBlbnRpcmUNCnJhbmdlIG9mIHBvc3NpYmxlIHJ1bGVzLg0KDQogIE5vbmV0 aGVsZXNzLCBKb2UgaXMgY29ycmVjdCwgc28gZmFyIGFzIHRoaXMgZ29lcy4NCg0KLS0NCkpvaG4g TGVzbGllIDxqb2huQGpsYy5uZXQ8bWFpbHRvOmpvaG5AamxjLm5ldD4+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0K dGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGNwbQ0K --_000_02254C94D7BA4D519164CF4779493A1Bnetappcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5IaSBKb2huLDwvZGl2 Pg0KPGRpdiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5XaXRob3V0 IGFueSBjbGFpbSBvZiBjb21wbGV0bmVzcyBvciByZWNlbnRuZXNzOjwvZGl2Pg0KPGRpdiBzdHls ZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5saXVueCAoYXQgbGVhc3QgdXNl ZCB0bykgc3RhcnQgdGFsa2luZyAvIHJlZmxlY3RpbmcgdGltZXN0YW1wcyB3aGVuIHRoZXkgc3Rh cnQgYXBwZWFyaW5nIGluIG1pZC1zZXNzaW9uLiBTaW11bHRhbmVvdXNseSwgYSBjb25uZWN0aW9u IHdpbGwgbm90IGZhaWwgd2hlbiB0aW1lc3RhbXBzIHN1ZGRlbmx5IGRpc2FwcGVhciAod2hpY2gg aXMsIGF0IGxlYXN0IGluIDczMjMsDQogaW4gdmlvbGF0aW9uIG9mIFBBV1MuIEJ1dCBpIGRpZCBz b21lIG1vcmUgZXh0ZW5zaXZlIHRlc3RzLCB3aGljaCBhbHNvIHBvaW50ZWQgaW4gdGhlIGRpcmVj dGlvbiB0aGF0IHBhd3MgaXMgYWN0dWFsbHkgbm90IGFjdGl2ZSBpbiBsaW51eCwgYW5kIHRoZSBw ZXItc2VnbWVudCBydHQgc2FtcGxpbmcgaXMgZG9uZSB1c2luZyBwZXItc2VnbWVudCBzdGF0ZSBp biB0aGUgc2VydmVyLiBTbyBpbiBjb25jbHVzaW9uLCB0aW1lc3RhbXBzIGFwcGVhciB0bw0KIHNl cnZlIG5vIHB1cnBvc2Ugb24gbGludXguLi4mbmJzcDs8YnI+DQo8YnI+DQpTb3JyeSB0cmllZCB0 byBwcnVuZSB0aGUgb3JpZ2luYWw8L2Rpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsiPk1haWwgdG8gdGhlIHBhcnQgaSByZXNwb25kIHRvLCBidXQgdGhpcyBj bGllbnQgY3V0IHRoYXQgcGFydCBvdXQgaW5zdGVhZCAoaXBob25lKTxicj4NCjxicj4NCkJlc3Qg cmVnYXJkcywNCjxkaXY+Jm5ic3A7ICZuYnNwO1JpY2hhcmQgU2NoZWZmZW5lZ2dlcjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48YnI+ DQpBbSAyNC4xMC4yMDE0IHVtIDA0OjE4IHNjaHJpZWIgJnF1b3Q7Sm9obiBMZXNsaWUmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpqb2huQGpsYy5uZXQiPmpvaG5AamxjLm5ldDwvYT4mZ3Q7Ojxi cj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuIHN0 eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5Kb2UgVG91Y2ggJmx0OzxhIGhy ZWY9Im1haWx0bzp0b3VjaEBpc2kuZWR1Ij50b3VjaEBpc2kuZWR1PC9hPiZndDsgd3JvdGU6PC9z cGFuPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSItd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87Ij48c3Bhbj5PbiAxMC8yMS8yMDE0IDg6NTQgUE0sIFlvc2hpZnVtaSBO aXNoaWRhIHdyb3RlOjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSdtIHdvbmRl cmluZyBpZiBhbGwgbmVnb3RpYXRpb25zIG5lZWQgdG8gYmUgbmVnb3RpYXRlZC4NCjwvc3Bhbj48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PHNwYW4+PC9zcGFuPjxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSItd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48c3Bhbj5UaGUgb25lcyBzcGVjaWZpZWQgaW4gUkZD NzkzIGRvIG5vdC48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4gc3R5bGU9Ii13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iLXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+Jm5ic3A7Jm5ic3A7KE9mIGNvdXJzZSEpPC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48 L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9Ii13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzsiPjxzcGFuPkFsbCBvdGhlcnMgbmVlZCB0byBiZSBuZWdvdGlhdGVk ICppZiogeW91IGNhcmUgdGhhdCB0aGUgb3RoZXIgZW5kPC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87Ij48c3Bhbj5zdXBwb3J0cyBpdC48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjwvc3Bhbj48YnI+ DQo8c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+Jm5ic3A7Jm5i c3A7UXVpdGUgdHJ1ZS4gQnV0IG5vdGUgdGhhdCBpdCdzIGVhc3kgdG8gaW1hZ2luZSBvcHRpb25z IHdoZXJlIG9uZTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyI+ZW5kcG9pbnQgX2RvZXNuJ3RfIGNhcmUgaWYgdGhlIG90aGVyIGVuZHBvaW50 IHN1cHBvcnRzIGl0Ljwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyI+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87Ij4mbmJzcDsmbmJzcDtJbiBmYWN0LCBJIGV4cGVjdCB0byBzaG9ydGx5 IHN1Ym1pdCBhIGRyYWZ0IHdoZXJlIHRoaXMgaXMgdGhlIGNhc2UuPC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5BbiBlbmRwb2ludCBzZW5k aW5nIGl0IGFubm91bmNlcyBpdHMgb3duIHN1cHBvcnQgZm9yIGl0OyBidXQgdW5sZXNzPC9zcGFu Pjxicj4NCjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij50aGUg b3RoZXIgZW5kcG9pbnQgYWxzbyBzZW5kcyBpdCwgdGhlIGZpcnN0IGVuZHBvaW50IHdvbid0IGtu b3cgd2hldGhlcjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyI+aXQgaGFzIGJlZW4gYWN0ZWQgb24gaW4gYW55IHdheS48L3NwYW4+PGJyPg0K PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjwvc3Bhbj48YnI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOyI+PHNwYW4+VGhhdCBuZWdvdGlhdGlvbiBjYW4gaGFwcGVuIGF0IGFueSBwb2ludCBp biB0aGUgY29ubmVjdGlvbiw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4gc3R5bGU9 Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHls ZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+Jm5ic3A7Jm5ic3A7Q3VycmVudGx5 LCBtb3N0IG9wdGlvbnMgX2FyZV8gbm90ZWQgaW4gdGhlIG9yaWdpbmF0aW5nIFNZTiwgZm9yPC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5z ZXZlcmFsIGRpZmZlcmVudCByZWFzb25zLiBGaXJzdCwgdGhlIFNZTiBhbmQgU1lOLUFDSyBhcmUg dGhlIG9ubHk8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsiPnBsYWNlIGluIGEgVENQIGNvbm5lY3Rpb24gdGhhdCB5b3Uga25vdyB0aGUgb3B0 aW9ucyB3b24ndCBiZSBxdWlldGx5PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSItd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij5kcm9wcGVkIGR1ZSB0byBjb25nZXN0aW9uLjxmb250IGNv bG9yPSIjMDAwMDAwIj4mbmJzcDtJIGFtPC9mb250Pjwvc3Bhbj48c3BhbiBzdHlsZT0iLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+Jm5ic3A7bm90IGF3YXJlPC9zcGFuPjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9Ii13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsiPg0KPGRpdj48c3Bhbj5vZiBtdWNoIGV2aWRlbmNlIGVpdGhl ciB3YXkgb24gdGhhdC4pPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5idXQgaWYgaXQgZG9lc24ndCBoYXBwZW4gZHVyaW5nIHRoZSBv cGVuaW5nIGhhbmRzaGFrZSB0aGVuIHRoZSBvcHRpb248L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+bmVlZHMgdG8gYmUgc3BlY2lmaWVkIHdp dGggaXRzIG93biAzV0hTIG1lY2hhbmlzbSB0aGF0IGNhbiBvcGVyYXRlPC9zcGFuPjxicj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmluZGVwZW5kZW50bHkg b2Ygc2VnbWVudCBsb3NzIGFuZCByZXRyYW5zbWlzc2lvbiAod2hpY2gsIElNTywgaXMgYSBiYWQ8 L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ aWRlYSkuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bh bj4mbmJzcDsmbmJzcDtJIGRvbid0IGFncmVlIGl0J3MgYSAmcXVvdDtiYWQmcXVvdDsgaWRlYSwg YnV0IGl0IHN1cmVseSBpcyBtb3JlIGNvbXBsaWNhdGVkLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3Nw YW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5ic3A7UGxlYXNlIG5vdGUsIGhvd2V2ZXIsIHRoYXQgYSAz LXdheSBIYW5kU2hha2UgaXNuJ3QgdGhlIG9ubHkgd2F5IHRvPC9zcGFuPjxicj4NCjxzcGFuPnN5 bmNocm9uaXplIHNlbmRlcidzIGFuZCByZWNlaXZlcidzIHZpZXdzIG9mIGFuIG9wdGlvbiBiZWlu ZyBlbmFibGVkLjwvc3Bhbj48YnI+DQo8c3Bhbj4oSXQgaXMgdXN1YWxseSB0aGUgYmVzdCwgYnV0 IG5vdCB0aGUgb25seS4uLik8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlNvbWUgYXJlIGNvbmZpcm1lZCBpbiBib3RoIGRpcmVjdGlv bnMgKHN1Y2ggYXMgVFMgYW5kIFdTKSwgYnV0IG90aGVyczwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5tYXkgbmVlZCB0byBoYXZlIGEgJnF1 b3Q7cmVzcG9uc2UmcXVvdDsgdG8gYSBzcGVjaWZpYyAmcXVvdDtyZXF1ZXN0JnF1b3Q7Ljwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7Jm5i c3A7VGhhdCBpbmRlZWQgaXMgY29tbW9uOyBhbmQgaXQgYmVjb21lcyBjb21wbGljYXRlZCBiZWNh dXNlIGVpdGhlciB0aGU8L3NwYW4+PGJyPg0KPHNwYW4+cmVxdWVzdCBvciB0aGUgcmVzcG9uc2Ug Y2FuIGdldCBkcm9wcGVkLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+RmluYWxseSwgdGhlcmUgYXJlIG9wdGlvbnMgdGhhdCBhcmVu J3QgYXMgbXVjaCBuZWdvdGlhdGVkIGFzIHRoZXkgYXJlPC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmVpdGhlciBzdXBwb3J0ZWQgb3Igbm90 LCBlLmcuLCBNRDUgYW5kIEFPLiBUaGVyZSdzIG5vIGhhbmRzaGFrZS4gSWYgdGhlPC9zcGFuPjxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPm9wdGlvbiBp cyByZXF1aXJlZCBvbiB0aGF0IGNvbm5lY3Rpb24gYW5kIGlzbid0IHByZXNlbnQsIHNlZ21lbnRz IGFyZTwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj5pZ25vcmVkIGFueXdheS48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4+PC9z cGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwO1RydWUuIEFuZCwgSU1ITywgdGhpcyBpcyBhIHJh dGhlciBpbXBvcnRhbnQgY2FzZS48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkkuZS4sIGEgdGF4b25vbXkgc2hvdWxkIGluY2x1ZGUs IGF0IGEgbWluaW11bTo8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyAmbmJzcDstIGFsd2F5cyBzdXBwb3J0ZWQ8L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZW5kLW9mLWxpc3Q8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Tk9QPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01TUzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7ICZuYnNwOy0gc3VwcG9y dGVkIGlmIGVuYWJsZWQgaW4gYm90aCBkaXJlY3Rpb25zIGR1cmluZyB0aGUgM1dIUzwvc3Bhbj48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtUUywgV1M8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyAmbmJzcDstIHJlcXVlc3QvcmVzcG9u c2U8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VEZPLCBNUFRDUCwgU0FDSzwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7ICZu YnNwOy0gc3VwcG9ydGVkIGlmIGVuYWJsZWQgdGhyb3VnaG91dCB0aGUgY29ubmVjdGlvbjwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNRDUsIEFPPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDtJJ20gaGVzaXRhbnQgdG8gbWFr ZSBzdGF0ZW1lbnRzIGxpa2UgdGhpczogRWFjaCBvcHRpb24gc2hvdWxkIGJlPC9zcGFuPjxicj4N CjxzcGFuPmRlZmluZWQgdG8gZGV0YWlsIGl0cyBydWxlczsgYW5kIHdlIGNhbiBuZXZlciBob3Bl IHRvIGNvdmVyIHRoZSBlbnRpcmU8L3NwYW4+PGJyPg0KPHNwYW4+cmFuZ2Ugb2YgcG9zc2libGUg cnVsZXMuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDtO b25ldGhlbGVzcywgSm9lIGlzIGNvcnJlY3QsIHNvIGZhciBhcyB0aGlzIGdvZXMuPC9zcGFuPjxi cj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4tLTwvc3Bhbj48YnI+DQo8c3Bhbj5Kb2huIExl c2xpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG5AamxjLm5ldCI+am9obkBqbGMubmV0PC9hPiZn dDs8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPnRjcG0gbWFp bGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3Jn Ij50Y3BtQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGNwbTwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_02254C94D7BA4D519164CF4779493A1Bnetappcom_-- From nobody Sun Nov 16 22: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 2FD211A0147 for ; Sun, 16 Nov 2014 22:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 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.594, 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 0tjxBCWDhq1s for ; Sun, 16 Nov 2014 22:48:53 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154681A014A for ; Sun, 16 Nov 2014 22:48:52 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so1788738igb.17 for ; Sun, 16 Nov 2014 22:48:52 -0800 (PST) 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=EfDFsl6SGY+dmc/uK2cd4IfQnpK6tVJf7mekQpxiNnM=; b=ip4Plku4Qw6Ow5sJX3TNuuA6/Uvs6CzVcu7yepKprNZmVP6AZvZelFkoMUdPX7rbds Pncoj3nrnv+8Y4nNZybOPQgJOCQ6E44NCfW/hyuZWC8V+NrVybdMmGVtEKQwMKg2aSvd sMk5+yvc2tOyhqigxiZuuhKC0AfykqXYbT1q+NTZKNMxRsiGHwe6SPhdWFAtjgxE55pI EbYdoQ3r3Lb5X7fuy4Wqh1fvFqIF8cxHPQZlokz2mszrldKgc3bRAgCcMBgRiQ6nfeLg 4tMfT3gDG+z5h/7a4x96+ptlwlbF9V/E3hR7FEdO9m43d5NbKhbZDAt4Qbzji+WDfYED K7lw== 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=EfDFsl6SGY+dmc/uK2cd4IfQnpK6tVJf7mekQpxiNnM=; b=Y9vnIdEJKAaE3Io7y0pTJscwhznZV1vLCBexStuBbyuSL5Sl5KwXcNGKCYeJf6qvWO NWUyl09eloaN6n4/7Z7gEXYJQP62OD14FXoNQ4ggbPkbVwG6uTZXIS6Yge50+wubMYL+ +PwH8+wAbdCUTHf6nsTh7uUWBoX3VZZPMyxo0GFPWxOJ20xrgZyA2eMrzVPEo1B3cClZ 70FblVWPK4JTFj6WQWWO+uJo7YwxWW5jNzaR7DQlzZaFPNqvRlgA2V9F06KayabzbPf8 lbKcORs7gbSjn9IfcUSb4Xs0YSA9+DPYWHw7HfsLkuqnaigVnTOMAu9vWJmE61s6Wuha GjbA== X-Gm-Message-State: ALoCoQnb0XoteXc7qDPVcyekwbcB2lvcZMEURrtsc0Bu2oTP6KgK5MSoKva6ZzNXQfsWGO8znrDU X-Received: by 10.107.155.209 with SMTP id d200mr28077876ioe.12.1416206932039; Sun, 16 Nov 2014 22:48:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.24.45 with HTTP; Sun, 16 Nov 2014 22:48:11 -0800 (PST) In-Reply-To: <02254C94-D7BA-4D51-9164-CF4779493A1B@netapp.com> References: <544709B5.3030605@isi.edu> <54493668.8090301@isi.edu> <20141023191902.GD525@verdi> <02254C94-D7BA-4D51-9164-CF4779493A1B@netapp.com> From: Yuchung Cheng Date: Mon, 17 Nov 2014 14:48:11 +0800 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RsGzZZgPlvQorc2yLrVYf93rm-M 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: Mon, 17 Nov 2014 06:48:57 -0000 On Mon, Nov 17, 2014 at 2:11 PM, Scheffenegger, Richard wrote: > Hi John, > > Without any claim of completness or recentness: > > liunx (at least used to) start talking / reflecting timestamps when they > start appearing in mid-session. Simultaneously, a connection will not fail > when timestamps suddenly disappear (which is, at least in 7323, in violation > of PAWS. But i did some more extensive tests, which also pointed in the > direction that paws is actually not active in linux, and the per-segment rtt > sampling is done using per-segment state in the server. So in conclusion, > timestamps appear to serve no purpose on linux... ?! Linux TCP uses RFC1323 PAWS by default if TS is used. RFC7323 is just published so please don't expect implementation will follow immediately ok? please bring the specific tests you have to linux netdev list or send them to me. Linux also uses TS for RTT measurement if Karn's rule forbids taking RTTs. TS is also critical for Eifel (undo) operations. Both have been used for years. > > Sorry tried to prune the original > Mail to the part i respond to, but this client cut that part out instead > (iphone) > > Best regards, > Richard Scheffenegger > > Am 24.10.2014 um 04:18 schrieb "John Leslie" : > > 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. 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 > > _______________________________________________ > 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 Mon Nov 17 05:46: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 8E3301A0397 for ; Mon, 17 Nov 2014 05:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 IyEVKWugTXyw for ; Mon, 17 Nov 2014 05:46:27 -0800 (PST) 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 0086F1A032D for ; Mon, 17 Nov 2014 05:46:26 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7D4FD5F331FA3; Mon, 17 Nov 2014 13:46:22 +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 sAHDjI7i006965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Nov 2014 14:46:12 +0100 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; Mon, 17 Nov 2014 14:44:50 +0100 From: "Scharf, Michael (Michael)" To: Yuchung Cheng , Bob Briscoe Thread-Topic: [tcpm] Inner Space and MTU Thread-Index: AQHQAdoq56kwZ5l67EqA0wrnODkGcZxkKhkAgACk1OA= Date: Mon, 17 Nov 2014 13:44:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D166A08E6@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> 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/39PCs7LboUyHeANCeTavXa0Tx8M Cc: Ted Hardie , tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 17 Nov 2014 13:46:28 -0000 > However an interesting question is for implementation that exports the > MSS to the application (e.g., Linux TCP info tcpi*mss fields): should > it include or exclude the inner-space option? Doesn't the same question apply to all variables that refer to byte stream = characteristics in bytes? For instance, tcpi_*_ssthresh? (Which is less lik= ely to be used by an app, but one never knows...) Another interesting question is what a stack with cwnd in bytes does? Does = the value include or exclude the inner-space options? What happens if the v= alue is exposed to an app? Possibly, other shim layer protocols on top of TCP run into similar questio= ns. Michael =20 From nobody Mon Nov 17 10:08: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 B61D51A8726 for ; Mon, 17 Nov 2014 10:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 gvmfDpQMW0bc for ; Mon, 17 Nov 2014 10:08:31 -0800 (PST) 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 2A9AA1A871D for ; Mon, 17 Nov 2014 10:08:31 -0800 (PST) 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 sAHI5uLM017844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Nov 2014 10:05:59 -0800 (PST) Message-ID: <546A3904.3040601@isi.edu> Date: Mon, 17 Nov 2014 10:05:56 -0800 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: Yuchung Cheng , Bob Briscoe References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> 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/DY0X_gibGkm1wyYrJWF_suft9Fs Cc: Ted Hardie , tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 17 Nov 2014 18:08:34 -0000 On 11/16/2014 8:30 PM, Yuchung Cheng wrote: > However an interesting question is for implementation that exports the > MSS to the application (e.g., Linux TCP info tcpi*mss fields): should > it include or exclude the inner-space option? First, the MSS value used in the header does NOT include TCP or IP options as per rfc6691 However, note that MSS has meaning at the TCP segment level The user-level shouldn't be involved in this. Sec 4 of that RFC explains why - the space used by options can vary (e.g., SACK), so there is no one appropriate MSS to report to the application. To the user, TCP is a bytestream. Wanting to expose segment boundaries to the user (or even implementing it in Linux) doesn't make it possible. Joe From nobody Tue Nov 18 09:04: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 205211A891F for ; Mon, 17 Nov 2014 11:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 sBPf-sdHh5Dk for ; Mon, 17 Nov 2014 11:06:39 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073551A890A for ; Mon, 17 Nov 2014 11:06:37 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so2014778iec.2 for ; Mon, 17 Nov 2014 11:06:36 -0800 (PST) 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=WQTroCJVxwqI850JLuoGzBdJwVnWustKQNJYwbmxFQI=; b=yqAUnYrsRtOOEPN6iJ/c1pEU3Wpd2eDny5wiIktw0zosd/idHvi057i2wKjfWIL2go snQ928AekqinscwR81l8zr2ORm3qI086Y+4q/G5+nk4gEzG+XqMKwyoxbk4o2mCuT4aS 7vhnMWQug+G4vT8/dnkt66PY/dxluwxs0QlMaG3o6Hr1HQ3h7nXpDbB5KzrkpdJWzKUi 6IaGM0aEgsILBkWgqGkAhyVRrkW+e1kUiJrrGYtlyCO0NuwCZcsWo9HxJo7h6q/ST6Sl hvFeSBwLwQwDg3w7iGukpIeiXJS35XjDeevnv0yVtmC0ziHzL2HEMAsCM1LydrIzZ7A+ 2toQ== MIME-Version: 1.0 X-Received: by 10.50.110.65 with SMTP id hy1mr28299876igb.13.1416251196029; Mon, 17 Nov 2014 11:06:36 -0800 (PST) Received: by 10.43.3.4 with HTTP; Mon, 17 Nov 2014 11:06:35 -0800 (PST) In-Reply-To: References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> Date: Mon, 17 Nov 2014 11:06:35 -0800 Message-ID: From: Ted Hardie To: Yuchung Cheng Content-Type: multipart/alternative; boundary=089e0111d1de73c0fe050812ad83 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/d18j7Dw0SDUUUAVVzIU4fkl33W4 X-Mailman-Approved-At: Tue, 18 Nov 2014 09:04:06 -0800 Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 17 Nov 2014 19:06:42 -0000 --089e0111d1de73c0fe050812ad83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, Some thougths in-line. On Sun, Nov 16, 2014 at 8:30 PM, Yuchung Cheng wrote: > On Mon, Nov 17, 2014 at 3:24 AM, Bob Briscoe wrote: > > Ted, > > > > Thx for the point you raised about when I presented Inner Space in > tcpinc. > > As Martin Stiemerling requested, some issues were not specific to > tcpinc, so > > I am moving them to tcpm. When resolved, I will send a digest to tcpinc= . > > > > Regarding the MTU issue you raised, I don't think it requires a redesig= n, > > but it is a valid concern. Therefore, I propose to add the following to > the > > section "Interaction with the Pre-Existing TCP API" > > > > "Some applications interrogate the TCP stack to determine the path max > > transmission unit (PMTU), e.g. in order to optimize application message > > boundaries within the datastream. From the viewpoint of such > applications, > > TCP options subtract the same amount from the PMTU whether they are > Outer or > > Inner Options. However, the 8 (or 12) octet InSpace header and the > alignment > > padding represent extra overhead. Therefore, for such applications, the > TCP > > stack as seem through the socket API will seem similar to a tunnel that > > reduces the useful size of the PMTU. This could lead to fragmentation > until > > such applications are updated. =E2=80=8B So, the best thing to do from my perspective would be to split IP_MTU into TCP_MTU and UDP_MTU in getsockopt(); if inner headers would be in use for TCP, then the MTU returned by the new call would be lower than that returned for UDP_MTU. If not, they would be the same. (You'd need to figure out what to do if IP_MTU were used, but an obvious choice here would be to return the lower of the two values if they differ.) In advance of something like that emerging, the conservative thing to do would be for the application to do in an Inner Space-approved world would be to assume it's always in use, and to adjust its message boundaries on that basis. regards, Ted > Nonetheless, most such applications already > > include code to adapt to PMTU reduction by tunnels. > Reasonable but I'd remove the last sentence. > > IMO it's app's own risk doing these kind of optimizations. > The particular fragmentation issue has motivated the Linux auto-corking > feature: > http://lwn.net/Articles/576263/ > > However an interesting question is for implementation that exports the > MSS to the application (e.g., Linux TCP info tcpi*mss fields): should > it include or exclude the inner-space option? > > > > > Is this an acceptable resolution? > > > > > > Bob > > > > > > > > ________________________________________________________________ > > Bob Briscoe, BT > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > --089e0111d1de73c0fe050812ad83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bob,

Some thougths in-line.
<= div class=3D"gmail_extra">
On Sun, Nov 16, 20= 14 at 8:30 PM, Yuchung Cheng <ycheng@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Mon, N= ov 17, 2014 at 3:24 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:
> Ted,
>
> Thx for the point you raised about when I presented Inner Space in tcp= inc.
> As Martin Stiemerling requested, some issues were not specific to tcpi= nc, so
> I am moving them to tcpm. When resolved, I will send a digest to tcpin= c.
>
> Regarding the MTU issue you raised, I don't think it requires a re= design,
> but it is a valid concern. Therefore, I propose to add the following t= o the
> section "Interaction with the Pre-Existing TCP API"
>
> "Some applications interrogate the TCP stack to determine the pat= h max
> transmission unit (PMTU), e.g. in order to optimize application messag= e
> boundaries within the datastream. From the viewpoint of such applicati= ons,
> TCP options subtract the same amount from the PMTU whether they are Ou= ter or
> Inner Options. However, the 8 (or 12) octet InSpace header and the ali= gnment
> padding represent extra overhead. Therefore, for such applications, th= e TCP
> stack as seem through the socket API will seem similar to a tunnel tha= t
> reduces the useful size of the PMTU. This could lead to fragmentation = until
> such applications are updated.
=E2= =80=8B
So, the best thing to do from my perspective woul= d be to split IP_MTU
into TCP_MTU and UDP_MTU in getsockopt(); if inner = headers would be in
use for TCP, then the MTU returned by the new call w= ould be lower than
that returned for UDP_MTU.=C2=A0 If not, they would = be the same.=C2=A0 (You'd need to
figure out what to do if IP_MTU w= ere used, but an obvious choice here
would be to return the lower of th= e two values if they differ.)

In advance of somethin= g like that emerging, the conservative thing to do
would be for the appl= ication to do in an Inner Space-approved world would
be to assume it'= ;s always in use, and to adjust its message boundaries on that
basis.
regards,

Ted

=C2=A0
Nonet= heless, most such applications already
> include code to adapt to PMTU reduction by tunnels.
Reasonable but I'd remove the last sentence.

IMO it's app's own risk doing these kind of optimizations.
The particular fragmentation issue has motivated the Linux auto-corking fea= ture:
http://lwn.ne= t/Articles/576263/

However an interesting question is for implementation that exports the
MSS to the application (e.g., Linux TCP info tcpi*mss fields): should
it include or exclude the inner-space option?

>
> Is this an acceptable resolution?
>
>
> Bob
>
>
>
> ________________________________________________________________
> Bob Briscoe,=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 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

--089e0111d1de73c0fe050812ad83-- From nobody Tue Nov 18 09:06: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 D463F1A1A84 for ; Tue, 18 Nov 2014 09:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 olUTUmFEQYOr for ; Tue, 18 Nov 2014 09:06:48 -0800 (PST) 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 25D681A1A95 for ; Tue, 18 Nov 2014 09:06:09 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D5164989AFA00 for ; Tue, 18 Nov 2014 17:06: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 sAIH64dl016552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Nov 2014 18:06:04 +0100 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; Tue, 18 Nov 2014 18:06:04 +0100 From: "Scharf, Michael (Michael)" To: tcpm IETF list Thread-Topic: [ipr-announce] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-heitzhe-tcpm-vm-rto-00 Thread-Index: AQHQA0eXVE3YREa1U06L+ZC9fHLnaJxmnTCg Date: Tue, 18 Nov 2014 17:06:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D166A1CAD@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_-5ZzESGXlheUo6ZNpCbbUxITeI Subject: [tcpm] FW: [ipr-announce] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-heitzhe-tcpm-vm-rto-00 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, 18 Nov 2014 17:06:51 -0000 FYI -----Original Message----- From: ipr-announce [mailto:ipr-announce-bounces@ietf.org] On Behalf Of IETF= Secretariat Sent: Tuesday, November 18, 2014 4:38 PM To: jheitz@cisco.com; chuan.he@ericsson.com Cc: jari.arkko@piuha.net; ipr-announce@ietf.org Subject: [ipr-announce] IPR Disclosure: Telefonaktiebolaget LM Ericsson (pu= bl)'s Statement about IPR related to draft-heitzhe-tcpm-vm-rto-00 Dear Jakob Heitz, Chuan He: An IPR disclosure that pertains to your Internet-Draft entitled "TCP Retransmission Timer for Virtual Machines" (draft-heitzhe-tcpm-vm-rto) was submitted to the IETF Secretariat on 2014-11-12 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2485/). The title of the IPR disclosure i= s "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to dr= aft- heitzhe-tcpm-vm-rto-00.""); The IETF Secretariat _______________________________________________ ipr-announce mailing list ipr-announce@ietf.org https://www.ietf.org/mailman/listinfo/ipr-announce From nobody Tue Nov 18 11:26: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 02E1B1A6F2C for ; Tue, 18 Nov 2014 11:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 zT_dHzsIEm8J for ; Tue, 18 Nov 2014 11:25:58 -0800 (PST) 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 A6FA71A6F3C for ; Tue, 18 Nov 2014 11:24:49 -0800 (PST) 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 sAIJOLLA028350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2014 11:24:21 -0800 (PST) Message-ID: <546B9CE5.4020203@isi.edu> Date: Tue, 18 Nov 2014 11:24:21 -0800 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: Ted Hardie , Yuchung Cheng References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> 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/9vA1MdCpxAFG37JK5KKPg1mGGXI Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 18 Nov 2014 19:26:01 -0000 On 11/17/2014 11:06 AM, Ted Hardie wrote: > Hi Bob, > > Some thougths in-line. ... > So, the best thing to do from my perspective would be to split IP_MTU > into TCP_MTU and UDP_MTU in getsockopt(); TCP might report an MTU for diagnostics, but it's a byte-oriented protocol so this value shouldn't be part of what's exposed to the userland application per se. It only gives the incorrect impression that socket boundaries are correlated to TCP segment boundaries. Additionally, as I've already noted, TCP MSS doesn't take into account the option space needed by either IP or TCP. TCP is in a position to use that value to limit how much application data is added to those headers AFTER they're formed. At the application API, there's no meaningful TCP MTU. The space that remains in a segment depends on the size of the options used *for that segment*, and those option sizes already vary. Joe From nobody Tue Nov 18 12:00: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 58CA81A8700 for ; Tue, 18 Nov 2014 12:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 c6req4m_eOPd for ; Tue, 18 Nov 2014 11:59:59 -0800 (PST) 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 AE9211A8034 for ; Tue, 18 Nov 2014 11:59:59 -0800 (PST) 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 sAIJwFH1004246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2014 11:58:15 -0800 (PST) Message-ID: <546BA4D7.9020802@isi.edu> Date: Tue, 18 Nov 2014 11:58:15 -0800 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: Ted Hardie References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> <546B9CE5.4020203@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/sYXWXHZOSkq5SmkY9yZbatdYVJI Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 18 Nov 2014 20:00:01 -0000 On 11/18/2014 11:48 AM, Ted Hardie wrote: > Hi Joe, > > On Tue, Nov 18, 2014 at 11:24 AM, Joe Touch > wrote: > > > > On 11/17/2014 11:06 AM, Ted Hardie wrote: > > Hi Bob, > > > > Some thougths in-line. > ... > > So, the best thing to do from my perspective would be to split IP_MTU > > into TCP_MTU and UDP_MTU in getsockopt(); > > TCP might report an MTU for diagnostics, but it's a byte-oriented > protocol so this value shouldn't be part of what's exposed to the > userland application per se. > > > ​At the moment, you can query the IP_MTU, and some TCP-using applications > attempt to use that information to craft messages that fit within the MTU. I can play PowerBall too, but that doesn't mean I'll be right (or that the app will either). IMO, an app that tries to use MTU when interfacing is doing a lot of work that TCP basically ignores in at least two ways: 1) the options, which (as noted) aren't considered and can vary (and the user can't predict - users don't know how the might be aligned, even if they're stable) 2) TCP grabs what it needs to fill the next segment based on what's available in the window. That window need not always indicate a complete MSS; its position depends on what has been ACKd of what has been sent Even with Nagle disabled, there's no way to control that interaction. So a TCP MTU just helps the app operate under a delusion. TCP is most efficient when the app hands over data as soon as it can. Anything else is asking for interference, not potentially helping. > The IP_MTU may well be a foot gun in its common usage, but it does get > used. That makes more sense for raw socket apps and UDP, but makes no sense at all for TCP for the same reason. > If those applications could query the socket to discover what the maximum > effective TCP payload size was, I believe they would use it instead. Sure. I might use it to guess a PowerBall ticket too. That doesn't mean it's actually useful or will ever be. I agree that apps can, will, and already do think they can do better. They're wrong. Let's not play into that delusion. Joe From nobody Tue Nov 18 13:35: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 E2F771A8F42 for ; Tue, 18 Nov 2014 13:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 o4w9cb4tKLME for ; Tue, 18 Nov 2014 13:35:02 -0800 (PST) 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 83AE61A8F40 for ; Tue, 18 Nov 2014 13:35:02 -0800 (PST) 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 sAILYbGQ006139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2014 13:34:37 -0800 (PST) Message-ID: <546BBB6D.1060407@isi.edu> Date: Tue, 18 Nov 2014 13:34:37 -0800 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: Ted Hardie References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> <546B9CE5.4020203@isi.edu> <546BA4D7.9020802@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/f2nzCo4yCvONCnP9jP2a97WC8FI Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 18 Nov 2014 21:35:04 -0000 On 11/18/2014 12:51 PM, Ted Hardie wrote: > TCP is most efficient when the app hands over data as soon as it can. > Anything else is asking for interference, not potentially helping. > > > ​Applications aren't interested in TCP efficiency in isolation; they > ​are interested in it in an application context. Sometimes that > causes them to make choices different from "hand over the data > as soon as you can in whatever chunks you have". When they do, they ought to be using a different transport. It isn't useful for an app to game its interface to TCP. ... > > If those applications could query the socket to discover what the maximum > > effective TCP payload size was, I believe they would use it instead. > > Sure. I might use it to guess a PowerBall ticket too. That doesn't mean > it's actually useful or will ever be. > > I agree that apps can, will, and already do think they can do better. > They're wrong. Let's not play into that delusion. > > ​Do you oppose Bob's language as well? His first sentence, IMO, only serves to support the delusion that apps can optimize by managing their interaction with the TCP stack. However, I'm not too interested in wordsmithing when there are other, (IMO) more fundamental problems with his approach. Joe From nobody Wed Nov 19 03:15: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 B07AB1AD05C for ; Wed, 19 Nov 2014 03:15:17 -0800 (PST) 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 GaPB41bRUbwt for ; Wed, 19 Nov 2014 03:15:15 -0800 (PST) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.227]) by ietfa.amsl.com (Postfix) with ESMTP id AE0591AD00E for ; Wed, 19 Nov 2014 03:15:14 -0800 (PST) Received: from t40700-la020.org.aalto.fi (130.233.145.26) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 546BDD58000DF19E for tcpm@ietf.org; Wed, 19 Nov 2014 13:15:13 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 19 Nov 2014 13:15:13 +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/O4Dhi071A5oukFlZZA-ngxYkcA0 Subject: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-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: Wed, 19 Nov 2014 11:15:17 -0000 Hi, The TCPM meeting last week supported adoption of = draft-zimmermann-tcpm-undeployed-01 (Moving Undeployed TCP Extensions to = Historic and Informational Status). This mail is to check that people = who did not attend the meeting are content with the meeting consensus to = adopt the draft. Therefore, please let us know by the end of this week, = if you are against adoption -- preferably on the mailing list. Thanks! - Pasi From nobody Wed Nov 19 08:11: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 49A721A86E7 for ; Tue, 18 Nov 2014 11:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 ffieqsYMkwfB for ; Tue, 18 Nov 2014 11:48:48 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74BC1A6FB6 for ; Tue, 18 Nov 2014 11:48:47 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so4564925iec.25 for ; Tue, 18 Nov 2014 11:48:47 -0800 (PST) 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=2Lbqiv4oGl74lM091sdtJCFMHnwlUiMRpSv7C83KYHc=; b=CZtq7CTMrSP1DYdHKl/0sMdWmJUZjajPNwLZ2ZyXhmi5d4RFdLo/K6YZqfNUBG4ZDo dn0ZwAg+iV+6e2hWwSxqIFgLPH4HGHcewTIdeYqdDrmQPKH3kEOYnN4gAkbpq7fUj232 eAWocPBjtwegtB120GWeIgCkJ2AmjXDMuNaFO+XRx9EhRTpyodcBYM1lkAP6g2H6vdR5 ynHaTQ6KC5n9oPPCCZQiK8voOKZ5LVaH4xj5W58F1E8z2vc3u+MrOiTqhz2sAKqVlIqH ZvR/HPB3qFiDfuXcvDvCPOCmRkHd9jY+DZhpfxpF/TCqA926Q/OnDq3FoPYx5ut7Ms3b Txfg== MIME-Version: 1.0 X-Received: by 10.107.138.131 with SMTP id c3mr35313448ioj.0.1416340127003; Tue, 18 Nov 2014 11:48:47 -0800 (PST) Received: by 10.43.3.4 with HTTP; Tue, 18 Nov 2014 11:48:46 -0800 (PST) In-Reply-To: <546B9CE5.4020203@isi.edu> References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> <546B9CE5.4020203@isi.edu> Date: Tue, 18 Nov 2014 11:48:46 -0800 Message-ID: From: Ted Hardie To: Joe Touch Content-Type: multipart/alternative; boundary=001a113e986426bcda0508276215 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/edzl6JRTf3hmFqMmIp6d6MSCfAU X-Mailman-Approved-At: Wed, 19 Nov 2014 08:11:50 -0800 Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 18 Nov 2014 19:48:50 -0000 --001a113e986426bcda0508276215 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joe, On Tue, Nov 18, 2014 at 11:24 AM, Joe Touch wrote: > > > On 11/17/2014 11:06 AM, Ted Hardie wrote: > > Hi Bob, > > > > Some thougths in-line. > ... > > So, the best thing to do from my perspective would be to split IP_MTU > > into TCP_MTU and UDP_MTU in getsockopt(); > > TCP might report an MTU for diagnostics, but it's a byte-oriented > protocol so this value shouldn't be part of what's exposed to the > userland application per se. > > =E2=80=8BAt the moment, you can query the IP_MTU, and some TCP-using applic= ations attempt to use that information to craft messages that fit within the MTU. The IP_MTU may well be a foot gun in its common usage, but it does get used. If those applications could query the socket to discover what the maximum effective TCP payload size was, I believe they would use it instead. That might get reported by taking pessimistic estimates of the variable bits plus the results of a path mtu discovery. How it gets reported may be more important than the details of how the stack estimates it, though. Failing that, those applications will try to discern whether inner space headers are in use and will do their own estimates of the impact on available space. Until they have been updated to discern that, the 8 (or 12) octet InSpace header and the alignment padding will blow them up, as Bob's text notes. If the working group wants to just note the issue and move on, then something along his text is likely fine. If it wants to suggest more, I still believe recognizing the reality and providing something better than the current state is worth considering. Just my two cents, Ted > It only gives the incorrect impression that socket boundaries are > correlated to TCP segment boundaries. > > Additionally, as I've already noted, TCP MSS doesn't take into account > the option space needed by either IP or TCP. TCP is in a position to use > that value to limit how much application data is added to those headers > AFTER they're formed. > > At the application API, there's no meaningful TCP MTU. The space that > remains in a segment depends on the size of the options used *for that > segment*, and those option sizes already vary. > > Joe > --001a113e986426bcda0508276215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

=
On Tue, Nov 18, 2014 at 11:24 AM, Joe Touch <touch@= isi.edu> wrote:


On 11/17/2014 11:06 AM, Ted Hardie wrote:
> Hi Bob,
>
> Some thougths in-line.
...
> So, the best thing to do from my perspective would be= to split IP_MTU
> into TCP_MTU and UDP_MTU in getsockopt();

TCP might report an MTU for diagnostics, but it's a byte-oriente= d
protocol so this value shouldn't be part of what's exposed to the userland application per se.


=E2=80=8BAt the moment, you can query t= he IP_MTU, and some TCP-using applications
attempt to us= e that information to craft messages that fit within the MTU.=C2=A0
The= IP_MTU may well be a foot gun in its common usage, but it does get
used= .=C2=A0

If those applications could query the socket to discover wh= at the maximum
effective TCP payload size was, I believe they would use= it instead.=C2=A0 That might
get reported by taking pessimistic estima= tes of the variable bits plus the results
of a path mtu discovery.=C2=A0= How it gets reported may be more important than the details
of how the = stack estimates it, though.

Failing that, those appl= ications will try to discern whether inner space headers
are in use and = will do their own estimates of the impact on available space.=C2=A0 Untilthey have been updated to discern that, the 8 (or 12) octet InSpace heade= r and the
alignment padding will blow them up, as Bob's text notes.= =C2=A0 If the working group wants
to just note the issu= e and move on, then something along his text is likely fine.=C2=A0 If
it= wants to suggest more, I still believe recognizing the reality and providi= ng something
better than the current state is worth considering.

Just my two cents,

Ted


=C2=A0
It only gives the incorrect impression that socket boundaries are
correlated to TCP segment boundaries.

Additionally, as I've already noted, TCP MSS doesn't take into acco= unt
the option space needed by either IP or TCP. TCP is in a position to use that value to limit how much application data is added to those headers
AFTER they're formed.

At the application API, there's no meaningful TCP MTU. The space that remains in a segment depends on the size of the options used *for that
segment*, and those option sizes already vary.

Joe

--001a113e986426bcda0508276215-- From nobody Wed Nov 19 08:12: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 5D6C41A899B for ; Tue, 18 Nov 2014 12:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 ag0P_0ioIu8m for ; Tue, 18 Nov 2014 12:51:26 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B411A8998 for ; Tue, 18 Nov 2014 12:51:26 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so4936694igb.11 for ; Tue, 18 Nov 2014 12:51:25 -0800 (PST) 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=3b2Trv8/+admadI9CpZt69+jerTmLFG/eBOt9wCE0O0=; b=gJf40g02PuRdGIl5CpAhVHno8a4Mcg8n5MiLobYsuOTn66M6jRH+0+y9BRpgK56rpn jk2KKZeaBOABFgxX4yOPCWJgxaj/a0JGREmUX3PD0uE5cqRD5XN9Ll8BUGusNVJWec65 tYnAs3BXGAZED/mo/ehi3U6be0t1MVpnqrx5lVQJm+kPBnhxhGm/zoRlg8qkrQrvDMU0 3XEkdbOIakcSrMOBmJNKSNdSnnPA3Qhex3qCIb82rkD4DbH3shDoYKoYgO7Yjj2ILMj0 BvsUtGXS/4RNhy4Lyn5EHCFcXCwoATWeh7sWw/N5qpR30xbsuZX0NaE4RbmQkj8hRdz1 rG5Q== MIME-Version: 1.0 X-Received: by 10.51.16.37 with SMTP id ft5mr35984867igd.6.1416343885798; Tue, 18 Nov 2014 12:51:25 -0800 (PST) Received: by 10.43.3.4 with HTTP; Tue, 18 Nov 2014 12:51:25 -0800 (PST) In-Reply-To: <546BA4D7.9020802@isi.edu> References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> <546B9CE5.4020203@isi.edu> <546BA4D7.9020802@isi.edu> Date: Tue, 18 Nov 2014 12:51:25 -0800 Message-ID: From: Ted Hardie To: Joe Touch Content-Type: multipart/alternative; boundary=001a11360240316410050828421b Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6Lyna3cA3KNx7nNfb9G6NpW8BXc X-Mailman-Approved-At: Wed, 19 Nov 2014 08:12:16 -0800 Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 18 Nov 2014 20:51:31 -0000 --001a11360240316410050828421b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2014 at 11:58 AM, Joe Touch wrote: > > > On 11/18/2014 11:48 AM, Ted Hardie wrote: > > Hi Joe, > > > > On Tue, Nov 18, 2014 at 11:24 AM, Joe Touch > > wrote: > > > > > > > > On 11/17/2014 11:06 AM, Ted Hardie wrote: > > > Hi Bob, > > > > > > Some thougths in-line. > > ... > > > So, the best thing to do from my perspective would be to split > IP_MTU > > > into TCP_MTU and UDP_MTU in getsockopt(); > > > > TCP might report an MTU for diagnostics, but it's a byte-oriented > > protocol so this value shouldn't be part of what's exposed to the > > userland application per se. > > > > > > =E2=80=8BAt the moment, you can query the IP_MTU, and some TCP-using ap= plications > > attempt to use that information to craft messages that fit within the > MTU. > > I can play PowerBall too, but that doesn't mean I'll be right (or that > the app will either). > > =E2=80=8BHmm. The PowerBall odds are: 1 in 175,223,510 for the Jackpot. I= f those approximate your personal odds of guessing the payload available to TCP correctly given an MTU, you have one heck of a Path MTU and some startling variability. Or possibly you just meant getting your money back, which is approximately 1 in 55. Even that seems pessimistic, since the actual problem only occurs if the application's guess is over-generous, resulting in fragmentation. But let's take it as read. IMO, an app that tries to use MTU when interfacing is doing a lot of > work that TCP basically ignores in at least two ways: > > 1) the options, which (as noted) aren't considered and can > vary (and the user can't predict - users don't know how > the might be aligned, even if they're stable) > > 2) TCP grabs what it needs to fill the next segment > based on what's available in the window. That window > need not always indicate a complete MSS; its position > depends on what has been ACKd of what has been sent > > Even with Nagle disabled, there's no way to control that interaction. So > a TCP MTU just helps the app operate under a delusion. > > TCP is most efficient when the app hands over data as soon as it can. > Anything else is asking for interference, not potentially helping. > > =E2=80=8BApplications aren't interested in TCP efficiency in isolation; the= y =E2=80=8Bare interested in it in an application context. Sometimes that causes them to make choices different from "hand over the data as soon as you can in whatever chunks you have". > > The IP_MTU may well be a foot gun in its common usage, but it does get > > used. > > That makes more sense for raw socket apps and UDP, but makes no sense at > all for TCP for the same reason. > > =E2=80=8BIt does make more sense for UDP, in general, and it sometimes dr= ives applications to recreate TCP's other characteristics on top of UDP.=E2=80= =8B > > If those applications could query the socket to discover what the maxim= um > > effective TCP payload size was, I believe they would use it instead. > > Sure. I might use it to guess a PowerBall ticket too. That doesn't mean > it's actually useful or will ever be. > > I agree that apps can, will, and already do think they can do better. > They're wrong. Let's not play into that delusion. > > =E2=80=8BDo you oppose Bob's language as well? Ted=E2=80=8B > Joe > --001a11360240316410050828421b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 18, 2014 at 11:58 A= M, Joe Touch <touch@isi.edu> wrote:


On 11/18/2014 11:48 AM, Ted Hardie wrote:
> Hi Joe,
>
> On Tue, Nov 18, 2014 at 11:24 AM, Joe Touch <touch@isi.edu
> <mailto:to= uch@isi.edu>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 11/17/2014 11:06 AM, Ted Hardie wrote:
>=C2=A0 =C2=A0 =C2=A0> Hi Bob,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Some thougths in-line.
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0> So, the best thing to do from my perspective w= ould be to split IP_MTU
>=C2=A0 =C2=A0 =C2=A0> into TCP_MTU and UDP_MTU in getsockopt();
>
>=C2=A0 =C2=A0 =C2=A0TCP might report an MTU for diagnostics, but it'= ;s a byte-oriented
>=C2=A0 =C2=A0 =C2=A0protocol so this value shouldn't be part of wha= t's exposed to the
>=C2=A0 =C2=A0 =C2=A0userland application per se.
>
>
> =E2=80=8BAt the moment, you can query the IP_MTU, and some TCP-using a= pplications
> attempt to use that information to craft messages that fit within the = MTU.

I can play PowerBall too, but that doesn't mean I'll be righ= t (or that
the app will either).


=E2=80=8BHmm.=C2=A0 The PowerBall odds = are: 1 in 175,223,510 for the Jackpot.=C2=A0 If
those approximate your = personal odds of guessing the payload available
to TCP correctly given a= n MTU, you have one heck of a Path MTU and
some startling variability.= =C2=A0 Or possibly you just meant getting your money back,
which is app= roximately 1 in 55.=C2=A0 Even that seems pessimistic, since the actual
= problem only occurs if the application's guess is over-generous, result= ing
in fragmentation.=C2=A0 But let's take it as read.

=
IMO, an app that tries to use MTU when interfacing is doing a lot of
work that TCP basically ignores in at least two ways:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) the options, which (as noted) aren't con= sidered and can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vary (and the user can't predict - users do= n't know how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the might be aligned, even if they're stabl= e)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) TCP grabs what it needs to fill the next seg= ment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 based on what's available in the window. Th= at window
=C2=A0 =C2=A0 =C2=A0 =C2=A0 need not always indicate a complete MSS; its po= sition
=C2=A0 =C2=A0 =C2=A0 =C2=A0 depends on what has been ACKd of what has been = sent

Even with Nagle disabled, there's no way to control that interaction. S= o
a TCP MTU just helps the app operate under a delusion.

TCP is most efficient when the app hands over data as soon as it can.
Anything else is asking for interference, not potentially helping.


=E2=80=8BApplic= ations aren't interested in TCP efficiency in isolation; they
=
=E2=80=8Bare interested in it in an application context.=C2=A0 So= metimes that
causes them to make choices different from = "hand over the data
as soon as you can in whatever chunks you have&= quot;.
=C2=A0
> The IP_MTU may well be a foot gun in its common usage, but it does get=
> used.

That makes more sense for raw socket apps and UDP, but makes no sens= e at
all for TCP for the same reason.

=E2=80=8BIt does ma= ke more sense for UDP, in general, and it sometimes drives
applications = to recreate TCP's other characteristics on top of UDP.=E2=80=8B
=C2=A0
> If those applications could query the socket to discover what the maxi= mum
> effective TCP payload size was, I believe they would use it instead.
Sure. I might use it to guess a PowerBall ticket too. That doesn'= ;t mean
it's actually useful or will ever be.

I agree that apps can, will, and already do think they can do better.
They're wrong. Let's not play into that delusion.


=E2=80=8BDo you oppose Bob's language as well?

<= /div>
Ted=E2=80=8B



=C2=A0
Joe

--001a11360240316410050828421b-- From nobody Wed Nov 19 12:23: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 2845B1A6F90 for ; Wed, 19 Nov 2014 12:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 P3oufnFE5_pG for ; Wed, 19 Nov 2014 12:23:38 -0800 (PST) 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 9044F1A700D for ; Wed, 19 Nov 2014 12:23:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,418,1413270000"; d="scan'208";a="211860483" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx12-out.netapp.com with ESMTP; 19 Nov 2014 12:23:09 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 19 Nov 2014 12:23:08 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Wed, 19 Nov 2014 12:23:08 -0800 From: "Scheffenegger, Richard" To: Joe Touch , Ted Hardie Thread-Topic: [tcpm] Inner Space and MTU Thread-Index: AQHQA3dzxci/LXAGkECAr6dYmGNDj5xoYueA Date: Wed, 19 Nov 2014 20:23:08 +0000 Message-ID: <14ef4138578d421d97b00a0a9e75eee6@hioexcmbx05-prd.hq.netapp.com> References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> <546B9CE5.4020203@isi.edu> <546BA4D7.9020802@isi.edu> <546BBB6D.1060407@isi.edu> In-Reply-To: <546BBB6D.1060407@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Zi-40eewzPERddRgQq1EUg5KmWc Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 19 Nov 2014 20:23:40 -0000 SGVsbG8gSm9lLA0KDQo+PiBBcHBsaWNhdGlvbnMgYXJlbid0IGludGVyZXN0ZWQgaW4gVENQIGVm ZmljaWVuY3kgaW4gaXNvbGF0aW9uOyB0aGV5IA0KPj4gYXJlIGludGVyZXN0ZWQgaW4gaXQgaW4g YW4gYXBwbGljYXRpb24gY29udGV4dC4gIFNvbWV0aW1lcyB0aGF0IA0KPj4gY2F1c2VzIHRoZW0g dG8gbWFrZSBjaG9pY2VzIGRpZmZlcmVudCBmcm9tICJoYW5kIG92ZXIgdGhlIGRhdGEgYXMgc29v biANCj4+IGFzIHlvdSBjYW4gaW4gd2hhdGV2ZXIgY2h1bmtzIHlvdSBoYXZlIi4NCj4NCj4gV2hl biB0aGV5IGRvLCB0aGV5IG91Z2h0IHRvIGJlIHVzaW5nIGEgZGlmZmVyZW50IHRyYW5zcG9ydC4g DQoNCkkgdGVuZCB0byBhZ3JlZSBpZiB3ZSdkIGJlIGxpdmluZyBpbiBhIHBlcmZlY3Qgd29ybGQu Li4NCg0KPiBJdCBpc24ndCB1c2VmdWwgZm9yIGFuIGFwcCB0byBnYW1lIGl0cyBpbnRlcmZhY2Ug dG8gVENQLg0KDQphdSBjb250cmFpcmUhIEluIG15IGNvbnRleHQgKHN0b3JhZ2UpIHRoZXJlIGlz IGEgdmVyeSB3ZWxsLWtub3duIHByb3RvY29sIHRoYXQgc3dpdGNoZWQgZnJvbSBVRFAgdG8gVENQ IChhdCBhIHRpbWUgd2hlbiBTQ1RQIHdhc24ndCBhdmFpbGFibGU7IG9uZSBjYW4gYXJndWUsIGl0 IHN0aWxsIGlzbid0IGluIG1vc3QgZW50ZXJwcmlzZXMuLi4pLiBJbiBvcmRlciB0byBhdm9pZCBl eGNlc3NpdmUgaGVhZC1vZi1saW5lIGJsb2NraW5nLCBpdCBkb2VzIG1ha2Ugc2Vuc2UgZm9yIGFu IGFwcCB0byBmZWVkIHRoZSBzZW5kaW5nIHNvY2tldCB0aGUgZGF0YSBpbiBzbWFsbCBjaHVua3Ms IHRvIGFsbG93IG1vcmUgY3JpdGljYWwgZGF0YSB0byBnZXQgcHJvY2Vzc2VkICh0aGF0IGlzLCB0 cmFuc3BvcnRlZCwgZGVhbHQgd2l0aCBvbiB0aGUgc2VydmVyLCBhbmQgcmVzcG9uZGVkIHRvKSBm YXN0ZXIuIEFuZCB0aGF0IHBhcnRpY3VsYXIgcGllY2Ugb2YgYmVoYXZpb3IgaXMgYWN0dWFsbHkg aW1wbGVtZW50ZWQgaW4gb25lIHBhcnRpY3VsYXIgdXNlci1zcGFjZSBORlMgaW1wbGVtZW50YXRp b24sIGZhaXJseSByZWNlbnRseSAoMjAxMS8xMiBJSVJDKS4NCg0KT3IsIHRvIHVzZSBhIChpbi0p ZmFtb3VzIHdvcmQsIHRvIGNpcmN1bXZlbnQgYnVmZmVyYmxvYXQgYSBsaXR0bGUgYml0IGF0IGxl YXN0ICh0Y3Agc2VuZCBidWZmZXIpLg0KDQpBbHNvLCBldmVuIHRob3VnaCBORlMgZG9lcyBub3Qg ZXhwbGljaXRseSBtYWludGFpbiBzZWdtZW50IGJvdW5kYXJpZXMgKG9yIGNhcmVzIGFib3V0IFRD UCBNU1MpLCB0aGUgZnJlcXVlbnQgdXNlIG9mIFBTSCBzZXJ2ZXMgdG8gYWxpZ24gdGhlIFJQQy9O RlMgY2FsbHMgdG8gdGhlIGV4dGVudCB0aGF0IG1hbnkgaW1wbGVtZW50YXRpb25zIGZhc3QtcGF0 aCBORlMgcHJvY2Vzc2luZyBieSBleHBlY3RpbmcgZml4ZWQgKHRjcCBkYXRhKSBvZmZzZXRzLi4u DQoNCklkZWFsbHksIE5GUyAob3IgcmF0aGVyLCBSUEMpIHdvdWxkIGJlIHVzaW5nIFNDVFAsIHRv IGFkZHJlc3MgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBkZW1hbmRzLCBubyBkb3VidC4NCg0KDQpJ biBhbnkgY2FzZSwgSSdtIG5vdCBpbnRlcmVzdGVkIGluIGRpc2N1c3NpbmcgdGhpcyB0byBleHRp bmN0aW9uIDspDQoNClJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KDQo= From nobody Wed Nov 19 12:25: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 57D111A1B82 for ; Wed, 19 Nov 2014 12:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.496 X-Spam-Level: X-Spam-Status: No, score=-7.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 afGfkbeZVfI0 for ; Wed, 19 Nov 2014 12:25:48 -0800 (PST) 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 D41BC1A1B5A for ; Wed, 19 Nov 2014 12:25:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,418,1413270000"; d="scan'208";a="168876503" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx11-out.netapp.com with ESMTP; 19 Nov 2014 12:25:48 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 19 Nov 2014 12:25:47 -0800 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::7d24:377:dc4c:f0b5%21]) with mapi id 15.00.0995.031; Wed, 19 Nov 2014 12:25:48 -0800 From: "Scheffenegger, Richard" To: Pasi Sarolahti , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-01 Thread-Index: AQHQA+owGUIZdB+28ECEJeVb/LLczJxoZY4w Date: Wed, 19 Nov 2014 20:25:47 +0000 Message-ID: <8f25ad8aaa904c41bab6b77f25d7bc4b@hioexcmbx05-prd.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.120.60.34] 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/tJNvhfbxP4azDbP1h55LQddbMFI Subject: Re: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-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: Wed, 19 Nov 2014 20:25:50 -0000 I'm not opposed, but wanted point out that I'm very much in favor of this, = and similar documents that try match the RFC series with deployment. Richard Scheffenegger -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Pasi Sarolahti Sent: Mittwoch, 19. November 2014 12:15 To: tcpm@ietf.org Extensions Subject: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-01 Hi, The TCPM meeting last week supported adoption of draft-zimmermann-tcpm-unde= ployed-01 (Moving Undeployed TCP Extensions to Historic and Informational S= tatus). This mail is to check that people who did not attend the meeting ar= e content with the meeting consensus to adopt the draft. Therefore, please = let us know by the end of this week, if you are against adoption -- prefera= bly on the mailing list. Thanks! - Pasi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Nov 19 12:36: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 0936F1A1B5A for ; Wed, 19 Nov 2014 12:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 5cLEoijYlaP8 for ; Wed, 19 Nov 2014 12:36:34 -0800 (PST) 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 AA2401A6FC6 for ; Wed, 19 Nov 2014 12:36:33 -0800 (PST) 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 sAJKZtbg010718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Nov 2014 12:35:55 -0800 (PST) Message-ID: <546CFF2B.2030008@isi.edu> Date: Wed, 19 Nov 2014 12:35:55 -0800 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: "Scheffenegger, Richard" , Ted Hardie References: <201411162015.sAGKFVcm023350@bagheera.jungle.bt.co.uk> <546B9CE5.4020203@isi.edu> <546BA4D7.9020802@isi.edu> <546BBB6D.1060407@isi.edu> <14ef4138578d421d97b00a0a9e75eee6@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <14ef4138578d421d97b00a0a9e75eee6@hioexcmbx05-prd.hq.netapp.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/8mrR0pPTjsRKzS94PYjeuqkEVus Cc: tcpm IETF list Subject: Re: [tcpm] Inner Space and MTU 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, 19 Nov 2014 20:36:36 -0000 On 11/19/2014 12:23 PM, Scheffenegger, Richard wrote: > Hello Joe, > >>> Applications aren't interested in TCP efficiency in isolation; they >>> are interested in it in an application context. Sometimes that >>> causes them to make choices different from "hand over the data as soon >>> as you can in whatever chunks you have". >> >> When they do, they ought to be using a different transport. > > I tend to agree if we'd be living in a perfect world... > >> It isn't useful for an app to game its interface to TCP. > > au contraire! In my context (storage) there is a very well-known > protocol that switched from UDP to TCP (at a time when SCTP wasn't > available; one can argue, it still isn't in most enterprises...). In > order to avoid excessive head-of-line blocking, it does make sense for > an app to feed the sending socket the data in small chunks, to allow > more critical data to get processed (that is, transported, dealt with on > the server, and responded to) faster. And that particular piece of > behavior is actually implemented in one particular user-space NFS > implementation, fairly recently (2011/12 IIRC). To be clear - a given implementation can be gamed all day long. Once the OS or protocol is updated, though, *all bets are off*, and all of those optimizations can - and will - come back to bite the programmer. > Or, to use a (in-)famous word, to circumvent bufferbloat a little bit > at least (tcp send buffer). Which comes back and bites you once AQM is deployed. > Also, even though NFS does not explicitly maintain segment > boundaries (or cares about TCP MSS), the frequent use of PSH serves to align the > RPC/NFS calls to the extent that many implementations fast-path NFS > processing by expecting fixed (tcp data) offsets... Note that PSH is part of the TCP API. Joe From nobody Thu Nov 20 09:01: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 40F271A1B92 for ; Thu, 20 Nov 2014 09:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 GrTio6Q6Wlby for ; Thu, 20 Nov 2014 09:00:58 -0800 (PST) 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 B1DC01A1B40 for ; Thu, 20 Nov 2014 09:00:45 -0800 (PST) Received: from [192.168.1.9] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id sAKH09xc016774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Nov 2014 09:00:12 -0800 (PST) Message-ID: <546E1E19.3080100@isi.edu> Date: Thu, 20 Nov 2014 09:00:09 -0800 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: Pasi Sarolahti , "tcpm@ietf.org Extensions" 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/wAsmAQqtGDbecISs-CspI41l-RU Subject: Re: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-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: Thu, 20 Nov 2014 17:01:00 -0000 On 11/19/2014 3:15 AM, Pasi Sarolahti wrote: > Hi, > > The TCPM meeting last week supported adoption of > draft-zimmermann-tcpm-undeployed-01 (Moving Undeployed TCP Extensions to > Historic and Informational Status). This mail is to check that people > who did not attend the meeting are content with the meeting consensus to > adopt the draft. ... I'm OK with this document as a WG item, but as a point of order, I am not. The email list is the primary venue for WG decisions. Any events off-list are at best a reason to ask the list, but it is the list that decides - not those who attend a meeting. In particular, the list needs to exhibit a positive "rough consensus" on this decision. If the list is largely silent, then the decision must be "no". Joe PS - sorry if I'm jumping on a note that wasn't intended to side-step process, but it's how these queries are worded that participants end up sensing how the IETF operates. From nobody Thu Nov 20 09:34: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 762A81A1BE1; Thu, 20 Nov 2014 09:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SmgraW1SPpM4; Thu, 20 Nov 2014 09:34:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7E81A1B48; Thu, 20 Nov 2014 09:34:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141120173412.9570.77071.idtracker@ietfa.amsl.com> Date: Thu, 20 Nov 2014 09:34:12 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/A88YXXO8RayLnQP6tIVLNmZJkzI Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Problem Statement and Requirements for a More Accurate ECN Feedback) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:34:14 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Problem Statement and Requirements for a More Accurate ECN Feedback' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like ConEx or DCTCP) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Nov 20 12:25: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 230AB1ACD41 for ; Thu, 20 Nov 2014 12:25:13 -0800 (PST) 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 2PU1QCXdVhNs for ; Thu, 20 Nov 2014 12:25:09 -0800 (PST) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB211ACD5A for ; Thu, 20 Nov 2014 12:24:31 -0800 (PST) Received: from t40700-la020.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 546BDD53003AAAD2; Thu, 20 Nov 2014 22:24:18 +0200 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: <546E1E19.3080100@isi.edu> Date: Thu, 20 Nov 2014 22:24:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <546E1E19.3080100@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_q1tDldVfoh7oTCwzggbqB6ODIY Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-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: Thu, 20 Nov 2014 20:25:13 -0000 On 20 Nov 2014, at 19:00, Joe Touch wrote: > On 11/19/2014 3:15 AM, Pasi Sarolahti wrote: >> Hi, >>=20 >> The TCPM meeting last week supported adoption of >> draft-zimmermann-tcpm-undeployed-01 (Moving Undeployed TCP Extensions = to >> Historic and Informational Status). This mail is to check that people >> who did not attend the meeting are content with the meeting consensus = to >> adopt the draft. ... >=20 > I'm OK with this document as a WG item, but as a point of order, I am = not. >=20 > The email list is the primary venue for WG decisions. Any events > off-list are at best a reason to ask the list, but it is the list that > decides - not those who attend a meeting. >=20 > In particular, the list needs to exhibit a positive "rough consensus" = on > this decision. If the list is largely silent, then the decision must = be > "no=94. Point taken, the wording in my Email was not all that successful, sorry = for that. Of course, all opinions for or against adoption are welcome, = regardless of the meeting events. (But I would note that we discussed = adoption already before the meeting on this list) [As far as I could read, RFC 2418 does not specify clear = primary/secondary decision relationship between meeting and mailing = list, but of course both should be taken into account. Anyways, I think = it=92s better to keep further process education off-list, unless there = is something relevant for this draft.] - Pasi From nobody Thu Nov 27 05:32: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 B5FF21A8904 for ; Thu, 27 Nov 2014 05:32:05 -0800 (PST) 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, 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 R2yZSP1Ry1dZ for ; Thu, 27 Nov 2014 05:32:03 -0800 (PST) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 688B11A88F8 for ; Thu, 27 Nov 2014 05:32:03 -0800 (PST) Received: from t40700-la020.org.aalto.fi (130.233.145.182) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 546BDD5300F91737 for tcpm@ietf.org; Thu, 27 Nov 2014 15:32:02 +0200 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: <17520_1416395763_546C7BF3_17520_271_1_CAFECC36-C907-40C8-BEB9-44B2EECF0F21@iki.fi> Date: Thu, 27 Nov 2014 15:32:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47EEE435-AB4A-4D3F-89F6-169C88F6F19F@iki.fi> References: <17520_1416395763_546C7BF3_17520_271_1_CAFECC36-C907-40C8-BEB9-44B2EECF0F21@iki.fi> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/L4GAAfz9qfYS4CYGzSDCtg5rqXk Subject: Re: [tcpm] WG Adoption of draft-zimmermann-tcpm-undeployed-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: Thu, 27 Nov 2014 13:32:06 -0000 Hi, There have been two Emails in support and none against for TCPM WG = adoption of draft-zimmermann-tcpm-undeployed, in addition to the clear = consensus for adoption in the Honolulu meeting. Therefore, I would like = to ask the authors to submit the next version of the document as = draft-ietf-tcpm-undeployed-00. Thanks! - Pasi On 19 Nov 2014, at 13:15, Pasi Sarolahti wrote: > Hi, >=20 > The TCPM meeting last week supported adoption of = draft-zimmermann-tcpm-undeployed-01 (Moving Undeployed TCP Extensions to = Historic and Informational Status). This mail is to check that people = who did not attend the meeting are content with the meeting consensus to = adopt the draft. Therefore, please let us know by the end of this week, = if you are against adoption -- preferably on the mailing list. >=20 > Thanks! >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Nov 28 09:00: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 AFAED1A020A; Fri, 28 Nov 2014 09:00:12 -0800 (PST) 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 1pt1BdvEt-hW; Fri, 28 Nov 2014 09:00:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5D41A023E; Fri, 28 Nov 2014 09:00:11 -0800 (PST) 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.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141128170011.6615.91730.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 09:00:11 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/QERwCVuDp0YAtDd-RvYU0dXFakM Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-00.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: Fri, 28 Nov 2014 17:00:12 -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 : Moving Undeployed TCP Extensions to Historic and Informational Status -- An addition to RFC 6247 Authors : Alexander Zimmermann Wesley M. Eddy Lars Eggert Filename : draft-ietf-tcpm-undeployed-00.txt Pages : 4 Date : 2014-11-27 Abstract: This document reclassifies several TCP extensions that have either been superceded or never seen widespread use to Historic status. The affected RFCs are RFC 675, RFC 721, RFC 879, RFC 1078, and RFC 6013. Additionally, it reclassifies RFC 813, RFC 814, RFC 816, RFC 817, RFC 872, RFC 896, and RFC 964 to Informational status. Most of those RFCs are today part of RFC 1122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-undeployed-00 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 Fri Nov 28 09:01: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 5C8B51A0149 for ; Fri, 28 Nov 2014 09:01:49 -0800 (PST) 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 uwEzbqZpbO-E for ; Fri, 28 Nov 2014 09:01:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4A41A008D for ; Fri, 28 Nov 2014 09:01:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141128170147.3233.14491.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 09:01:47 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5X59RTXgi-Uo88jzkjJJo-JUwsc Subject: [tcpm] Milestones changed for tcpm WG 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: Fri, 28 Nov 2014 17:01:49 -0000 URL: http://datatracker.ietf.org/wg/tcpm/charter/