From nobody Tue Apr 8 09:06: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 F05911A03E6 for ; Tue, 8 Apr 2014 09:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 fkUVIW-36TDe for ; Tue, 8 Apr 2014 09:06:34 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id B4C801A04A1 for ; Tue, 8 Apr 2014 09:06:31 -0700 (PDT) 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.327.1; Tue, 8 Apr 2014 17:06:29 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 8 Apr 2014 17:06:29 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Tue, 8 Apr 2014 17:06:28 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.231.251]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s38G6PkL019217; Tue, 8 Apr 2014 17:06:26 +0100 Message-ID: <201404081606.s38G6PkL019217@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 8 Apr 2014 17:04:19 +0100 To: Stephen Bensley From: Bob Briscoe In-Reply-To: <6e10127330744b0b996ef6b49a3e0b3b@BN1PR03MB023.namprd03.pro d.outlook.com> References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk> <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk> <201403141136.s2EBZx2I015898@bagheera.jungle.bt.co.uk> <6e10127330744b0b996ef6b49a3e0b3b@BN1PR03MB023.namprd03.prod.outlook.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/4c37bksz_McnhaMfRd-N2ulu56s Cc: Martin Stiemerling , tcpm IETF list Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Apr 2014 16:06:40 -0000 Stephen, Sorry, I let this thread run dry (I shifted focus from email to deliverables!). It's not appropriate to just say DCTCP has worked well so far. It's as if I had identified a flaw in the emergency braking system of a train, and the designer just says "The brakes have been working fine so far, so the alleged problem you've identified can't be that bad". I've identified a flaw that makes DCTCP increasingly more broken the more pure ACK losses there are on the reverse channel. That implies it could well have been 'working' for years without noticing the problem. But in the wrong circumstances, e.g. losing a link that causes a lot of traffic to reroute onto other links, competing with the reverse channel of other flows. Such a loss situation could persist for some time. In this case, the pre-existing other traffic in the other direction would probably not be persistently congested itself, but it would be losing control information, so it would be alternately overshooting and undershooting without even knowing how badly out of control it had become. As I show here: if one or two pure ACK losses might have occurred, a simple sequence of 3 delayed ACKs apparently feeding back no ECE to the sender might have meant 0%, 20% or 40% CE feedback when they left the receiver, and the sender doesn't know which. Detailed responses inline... At 03:27 15/03/2014, Stephen Bensley wrote: >Hi Bob, > >I don't think dropped ACKs are as bad as that. If a drop occurs >during an unbroken string of CE or non-CE packets, the congestion >estimate is unaffected. If a drop occurs during a transition between >CE and non-CE, then yes, the estimate will be less accurate than it >would be without drops. However, there are some mitigations: >- It may be that even with a less accurate congestion estimate, >DCTCP still performs better than RFC 3168. RFC3168 ECN is designed to be robust to any amount of pure ack loss. >- If the estimation gain is small enough relative to the packet loss >rate, the estimate may not be degraded much. Not knowing whether ECE feedback is 0%, 20% or 40% is not a small estimation error. And the example in Appx A is not a contrived example. Once the sender needs to allow for possible pure ACK losses (which it doesn't know), it has insufficient information to guess what the ACK stream means: in the example given, the sender can guess 0% on the balance of probabilities, but it doesn't really know whether 40% is more likely to be correct... ...because the sender cannot know the pure ACK loss rate, because pure ACKs are not delivered reliably. So, it cannot estimate how much pure ACK losses might be altering its estimate of CE probability. This is also because the gaps between DCTCP's delayed ACKs depend on the unpredictable sequence of CE marks itself, which leads to a catch-22. >- It may be that packet losses mostly occur under heavy congestion. >In which case, most drops occur during an unbroken string of CE packets. We're talking about ACK losses on the reverse path, which can be uncorrelated with congestion on the forward path. >I'd need data about the distribution of CE events relative to packet >drops to analyze the impact, and I don't have this data, so the >above is all speculation. No-one is planning to write artificial intelligence algorithms to estimate what the protocol probably intended to mean. We're just re-designing the protocol, so it works, including during reverse congestion. We're not attached to Microsoft's design of DCTCP like its our favourite pet dog. It's just a protocol. If it isn't safe when it's most needed, we just kill it and make another one. >But DCTCP is successfully deployed in large datacenters today, so it >works well in at least some environments. Just because the brakes have always worked on a trian, doesn't mean the emergency braking system will always work when its needed, especially given a design flaw has been pointed out. >For the case where one server uses DCTCP and the other implements >standard RFC 3168 behavior, Lars had a graduate student who analyzed >this situation in detail and proposed some improvements. We will add >a reference to this paper in the next version. Is it anything like our proposal to use differently configured AQM for ECN and non-ECN? >"Won't they conclude that they can use DCTCP as is, given MS is using it?" > >I believe they can use DCTCP as is. I'm not opposed to developing >something better, but DCTCP seems to work well in practice. I'm not saying the sky is falling. I am saying, if it does, we don't have a way to respond. Bob >-----Original Message----- >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: Thursday, March 13, 2014 12:05 PM >To: Stephen Bensley >Cc: Scharf, Michael (Michael); Martin Stiemerling; >gorry@erg.abdn.ac.uk; Richard Scheffenegger; tcpm IETF list >Subject: RE: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > >Stephen, > >At 14:52 13/03/2014, Stephen Bensley wrote: > >Hello Bob and others, > > > >I'm one of the authors of the draft. I'm new to writing IETF drafts, so > >I'll defer to my co-authors on the debate over intended status. > >The current plan is to switch this to Informational in the next version. > > > >I agree that we should document any known limitations with DCTCP. I > >don't have any data on the effect of lost ACKs, but I will mention that > >dropped ACKs degrade the congestion estimate. > >It's worse than that. Even if no ACKS have been dropped, the sender >cannot know that no ACKs have been dropped, because every gap >between delayed ACKS could represent a pure ACK loss. So the >feedback is always highly ambiguous. If losses are extremely rare on >ECN traffic, the ambiguity can be assumed not to exist. But as soon >as there's a few losses, that assumption collapses and you have a >very broken TCP protocol. > > >In the deployment issues section, I will make it clear that there is no > >negotiation. I'll also mention the RTT fairness issue. Anything else > >specifically that you'd like to see covered? > >For me personally, RTT fairness isn't an issue, and if it were for >anyone else, they would have to deprecate TCP itself as well. > >The only other concern I have is what people will do when they read >an RFC that says Microsoft is using DCTCP, altho it has problems, >but then the draft doesn't point to any solutions (because we are >still working on them). Won't they conclude that they can use DCTCP >as is, given MS is using it? > >==The no.1 concern is capability negotiation. == There are very few >codepoints left for negotiation, so if implementations appear that >either burn up the remaining codepoints without agreement, or don't >negotiate at all, the TCP wire protocol will become unusable with >ECN. So the stakes are very high. > >Win8 server already started us down this slippery slope, given it >can use a different wire protocol without negotiation, so we need to >fix this rapidly. > >Superficially it seems safe because: >- the data centre template has to be turned on in Windows, >- it has to have negotiated ECN with the other end >- the RTT has to be below x (5ms from memory). > >But what if one of our customers turns on the DC template in the >Windows servers in one of the DCs we interconnect with the DCs of >other customers? These TCPs will then start talking with other >standard TCP implementations in other DCs, but using the ECN flags >differently without the other end knowing. Chaos ensues. > > >I think Lars has already made this clear, but just to reiterate, our > >primary goals for documenting DCTCP were to provide a mechanism for the > >IPR disclosure and to document Windows behavior for the benefit of > >other stacks that would like to interoperate. There are some sizable > >DCTCP deployments, and thus, there has been some interest from > >non-Microsoft vendors to implement DCTCP. We hope to facilitate this by > >providing quality documentation and a royalty-free license. > >This must have involved quite a bit of work internally for no direct >gain, so thank you for doing this. > > > > >If there is interest in doing further congestion control > >improvements for datacenters, I'm happy to participate, but perhaps > >this draft isn't the best vehicle for that. > >I think you were right to just document what you had done. >Particularly to make the IPR position clear. And if you make the >listed problems extremely clear, and point to solutions, I'll be happy. > >Do you want me to point you at all the relevant background? > >You will see a roadmap of the drafts I think are necessary on slide >11 of a presentation I gave to TSVAREA about this last week >(including your draft): > >To be clear, this roadmap has greater ambitions than just private >data centres. > > >Bob > > > >Thanks for the feedback, > >Stephen Bensley > > > >-----Original Message----- > >From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > >Sent: Tuesday, March 11, 2014 7:26 AM > >To: Scharf, Michael (Michael); Martin Stiemerling; > >gorry@erg.abdn.ac.uk; Richard Scheffenegger > >Cc: tcpm IETF list > >Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > > >Gorry, Michael, Martin, Richard, > > > >I would be happy with INF as long as the outstanding issues were > >clearly identified (feedback broken, no negotiation of alternate > >wire protocol, deployment applicability, etc) > > > >The main reason for suggesting HISTORIC was to avoid people getting > >the impression the protocol as currently implemented is good to go > >on the public Internet. > > > > > >Bob > > > >At 09:28 10/03/2014, Gorry Fairhurst wrote: > > >This seems sensible to me, get WG comments feedback for an individual > > >submission (via AD) and propose as INFO. If there is feedback by the > > >authors they want it to be HISTORIC, that would be OK also. > > > > > >To me, it would need careful crafting of the abstract to explain the > > >current position with respect to other work in this area. > > > > > >Gorry > > > > > >On 09/03/2014 11:02, Scharf, Michael (Michael) wrote: > > >>Hi Bob, > > >> > > >>I think we should encourage that implementers document widely deployed > > >>TCP mechanism in the RFC series, if they are willing to discuss with > > >>the IETF and improve document clarity so that the document is a good, > > >>informational description that can be used as reference. (This thought > > >>is actually independent of DCTCP.) > > >> > > >>If implementers are responsive to questions, such informational > > >>documentation (possible as AD-sponsored document) should actually be > > >>possible rather quickly. This almost likely implies that the RFC > > >>documents a mechanism that is still in use at the time of publication. > > >>To me, this is not "historic". > > >> > > >>I could imagine that a Proposed Standard produced by the IETF changes > > >>the status to "Historic" at a later stage. But even then I'd ask > > >>whether the Proposed Standard indeed describes what is deployed, or > > >>will be deployed, at large scale in the Internet. > > >> > > >>Thanks > > >> > > >>Michael (as individual contributor) > > >> > > >> > > >> > > >>>-----Original Message----- > > >>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > > >>>Sent: Thursday, March 06, 2014 3:52 PM > > >>>To: EGGERT, Lars; Martin Stiemerling > > >>>Cc: tcpm IETF list > > >>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > >>> > > >>>Lars, > > >>> > > >>>Everyone seems to agree this should be independent stream. That > > >>>leaves the question of intended status... > > >>> > > >>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do > > >>>you want to update this draft? I doubt it. > > >>> > > >>>So, IMO if you wanted to only document what Microsoft did, even tho > > >>>it was broken, then this should be HISTORIC, not INFORMATIONAL. > > >>> > > >>>If it's INFORMATIONAL it should at least fix known major problems > > >>>before it is published. > > >>> > > >>> > > >>> > > >>>Bob > > >>> > > >>> > > >>> > > >>>________________________________________________________________ > > >>>Bob Briscoe, BT > > >>> > > >>>_______________________________________________ > > >>>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 > > > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www.ietf.org/mailman/listinfo/tcpm > >________________________________________________________________ >Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From nobody Tue Apr 8 11:14:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81AE1A048D for ; Tue, 8 Apr 2014 11:13:52 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 h_81GXVqA-jj for ; Tue, 8 Apr 2014 11:13:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) by ietfa.amsl.com (Postfix) with ESMTP id 183EE1A0465 for ; Tue, 8 Apr 2014 11:13:45 -0700 (PDT) Received: from BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) by BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) with Microsoft SMTP Server (TLS) id 15.0.913.9; Tue, 8 Apr 2014 18:13:44 +0000 Received: from BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.227]) by BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.227]) with mapi id 15.00.0913.002; Tue, 8 Apr 2014 18:13:44 +0000 From: Stephen Bensley To: Bob Briscoe Thread-Topic: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? Thread-Index: AQHPOUuqAo6vz4uFNkGDCeAsqicfcZrYm3eAgAF4BwCAAeVxAIADJy2AgAFgf+6AAOzBsIAmqRRjgAAdHLA= Date: Tue, 8 Apr 2014 18:13:43 +0000 Message-ID: <0520601fa4a444d6b86d3f723c58332f@BN1PR03MB023.namprd03.prod.outlook.com> References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk> <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk> <201403141136.s2EBZx2I015898@bagheera.jungle.bt.co.uk> <6e10127330744b0b996ef6b49a3e0b3b@BN1PR03MB023.namprd03.prod.outlook.com> <201404081606.s38G6PkL019217@bagheera.jungle.bt.co.uk> In-Reply-To: <201404081606.s38G6PkL019217@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.132.2.190] x-forefront-prvs: 017589626D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(51914003)(243025003)(51704005)(479174003)(377454003)(13464003)(74316001)(49866001)(74706001)(86362001)(81542001)(85306002)(76796001)(93136001)(98676001)(20776003)(76786001)(93516002)(74876001)(46102001)(2656002)(81342001)(80022001)(85852003)(92566001)(47446003)(54356002)(47736002)(54316003)(47976002)(4396001)(77096001)(74366001)(33646001)(65816001)(87936001)(66066001)(81686001)(83072002)(74662001)(56816005)(59766001)(77982001)(81816001)(94316002)(76482001)(97186001)(90146001)(76576001)(56776001)(31966008)(561944002)(15395725003)(87266001)(69226001)(97336001)(63696002)(19580395003)(83322001)(80976001)(74502001)(94946001)(19580405001)(79102001)(95416001)(53806002)(99396002)(95666003)(50986002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB023; H:BN1PR03MB023.namprd03.prod.outlook.com; FPR:E79FF1A5.97FA51BE.BDD3B14B.D2E6A140.20950; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pHDtblcGi3AKRolSVSMr3QWjWCE Cc: Martin Stiemerling , tcpm IETF list Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Apr 2014 18:13:53 -0000 Hi Bob, I agree that there are almost certainly real world scenarios where DCTCP pe= rforms poorly. However, the same is true of the existing congestion control= algorithms. That's what motivated the invention of DCTCP. I also agree with the issues you've identified, and I've documented them in= the next version. I too have been side-tracked by deliverables, but I hope= to have the next version published soon. Furthermore, as I wrote before, I= 'm happy to work with you and others to come up with something better. Please wait for the new version, and see if you're happy with the language. Thanks again for all the feedback. I do think version 01 is much better tha= n the previous version. -----Original Message----- From: Bob Briscoe [mailto:bob.briscoe@bt.com]=20 Sent: Tuesday, April 8, 2014 9:04 AM To: Stephen Bensley Cc: Scharf, Michael (Michael); Martin Stiemerling; gorry@erg.abdn.ac.uk; Ri= chard Scheffenegger; tcpm IETF list Subject: RE: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? Stephen, Sorry, I let this thread run dry (I shifted focus from email to deliverable= s!). It's not appropriate to just say DCTCP has worked well so far. It's as if I= had identified a flaw in the emergency braking system of a train, and the = designer just says "The brakes have been working fine so far, so the allege= d problem you've identified can't be that bad". I've identified a flaw that makes DCTCP increasingly more broken the more p= ure ACK losses there are on the reverse channel. That implies it could well= have been 'working' for years without noticing the problem. But in the wro= ng circumstances, e.g. losing a link that causes a lot of traffic to rerout= e onto other links, competing with the reverse channel of other flows. Such= a loss situation could persist for some time. In this case, the pre-existing other traffic in the other direction would p= robably not be persistently congested itself, but it would be losing contro= l information, so it would be alternately overshooting and undershooting wi= thout even knowing how badly out of control it had become. As I show here: if one or two pure ACK losses might have occurred, a simple sequence of 3 d= elayed ACKs apparently feeding back no ECE to the sender might have meant 0= %, 20% or 40% CE feedback when they left the receiver, and the sender doesn= 't know which. Detailed responses inline... At 03:27 15/03/2014, Stephen Bensley wrote: >Hi Bob, > >I don't think dropped ACKs are as bad as that. If a drop occurs during=20 >an unbroken string of CE or non-CE packets, the congestion estimate is=20 >unaffected. If a drop occurs during a transition between CE and non-CE,=20 >then yes, the estimate will be less accurate than it would be without=20 >drops. However, there are some mitigations: >- It may be that even with a less accurate congestion estimate, DCTCP=20 >still performs better than RFC 3168. RFC3168 ECN is designed to be robust to any amount of pure ack loss. >- If the estimation gain is small enough relative to the packet loss=20 >rate, the estimate may not be degraded much. Not knowing whether ECE feedback is 0%, 20% or 40% is not a small estimatio= n error. And the example in Appx A is not a contrived example. Once the sender needs= to allow for possible pure ACK losses (which it doesn't know), it has insu= fficient information to guess what the ACK stream means:=20 in the example given, the sender can guess 0% on the balance of probabiliti= es, but it doesn't really know whether 40% is more likely to be correct... ...because the sender cannot know the pure ACK loss rate, because pure ACKs= are not delivered reliably. So, it cannot estimate how much pure ACK losse= s might be altering its estimate of CE probability.=20 This is also because the gaps between DCTCP's delayed ACKs depend on the un= predictable sequence of CE marks itself, which leads to a catch-22. >- It may be that packet losses mostly occur under heavy congestion.=20 >In which case, most drops occur during an unbroken string of CE packets. We're talking about ACK losses on the reverse path, which can be uncorrelat= ed with congestion on the forward path. >I'd need data about the distribution of CE events relative to packet=20 >drops to analyze the impact, and I don't have this data, so the=20 >above is all speculation. No-one is planning to write artificial intelligence algorithms to=20 estimate what the protocol probably intended to mean. We're just=20 re-designing the protocol, so it works, including during reverse=20 congestion. We're not attached to Microsoft's design of DCTCP like=20 its our favourite pet dog. It's just a protocol. If it isn't safe=20 when it's most needed, we just kill it and make another one. >But DCTCP is successfully deployed in large datacenters today, so it=20 >works well in at least some environments. Just because the brakes have always worked on a trian, doesn't mean=20 the emergency braking system will always work when its needed,=20 especially given a design flaw has been pointed out. >For the case where one server uses DCTCP and the other implements=20 >standard RFC 3168 behavior, Lars had a graduate student who analyzed=20 >this situation in detail and proposed some improvements. We will add=20 >a reference to this paper in the next version. Is it anything like our proposal to use differently configured AQM=20 for ECN and non-ECN? >"Won't they conclude that they can use DCTCP as is, given MS is using it?" > >I believe they can use DCTCP as is. I'm not opposed to developing=20 >something better, but DCTCP seems to work well in practice. I'm not saying the sky is falling. I am saying, if it does, we don't=20 have a way to respond. Bob >-----Original Message----- >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: Thursday, March 13, 2014 12:05 PM >To: Stephen Bensley >Cc: Scharf, Michael (Michael); Martin Stiemerling;=20 >gorry@erg.abdn.ac.uk; Richard Scheffenegger; tcpm IETF list >Subject: RE: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > >Stephen, > >At 14:52 13/03/2014, Stephen Bensley wrote: > >Hello Bob and others, > > > >I'm one of the authors of the draft. I'm new to writing IETF drafts, so > >I'll defer to my co-authors on the debate over intended status. > >The current plan is to switch this to Informational in the next version. > > > >I agree that we should document any known limitations with DCTCP. I > >don't have any data on the effect of lost ACKs, but I will mention that > >dropped ACKs degrade the congestion estimate. > >It's worse than that. Even if no ACKS have been dropped, the sender=20 >cannot know that no ACKs have been dropped, because every gap=20 >between delayed ACKS could represent a pure ACK loss. So the=20 >feedback is always highly ambiguous. If losses are extremely rare on=20 >ECN traffic, the ambiguity can be assumed not to exist. But as soon=20 >as there's a few losses, that assumption collapses and you have a=20 >very broken TCP protocol. > > >In the deployment issues section, I will make it clear that there is no > >negotiation. I'll also mention the RTT fairness issue. Anything else > >specifically that you'd like to see covered? > >For me personally, RTT fairness isn't an issue, and if it were for=20 >anyone else, they would have to deprecate TCP itself as well. > >The only other concern I have is what people will do when they read=20 >an RFC that says Microsoft is using DCTCP, altho it has problems,=20 >but then the draft doesn't point to any solutions (because we are=20 >still working on them). Won't they conclude that they can use DCTCP=20 >as is, given MS is using it? > >=3D=3DThe no.1 concern is capability negotiation. =3D=3D There are very fe= w=20 >codepoints left for negotiation, so if implementations appear that=20 >either burn up the remaining codepoints without agreement, or don't=20 >negotiate at all, the TCP wire protocol will become unusable with=20 >ECN. So the stakes are very high. > >Win8 server already started us down this slippery slope, given it=20 >can use a different wire protocol without negotiation, so we need to=20 >fix this rapidly. > >Superficially it seems safe because: >- the data centre template has to be turned on in Windows, >- it has to have negotiated ECN with the other end >- the RTT has to be below x (5ms from memory). > >But what if one of our customers turns on the DC template in the=20 >Windows servers in one of the DCs we interconnect with the DCs of=20 >other customers? These TCPs will then start talking with other=20 >standard TCP implementations in other DCs, but using the ECN flags=20 >differently without the other end knowing. Chaos ensues. > > >I think Lars has already made this clear, but just to reiterate, our > >primary goals for documenting DCTCP were to provide a mechanism for the > >IPR disclosure and to document Windows behavior for the benefit of > >other stacks that would like to interoperate. There are some sizable > >DCTCP deployments, and thus, there has been some interest from > >non-Microsoft vendors to implement DCTCP. We hope to facilitate this by > >providing quality documentation and a royalty-free license. > >This must have involved quite a bit of work internally for no direct=20 >gain, so thank you for doing this. > > > > >If there is interest in doing further congestion control > >improvements for datacenters, I'm happy to participate, but perhaps > >this draft isn't the best vehicle for that. > >I think you were right to just document what you had done. >Particularly to make the IPR position clear. And if you make the >listed problems extremely clear, and point to solutions, I'll be happy. > >Do you want me to point you at all the relevant background? > >You will see a roadmap of the drafts I think are necessary on slide >11 of a presentation I gave to TSVAREA about this last week >(including your draft): > >To be clear, this roadmap has greater ambitions than just private=20 >data centres. > > >Bob > > > >Thanks for the feedback, > >Stephen Bensley > > > >-----Original Message----- > >From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > >Sent: Tuesday, March 11, 2014 7:26 AM > >To: Scharf, Michael (Michael); Martin Stiemerling; > >gorry@erg.abdn.ac.uk; Richard Scheffenegger > >Cc: tcpm IETF list > >Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > > >Gorry, Michael, Martin, Richard, > > > >I would be happy with INF as long as the outstanding issues were > >clearly identified (feedback broken, no negotiation of alternate > >wire protocol, deployment applicability, etc) > > > >The main reason for suggesting HISTORIC was to avoid people getting > >the impression the protocol as currently implemented is good to go > >on the public Internet. > > > > > >Bob > > > >At 09:28 10/03/2014, Gorry Fairhurst wrote: > > >This seems sensible to me, get WG comments feedback for an individual > > >submission (via AD) and propose as INFO. If there is feedback by the > > >authors they want it to be HISTORIC, that would be OK also. > > > > > >To me, it would need careful crafting of the abstract to explain the > > >current position with respect to other work in this area. > > > > > >Gorry > > > > > >On 09/03/2014 11:02, Scharf, Michael (Michael) wrote: > > >>Hi Bob, > > >> > > >>I think we should encourage that implementers document widely deploye= d > > >>TCP mechanism in the RFC series, if they are willing to discuss with > > >>the IETF and improve document clarity so that the document is a good, > > >>informational description that can be used as reference. (This though= t > > >>is actually independent of DCTCP.) > > >> > > >>If implementers are responsive to questions, such informational > > >>documentation (possible as AD-sponsored document) should actually be > > >>possible rather quickly. This almost likely implies that the RFC > > >>documents a mechanism that is still in use at the time of publication= . > > >>To me, this is not "historic". > > >> > > >>I could imagine that a Proposed Standard produced by the IETF changes > > >>the status to "Historic" at a later stage. But even then I'd ask > > >>whether the Proposed Standard indeed describes what is deployed, or > > >>will be deployed, at large scale in the Internet. > > >> > > >>Thanks > > >> > > >>Michael (as individual contributor) > > >> > > >> > > >> > > >>>-----Original Message----- > > >>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > > >>>Sent: Thursday, March 06, 2014 3:52 PM > > >>>To: EGGERT, Lars; Martin Stiemerling > > >>>Cc: tcpm IETF list > > >>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > >>> > > >>>Lars, > > >>> > > >>>Everyone seems to agree this should be independent stream. That > > >>>leaves the question of intended status... > > >>> > > >>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then d= o > > >>>you want to update this draft? I doubt it. > > >>> > > >>>So, IMO if you wanted to only document what Microsoft did, even tho > > >>>it was broken, then this should be HISTORIC, not INFORMATIONAL. > > >>> > > >>>If it's INFORMATIONAL it should at least fix known major problems > > >>>before it is published. > > >>> > > >>> > > >>> > > >>>Bob > > >>> > > >>> > > >>> > > >>>________________________________________________________________ > > >>>Bob Briscoe, BT > > >>> > > >>>_______________________________________________ > > >>>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 > > > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www.ietf.org/mailman/listinfo/tcpm > >________________________________________________________________ >Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT=20 From nobody Tue Apr 8 11:49: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 3BE1C1A06A4 for ; Tue, 8 Apr 2014 11:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 UCVXNk6yID8q for ; Tue, 8 Apr 2014 11:49:42 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 79D291A0273 for ; Tue, 8 Apr 2014 11:49:41 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 19:49:40 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 8 Apr 2014 19:49:38 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 8 Apr 2014 19:49:37 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.14.1]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s38InYCo019864; Tue, 8 Apr 2014 19:49:35 +0100 Message-ID: <201404081849.s38InYCo019864@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 8 Apr 2014 19:49:33 +0100 To: Stephen Bensley From: Bob Briscoe In-Reply-To: <0520601fa4a444d6b86d3f723c58332f@BN1PR03MB023.namprd03.pro d.outlook.com> References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk> <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk> <201403141136.s2EBZx2I015898@bagheera.jungle.bt.co.uk> <6e10127330744b0b996ef6b49a3e0b3b@BN1PR03MB023.namprd03.prod.outlook.com> <201404081606.s38G6PkL019217@bagheera.jungle.bt.co.uk> <0520601fa4a444d6b86d3f723c58332f@BN1PR03MB023.namprd03.prod.outlook.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/th6qj-kkeTXlUbTrHJvuOlt5MZE Cc: Martin Stiemerling , tcpm IETF list Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Apr 2014 18:49:50 -0000 Stephen, Thx for your patience. I don't think we should be talking about whether DCTCP as a whole is 'better' or 'worse' than RFC3168. For instance, it performs much better, but you can't use it on the public Internet. Is that better or worse?! For the IETF, I'm essentially advocating that we don't treat DCTCP as one inviolable whole. Instead, we build on the whole idea, dividing it into component parts, and incrementally improve each one, eg: - the feedback protocol (accecn) - the marking algo - co-existence with legacy traffic - and there is always scope for improving the sender algo too. Bob At 19:13 08/04/2014, Stephen Bensley wrote: >Hi Bob, > >I agree that there are almost certainly real world scenarios where >DCTCP performs poorly. However, the same is true of the existing >congestion control algorithms. That's what motivated the invention of DCTCP. > >I also agree with the issues you've identified, and I've documented >them in the next version. I too have been side-tracked by >deliverables, but I hope to have the next version published soon. >Furthermore, as I wrote before, I'm happy to work with you and >others to come up with something better. > >Please wait for the new version, and see if you're happy with the language. > >Thanks again for all the feedback. I do think version 01 is much >better than the previous version. > > >-----Original Message----- >From: Bob Briscoe [mailto:bob.briscoe@bt.com] >Sent: Tuesday, April 8, 2014 9:04 AM >To: Stephen Bensley >Cc: Scharf, Michael (Michael); Martin Stiemerling; >gorry@erg.abdn.ac.uk; Richard Scheffenegger; tcpm IETF list >Subject: RE: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > >Stephen, > >Sorry, I let this thread run dry (I shifted focus from email to >deliverables!). > >It's not appropriate to just say DCTCP has worked well so far. It's >as if I had identified a flaw in the emergency braking system of a >train, and the designer just says "The brakes have been working fine >so far, so the alleged problem you've identified can't be that bad". > >I've identified a flaw that makes DCTCP increasingly more broken the >more pure ACK losses there are on the reverse channel. That implies >it could well have been 'working' for years without noticing the >problem. But in the wrong circumstances, e.g. losing a link that >causes a lot of traffic to reroute onto other links, competing with >the reverse channel of other flows. Such a loss situation could >persist for some time. > >In this case, the pre-existing other traffic in the other direction >would probably not be persistently congested itself, but it would be >losing control information, so it would be alternately overshooting >and undershooting without even knowing how badly out of control it had become. > >As I show here: > >if one or two pure ACK losses might have occurred, a simple sequence >of 3 delayed ACKs apparently feeding back no ECE to the sender might >have meant 0%, 20% or 40% CE feedback when they left the receiver, >and the sender doesn't know which. > >Detailed responses inline... > >At 03:27 15/03/2014, Stephen Bensley wrote: > >Hi Bob, > > > >I don't think dropped ACKs are as bad as that. If a drop occurs during > >an unbroken string of CE or non-CE packets, the congestion estimate is > >unaffected. If a drop occurs during a transition between CE and non-CE, > >then yes, the estimate will be less accurate than it would be without > >drops. However, there are some mitigations: > >- It may be that even with a less accurate congestion estimate, DCTCP > >still performs better than RFC 3168. > >RFC3168 ECN is designed to be robust to any amount of pure ack loss. > > >- If the estimation gain is small enough relative to the packet loss > >rate, the estimate may not be degraded much. > >Not knowing whether ECE feedback is 0%, 20% or 40% is not a small >estimation error. > >And the example in Appx A is not a contrived example. Once the >sender needs to allow for possible pure ACK losses (which it doesn't >know), it has insufficient information to guess what the ACK stream means: >in the example given, the sender can guess 0% on the balance of >probabilities, but it doesn't really know whether 40% is more likely >to be correct... > >...because the sender cannot know the pure ACK loss rate, because >pure ACKs are not delivered reliably. So, it cannot estimate how >much pure ACK losses might be altering its estimate of CE probability. >This is also because the gaps between DCTCP's delayed ACKs depend on >the unpredictable sequence of CE marks itself, which leads to a catch-22. > > >- It may be that packet losses mostly occur under heavy congestion. > >In which case, most drops occur during an unbroken string of CE packets. > >We're talking about ACK losses on the reverse path, which can be >uncorrelated with congestion on the forward path. > > > >I'd need data about the distribution of CE events relative to packet > >drops to analyze the impact, and I don't have this data, so the > >above is all speculation. > >No-one is planning to write artificial intelligence algorithms to >estimate what the protocol probably intended to mean. We're just >re-designing the protocol, so it works, including during reverse >congestion. We're not attached to Microsoft's design of DCTCP like >its our favourite pet dog. It's just a protocol. If it isn't safe >when it's most needed, we just kill it and make another one. > > >But DCTCP is successfully deployed in large datacenters today, so it > >works well in at least some environments. > >Just because the brakes have always worked on a trian, doesn't mean >the emergency braking system will always work when its needed, >especially given a design flaw has been pointed out. > > > >For the case where one server uses DCTCP and the other implements > >standard RFC 3168 behavior, Lars had a graduate student who analyzed > >this situation in detail and proposed some improvements. We will add > >a reference to this paper in the next version. > >Is it anything like our proposal to use differently configured AQM >for ECN and non-ECN? > > > > >"Won't they conclude that they can use DCTCP as is, given MS is using it?" > > > >I believe they can use DCTCP as is. I'm not opposed to developing > >something better, but DCTCP seems to work well in practice. > >I'm not saying the sky is falling. I am saying, if it does, we don't >have a way to respond. > > >Bob > > > >-----Original Message----- > >From: Bob Briscoe [mailto:bob.briscoe@bt.com] > >Sent: Thursday, March 13, 2014 12:05 PM > >To: Stephen Bensley > >Cc: Scharf, Michael (Michael); Martin Stiemerling; > >gorry@erg.abdn.ac.uk; Richard Scheffenegger; tcpm IETF list > >Subject: RE: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > > >Stephen, > > > >At 14:52 13/03/2014, Stephen Bensley wrote: > > >Hello Bob and others, > > > > > >I'm one of the authors of the draft. I'm new to writing IETF drafts, so > > >I'll defer to my co-authors on the debate over intended status. > > >The current plan is to switch this to Informational in the next version. > > > > > >I agree that we should document any known limitations with DCTCP. I > > >don't have any data on the effect of lost ACKs, but I will mention that > > >dropped ACKs degrade the congestion estimate. > > > >It's worse than that. Even if no ACKS have been dropped, the sender > >cannot know that no ACKs have been dropped, because every gap > >between delayed ACKS could represent a pure ACK loss. So the > >feedback is always highly ambiguous. If losses are extremely rare on > >ECN traffic, the ambiguity can be assumed not to exist. But as soon > >as there's a few losses, that assumption collapses and you have a > >very broken TCP protocol. > > > > >In the deployment issues section, I will make it clear that there is no > > >negotiation. I'll also mention the RTT fairness issue. Anything else > > >specifically that you'd like to see covered? > > > >For me personally, RTT fairness isn't an issue, and if it were for > >anyone else, they would have to deprecate TCP itself as well. > > > >The only other concern I have is what people will do when they read > >an RFC that says Microsoft is using DCTCP, altho it has problems, > >but then the draft doesn't point to any solutions (because we are > >still working on them). Won't they conclude that they can use DCTCP > >as is, given MS is using it? > > > >==The no.1 concern is capability negotiation. == There are very few > >codepoints left for negotiation, so if implementations appear that > >either burn up the remaining codepoints without agreement, or don't > >negotiate at all, the TCP wire protocol will become unusable with > >ECN. So the stakes are very high. > > > >Win8 server already started us down this slippery slope, given it > >can use a different wire protocol without negotiation, so we need to > >fix this rapidly. > > > >Superficially it seems safe because: > >- the data centre template has to be turned on in Windows, > >- it has to have negotiated ECN with the other end > >- the RTT has to be below x (5ms from memory). > > > >But what if one of our customers turns on the DC template in the > >Windows servers in one of the DCs we interconnect with the DCs of > >other customers? These TCPs will then start talking with other > >standard TCP implementations in other DCs, but using the ECN flags > >differently without the other end knowing. Chaos ensues. > > > > >I think Lars has already made this clear, but just to reiterate, our > > >primary goals for documenting DCTCP were to provide a mechanism for the > > >IPR disclosure and to document Windows behavior for the benefit of > > >other stacks that would like to interoperate. There are some sizable > > >DCTCP deployments, and thus, there has been some interest from > > >non-Microsoft vendors to implement DCTCP. We hope to facilitate this by > > >providing quality documentation and a royalty-free license. > > > >This must have involved quite a bit of work internally for no direct > >gain, so thank you for doing this. > > > > > > > > >If there is interest in doing further congestion control > > >improvements for datacenters, I'm happy to participate, but perhaps > > >this draft isn't the best vehicle for that. > > > >I think you were right to just document what you had done. > >Particularly to make the IPR position clear. And if you make the > >listed problems extremely clear, and point to solutions, I'll be happy. > > > >Do you want me to point you at all the relevant background? > > > >You will see a roadmap of the drafts I think are necessary on slide > >11 of a presentation I gave to TSVAREA about this last week > >(including your draft): > > > >To be clear, this roadmap has greater ambitions than just private > >data centres. > > > > > >Bob > > > > > > >Thanks for the feedback, > > >Stephen Bensley > > > > > >-----Original Message----- > > >From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > > >Sent: Tuesday, March 11, 2014 7:26 AM > > >To: Scharf, Michael (Michael); Martin Stiemerling; > > >gorry@erg.abdn.ac.uk; Richard Scheffenegger > > >Cc: tcpm IETF list > > >Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > > > > >Gorry, Michael, Martin, Richard, > > > > > >I would be happy with INF as long as the outstanding issues were > > >clearly identified (feedback broken, no negotiation of alternate > > >wire protocol, deployment applicability, etc) > > > > > >The main reason for suggesting HISTORIC was to avoid people getting > > >the impression the protocol as currently implemented is good to go > > >on the public Internet. > > > > > > > > >Bob > > > > > >At 09:28 10/03/2014, Gorry Fairhurst wrote: > > > >This seems sensible to me, get WG comments feedback for an individual > > > >submission (via AD) and propose as INFO. If there is feedback by the > > > >authors they want it to be HISTORIC, that would be OK also. > > > > > > > >To me, it would need careful crafting of the abstract to explain the > > > >current position with respect to other work in this area. > > > > > > > >Gorry > > > > > > > >On 09/03/2014 11:02, Scharf, Michael (Michael) wrote: > > > >>Hi Bob, > > > >> > > > >>I think we should encourage that implementers document widely deployed > > > >>TCP mechanism in the RFC series, if they are willing to discuss with > > > >>the IETF and improve document clarity so that the document is a good, > > > >>informational description that can be used as reference. (This thought > > > >>is actually independent of DCTCP.) > > > >> > > > >>If implementers are responsive to questions, such informational > > > >>documentation (possible as AD-sponsored document) should actually be > > > >>possible rather quickly. This almost likely implies that the RFC > > > >>documents a mechanism that is still in use at the time of publication. > > > >>To me, this is not "historic". > > > >> > > > >>I could imagine that a Proposed Standard produced by the IETF changes > > > >>the status to "Historic" at a later stage. But even then I'd ask > > > >>whether the Proposed Standard indeed describes what is deployed, or > > > >>will be deployed, at large scale in the Internet. > > > >> > > > >>Thanks > > > >> > > > >>Michael (as individual contributor) > > > >> > > > >> > > > >> > > > >>>-----Original Message----- > > > >>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > > > >>>Sent: Thursday, March 06, 2014 3:52 PM > > > >>>To: EGGERT, Lars; Martin Stiemerling > > > >>>Cc: tcpm IETF list > > > >>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC? > > > >>> > > > >>>Lars, > > > >>> > > > >>>Everyone seems to agree this should be independent stream. That > > > >>>leaves the question of intended status... > > > >>> > > > >>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do > > > >>>you want to update this draft? I doubt it. > > > >>> > > > >>>So, IMO if you wanted to only document what Microsoft did, even tho > > > >>>it was broken, then this should be HISTORIC, not INFORMATIONAL. > > > >>> > > > >>>If it's INFORMATIONAL it should at least fix known major problems > > > >>>before it is published. > > > >>> > > > >>> > > > >>> > > > >>>Bob > > > >>> > > > >>> > > > >>> > > > >>>________________________________________________________________ > > > >>>Bob Briscoe, BT > > > >>> > > > >>>_______________________________________________ > > > >>>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 > > > > > >_______________________________________________ > > >tcpm mailing list > > >tcpm@ietf.org > > >https://www.ietf.org/mailman/listinfo/tcpm > > > >________________________________________________________________ > >Bob Briscoe, BT > >________________________________________________________________ >Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From nobody Wed Apr 9 05:20: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 ACDDC1A0285; Wed, 9 Apr 2014 05:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T2MTzzlMV_8; Wed, 9 Apr 2014 05:20:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D21A020F; Wed, 9 Apr 2014 05:20:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140409122016.5188.49191.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 05:20:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/yDvdvJN3JCnaoBGbDv-rfkv4IO8 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:20:17 -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 : A Roadmap for Transmission Control Protocol (TCP) Specification Documents Authors : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-04.txt Pages : 52 Date : 2014-04-09 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-rfc4614bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 9 05:22: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 CFE551A029C for ; Wed, 9 Apr 2014 05:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 n4i4ZgSpGsPE for ; Wed, 9 Apr 2014 05:22:54 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC251A0286 for ; Wed, 9 Apr 2014 05:22:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,826,1389772800"; d="asc'?scan'208";a="115713705" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 09 Apr 2014 05:22:49 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 9 Apr 2014 05:22:49 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-04.txt Thread-Index: AQHPU+4n+J4bibA5KEy/NBn4o2wSopsJqlGA Date: Wed, 9 Apr 2014 12:22:47 +0000 Message-ID: <034E30C7-54AC-44BD-8392-DE032F8F9D24@netapp.com> References: <20140409122016.5188.49191.idtracker@ietfa.amsl.com> In-Reply-To: <20140409122016.5188.49191.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.22] Content-Type: multipart/signed; boundary="Apple-Mail=_D40CB83D-5057-4654-BD75-BC67479C990F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HerWpmf2l-yuJ8waZibvrHTMTF0 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:22:56 -0000 --Apple-Mail=_D40CB83D-5057-4654-BD75-BC67479C990F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reflects last call comments. Alex Am 09.04.2014 um 14:20 schrieb internet-drafts@ietf.org: >=20 > 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. >=20 > Title : A Roadmap for Transmission Control Protocol = (TCP) Specification Documents > Authors : Martin Duke > Robert Braden > Wesley M. Eddy > Ethan Blanton > Alexander Zimmermann > Filename : draft-ietf-tcpm-tcp-rfc4614bis-04.txt > Pages : 52 > Date : 2014-04-09 >=20 > Abstract: > This document contains a "roadmap" to the Requests for Comments = (RFC) > documents relating to the Internet's Transmission Control Protocol > (TCP). This roadmap provides a brief summary of the documents > defining TCP and various TCP extensions that have accumulated in the > RFC series. This serves as a guide and quick reference for both TCP > implementers and other parties who desire information contained in > the TCP-related RFCs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-tcp-rfc4614bis-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_D40CB83D-5057-4654-BD75-BC67479C990F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNFO5cACgkQdyiq39b9uS7NKwCg1QIDYK9EplIPWX5jtjextknj oHYAoPOheOFQCsOV1aNDHBRVQNsgC9CC =tkN1 -----END PGP SIGNATURE----- --Apple-Mail=_D40CB83D-5057-4654-BD75-BC67479C990F-- From nobody Thu Apr 10 00:31:32 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5561A013A for ; Thu, 10 Apr 2014 00:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 Cg8G4w1GsLq0 for ; Thu, 10 Apr 2014 00:31:27 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 949B11A00BF for ; Thu, 10 Apr 2014 00:31:26 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A6F7C278151 for ; Thu, 10 Apr 2014 16:31:23 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id pv20so1991645lab.38 for ; Thu, 10 Apr 2014 00:31:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.26.66 with SMTP id j2mr11230300lag.25.1397115080873; Thu, 10 Apr 2014 00:31:20 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Thu, 10 Apr 2014 00:31:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 00:31:20 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e0160be541b1a9e04f6ab3492 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_jIpXx7MlmYkAtPHAb9C2okVNp4 Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-rfc4614bis-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Apr 2014 07:31:31 -0000 --089e0160be541b1a9e04f6ab3492 Content-Type: text/plain; charset=ISO-8859-1 Hello, This is an announcement that we have concluded the WGLC for 4614bis. During the WGLC, there has been discussions about some of old RFCs whose status is unknown. The chairs are thinking that creating another doc that makes some of these RFCs historic is good approach rather than doing it in the draft or not doing anything. If someone has opinions on this, please speak up. Otherwise, we will proceed this draft to the next step and will start discussions on another one. Thanks, -- Yoshifumi (on behalf of tcpm co-chairs) On Tue, Mar 18, 2014 at 9:56 PM, Yoshifumi Nishida wrote: > Hello, > > As we have discussed in the London meeting, we initiate WGLC for > draft-ietf-tcpm-tcp-rfc4614bis-03. The WGLC will run until * April 4th *. > The intended status of the draft is Informational. > > If you have any comments or questions on this document, please send us > before the deadline. > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-03 > > Thanks, > -- > Yoshifumi > (on behalf of tcpm co-chairs)d --089e0160be541b1a9e04f6ab3492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

This is an announcement that we have conclud= ed the WGLC for 4614bis.

During the WGLC, there has been discussions= about some of old RFCs whose status is unknown.
The chairs are th= inking that creating another doc that makes some of these RFCs historic is = good approach rather than doing it in the draft or not doing anything.

If someone has opinions on this, please speak up. Other= wise, we will proceed this draft to the next step and will start discussion= s on another one.

Thanks,
--
Yoshifumi
(on behalf of tcpm co-chairs)

On Tue, Mar= 18, 2014 at 9:56 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> Hello,
>
> As we have discussed in the London meeting, we initiate WGLC for
&g= t; draft-ietf-tcpm-tcp-rfc4614bis-03. The WGLC will run until * April 4th *= .
> The intended status of the draft is Informational.
>
> If you have any comments or questions on this document, please send us=
> before the deadline.
> The draft is available at:
> http= ://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-03
>
> Thanks,
> --
> Yoshifumi
> (on behalf of tcp= m co-chairs)d
--089e0160be541b1a9e04f6ab3492-- From nobody Thu Apr 10 06:38: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 756FC1A021E for ; Thu, 10 Apr 2014 06:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 Yi-gAOl91lpe for ; Thu, 10 Apr 2014 06:38:07 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0017E1A01DC for ; Thu, 10 Apr 2014 06:38:06 -0700 (PDT) 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.327.1; Thu, 10 Apr 2014 14:38:02 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 10 Apr 2014 14:38:03 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Thu, 10 Apr 2014 14:38:02 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.122.119]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s3ADc0tp000859; Thu, 10 Apr 2014 14:38:01 +0100 Message-ID: <201404101338.s3ADc0tp000859@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Apr 2014 14:37:59 +0100 To: Richard Scheffenegger , Mirja KUEHLEWIND 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/iaVz3v3Sb-kTmEBAGOWv2CCGzpk Cc: tcpm IETF list Subject: [tcpm] draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Apr 2014 13:38:11 -0000 Richard, Mirja, There's a general need to make the text describing normative requirements clearer. However, we can deal with wordsmithing later. First we need to agree what normative statements we are trying to make. Here's my suggestions: S.2.3 More Accurate ECN TCP Receiver OLD: With each ACK the receiver will calculate CI modulo 5 and set the respective codepoint in the ACE field (see Table 2). In addition, the receiver calculates CI divided by 5 and may set the "Top ACE" field to this value, provided the URG flag is not set in the segment. ALTERNATIVE 1: With each ACK the receiver will calculate CI modulo 5 and MUST set the respective codepoint in the ACE field (see Table 2). In addition, if the receiver does not need to set the URG flag, it calculates CI divided by 5 and it MUST set the "Top ACE" field to this value. REASONING: - 1st MUST (setting ACE) is required for basic protocol compliance. - 2nd MUST (conditionally setting Top ACE) avoids having another mechanism for the receiver to say whether it has set Top ACE or not. And we don't want a malicious receiver to be able to choose not to feed back the nonce, while still getting the benefit of AccECN. ALTERNATIVE 2 (if testing finds some middleboxes drop a non-zero URG ptr when URG flag=0): With each ACK the receiver will calculate CI modulo 5 and MUST set the respective codepoint in the ACE field (see Table 2). In addition, if the receiver does not need to set the URG flag, it calculates CI divided by 5 and it SHOULD set the "Top ACE" field to this value. A valid reason for not setting Top ACE to CI/5 would be if the receiver has discovered that such packets are not being forwarded. If, when URG flag = 0, the receiver does not set Top ACE to CI/5, it MUST set Top ACE to zero instead, and continue setting it to zero for the remainder of the connection. REASONING: We don't want to lose one value of Top ACE by defining URG_flag=0 and TopACE=0 as a special 'undefined' value not to be used when cycling the counters. Instead, the sender only needs to test for a wrap to zero in Top ACE of more than one, then it MUST turn off processing Top ACE for the rest of the connection. Nits in the draft: _________________ S.2.2.2 s/ETC(1)/ECT(1)/ S.2.2.3 Need to say explicitly that Top ACE is defined as - the Top of CI if the value of ACE is one of the CI codepoints - the Top of E1 if the value of ACE is one of the E1 codepoints S.2.4 s/exclude/decode/ Bob ________________________________________________________________ Bob Briscoe, BT From nobody Thu Apr 10 09:02:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0C1A0297 for ; Thu, 10 Apr 2014 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 V2Qot846LWx8 for ; Thu, 10 Apr 2014 09:02:18 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id AA1501A01DC for ; Thu, 10 Apr 2014 09:02:17 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 10 Apr 2014 17:02:14 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 10 Apr 2014 17:02:15 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Thu, 10 Apr 2014 17:02:10 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.122.119]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s3AG28nH001717; Thu, 10 Apr 2014 17:02:09 +0100 Message-ID: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Apr 2014 17:02:08 +0100 To: 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/ru8_yMSoGqCA_VqFAPF9rQME3_E Cc: draft-tcpm-fastopen@tools.ietf.org, tcpm IETF list Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Apr 2014 16:02:20 -0000 Yuchung, In draft-tcpm-fastopen, you may be able to get away with saying nothing about this, but.. 1) Just in case someone thinks it would be clever for a TFO client to resume use of ECN on a subsequent SYN, it may be best to clarify that: "TFO does not allow a subsequent connection to reuse the ECN capability negotiated in a previous connection. If TCP endpoints negotiate the use of ECN, they MUST apply the initialization rules (Section 6.1.1 of [RFC3168]) separately for each connection." 2) You might also want to recommend using RFC 5562 (ECN on SYN-ACK), just to give developers a tick-list of RFCs to use. However, if you plan to quickly move TFO on from experimental status, make sure you just say this 'for information', rather than as a normative reference, because 5562 is experimental. I know this is my second comment after WGLC, but I thought it best to say something. (I was just getting the capability negotiation logic in Accurate ECN to interwork with TFO, when I realised this issue applied to classic ECN too.) Bob ________________________________________________________________ Bob Briscoe, BT From nobody Thu Apr 10 09:18: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 0E4F81A01FF for ; Thu, 10 Apr 2014 09:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 fpZXSo0b-Qht for ; Thu, 10 Apr 2014 09:18:12 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A04871A01DC for ; Thu, 10 Apr 2014 09:18:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,835,1389772800"; d="scan'208";a="157055850" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 10 Apr 2014 09:18:11 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 09:18:11 -0700 From: "Scheffenegger, Richard" To: Bob Briscoe , Mirja KUEHLEWIND Thread-Topic: draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed Thread-Index: AQHPVMIbKLG9A02TCEmey1MzcOG4hJsLA1bA Date: Thu, 10 Apr 2014 16:18:10 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A3001B1@SACEXCMBX02-PRD.hq.netapp.com> References: <201404101338.s3ADc0tp000859@bagheera.jungle.bt.co.uk> In-Reply-To: <201404101338.s3ADc0tp000859@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.21] 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/heOHS5KdXmjMEcd4CgU2P155BNw Cc: tcpm IETF list Subject: Re: [tcpm] draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Apr 2014 16:18:14 -0000 Hi Bob, >=20 > Richard, Mirja, >=20 > OLD: > With each ACK the receiver will calculate CI > modulo 5 and set the respective codepoint in the ACE field (see Table > 2). In addition, the receiver calculates CI divided by 5 and may set > the "Top ACE" field to this value, provided the URG flag is not set > in the segment. I'm in favor of > ALTERNATIVE 2 (if testing finds some middleboxes drop a non-zero URG ptr > when URG flag=3D0): I see more middleboxes sanitizing the URGPTR; but I haven't yet looked spec= ifically at TCP session drops due to a set URGPTR, but that is on my todo l= ist for the next measurement run. Actually, I found an interesting data point in a book [1] that I was readin= g - a number of versions of windows inadvertedly leaked data on uninitializ= ed ACK and URGPTR fields for years. Obviously, that issue never caused TCP = session setups to fail, thus its save to assume that this worldwide test co= nducted by Microsoft "fixed" any misbehaving stacks and middleboxes (which = would not properly work with URGPRT !=3D 0) long ago. > With each ACK the receiver will calculate CI > modulo 5 and MUST set the respective codepoint in the ACE field (see > Table > 2). In addition, if the receiver does not need to set the URG flag, > it > calculates CI divided by 5 and it SHOULD set the "Top ACE" field to > this value. > A valid reason for not setting Top ACE to CI/5 would be if the > receiver has > discovered that such packets are not being forwarded. If, when URG > flag =3D 0, > the receiver does not set Top ACE to CI/5, it MUST set Top ACE to zer= o > instead, > and continue setting it to zero for the remainder of the connection. > REASONING: > We don't want to lose one value of Top ACE by defining URG_flag=3D0 and > TopACE=3D0 as a special 'undefined' value not to be used when cycling the > counters. Instead, the sender only needs to test for a wrap to zero in To= p > ACE of more than one, then it MUST turn off processing Top ACE for the > rest of the connection. I think we should have this even more strict, and have a URGPTR negotiation= during 3WHS: a) set URGPTR =3D 0x???F in SYN b) set URGPRT =3D 0x???1 if ???F was received or 0x???0 if ???0 was receive= d in SYN/ACK -> negotiate to both ends, if URGPTR may be used. Then, if URGPTR can NOT be used, have AccECN signal the most conservative c= ongestion indication, whenever an overflow may have occurred (multiple ACKs= being lost, even when ECI not changed). This should give a good incentive = for sanitizing middleboxes to clean up their act :) Especially when these a= re close to the server and in the same admin domain as the poor performing = service... And yes, if URGPTR cannot be used, the TCP MUST set TopACE to 0 at all time= s... [1] Silence on the Wire: A Field Guide to Passive Reconnaissance and Indire= ct Attacks, Michal Zalewski, No Starch Press, 2005 - 281 pages Best regards, Richard From nobody Thu Apr 10 11:08: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 0668F1A039B for ; Thu, 10 Apr 2014 11:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 tarWocs_d0Ho for ; Thu, 10 Apr 2014 11:08:41 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id E5F261A0395 for ; Thu, 10 Apr 2014 11:08:40 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 19:08:38 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 10 Apr 2014 19:08:37 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Thu, 10 Apr 2014 19:08:37 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.122.119]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s3AI8ZK2002299; Thu, 10 Apr 2014 19:08:36 +0100 Message-ID: <201404101808.s3AI8ZK2002299@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Apr 2014 19:08:35 +0100 To: "Scheffenegger, Richard" From: Bob Briscoe In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F4A3001B1@SACEXCMBX02-PRD.h q.netapp.com> References: <201404101338.s3ADc0tp000859@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F4A3001B1@SACEXCMBX02-PRD.hq.netapp.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/uRqfjSAfGgBLzZ-1HIecgf7fZ4o Cc: tcpm IETF list Subject: Re: [tcpm] draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Apr 2014 18:08:46 -0000 Richard, At 17:18 10/04/2014, Scheffenegger, Richard wrote: >Hi Bob, > > > > Richard, Mirja, > > > > OLD: > > With each ACK the receiver will calculate CI > > modulo 5 and set the respective codepoint in the ACE field (see Table > > 2). In addition, the receiver calculates CI divided by 5 and may set > > the "Top ACE" field to this value, provided the URG flag is not set > > in the segment. > >I'm in favor of > > > ALTERNATIVE 2 (if testing finds some middleboxes drop a non-zero URG ptr > > when URG flag=0): > >I see more middleboxes sanitizing the URGPTR; but I haven't yet >looked specifically at TCP session drops due to a set URGPTR, but >that is on my todo list for the next measurement run. > >Actually, I found an interesting data point in a book [1] that I was >reading - a number of versions of windows inadvertedly leaked data >on uninitialized ACK and URGPTR fields for years. Obviously, that >issue never caused TCP session setups to fail, thus its save to >assume that this worldwide test conducted by Microsoft "fixed" any >misbehaving stacks and middleboxes (which would not properly work >with URGPRT != 0) long ago. That' cool. Obviously your bedtime reading is more interesting than mine ;) > > With each ACK the receiver will calculate CI > > modulo 5 and MUST set the respective codepoint in the ACE field (see > > Table > > 2). In addition, if the receiver does not need to set the URG flag, > > it > > calculates CI divided by 5 and it SHOULD set the "Top ACE" field to > > this value. > > A valid reason for not setting Top ACE to CI/5 would be if the > > receiver has > > discovered that such packets are not being forwarded. If, when URG > > flag = 0, > > the receiver does not set Top ACE to CI/5, it MUST set Top ACE to zero > > instead, > > and continue setting it to zero for the remainder of the connection. > > REASONING: > > We don't want to lose one value of Top ACE by defining URG_flag=0 and > > TopACE=0 as a special 'undefined' value not to be used when cycling the > > counters. Instead, the sender only needs to test for a wrap to zero in Top > > ACE of more than one, then it MUST turn off processing Top ACE for the > > rest of the connection. > >I think we should have this even more strict, and have a URGPTR >negotiation during 3WHS: > >a) set URGPTR = 0x???F in SYN >b) set URGPRT = 0x???1 if ???F was received or 0x???0 if ???0 was >received in SYN/ACK > >-> negotiate to both ends, if URGPTR may be used. Don't agree here. The point of my suggested text was that, for short connections, you'll never need to have a value higher than 0000 in the URG PTR anyway. So no point risking timeouts by negotiating it in SYN. Instead, the first time that the ACE field wraps, the receiver sets Top ACE to 0001 anyway. Then whenever the sender code detects a wrap in the ACE value, if there's no corresponding increment in the Top ACE value it knows a middlebox has normalised it. Then the sender must stop reading Top ACE for the rest of the connection (in case the normalisation isn't consistent (abnormal normalisation!)). The same procedure can happen independently on the other half connection. Ie the sender can detect the problem by inference rather than negotiation, because of the way ACE and Top ACE are defined to work together. If your experiments continue to find no middleboxes actually discarding Top ACE != 0 packets, so the problem is only 'normalisation', then I don't see the need for negotiation about using a field that is for optional accuracy anyway. >Then, if URGPTR can NOT be used, have AccECN signal the most >conservative congestion indication, whenever an overflow may have >occurred (multiple ACKs being lost, even when ECI not changed). This >should give a good incentive for sanitizing middleboxes to clean up >their act :) Especially when these are close to the server and in >the same admin domain as the poor performing service... Can a receiver do anything more conservative that what it's doing anyway? It's just a dumb reflector. I suppose it could turn off delayed ACKs. But is that a good idea to recommend more ACKs whenever multiple pure ACKs seem to be getting lost? And how does it know that? My proposal was on the basis that the receiver doesn't need to know that its Top ACE is being normalised, because it can't do anything about it anyway. Can it? >And yes, if URGPTR cannot be used, the TCP MUST set TopACE to 0 at >all times... > > > > >[1] Silence on the Wire: A Field Guide to Passive Reconnaissance and >Indirect Attacks, Michal Zalewski, No Starch Press, 2005 - 281 pages Cheers Bob >Best regards, > Richard ________________________________________________________________ Bob Briscoe, BT From nobody Fri Apr 11 01:18: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 4F5361A040D for ; Fri, 11 Apr 2014 01:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 tadq47X6B_DC for ; Fri, 11 Apr 2014 01:17:58 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C60961A03F4 for ; Fri, 11 Apr 2014 01:17:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,840,1389772800"; d="scan'208";a="157229393" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 11 Apr 2014 01:17:54 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 01:17:54 -0700 From: "Scheffenegger, Richard" To: Bob Briscoe Thread-Topic: draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed Thread-Index: AQHPVMIbKLG9A02TCEmey1MzcOG4hJsLA1bAgAAi+FuAAN9ngA== Date: Fri, 11 Apr 2014 08:17:53 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A3014C7@SACEXCMBX02-PRD.hq.netapp.com> References: <201404101338.s3ADc0tp000859@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F4A3001B1@SACEXCMBX02-PRD.hq.netapp.com> <201404101808.s3AI8ZK2002299@bagheera.jungle.bt.co.uk> In-Reply-To: <201404101808.s3AI8ZK2002299@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.21] 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/kbHEHSVubm-kSd5xd3wP2RBPMts Cc: tcpm IETF list Subject: Re: [tcpm] draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Apr 2014 08:18:00 -0000 Hi Bob, >=20 > That' cool. Obviously your bedtime reading is more interesting than mine > ;) Well, it at least means that I'm a complete nerd ;) > >-> negotiate to both ends, if URGPTR may be used. >=20 > Don't agree here. >=20 > The point of my suggested text was that, for short connections, you'll > never need to have a value higher than 0000 in the URG PTR anyway. So no > point risking timeouts by negotiating it in SYN. Ok, point taken.=20 > Instead, the first time that the ACE field wraps, the receiver sets Top > ACE to 0001 anyway. Then whenever the sender code detects a wrap in the > ACE value, if there's no corresponding increment in the Top ACE value it > knows a middlebox has normalised it. Then the sender must stop reading To= p > ACE for the rest of the connection (in case the normalisation isn't > consistent (abnormal normalisation!)). >=20 > The same procedure can happen independently on the other half connection. >=20 > Ie the sender can detect the problem by inference rather than negotiation= , > because of the way ACE and Top ACE are defined to work together. >=20 > If your experiments continue to find no middleboxes actually discarding > Top ACE !=3D 0 packets, so the problem is only 'normalisation', then I do= n't > see the need for negotiation about using a field that is for optional > accuracy anyway. So, in the unlikely event when a middlebox doesn't normalize but discard... Those ACKs wouldn't make it through. On the forward path, everything would = look ok (until a TopACE rollover happens). So the sender would perform RTO = retransmissions until session timeout, with the receiver ACKing every segme= nt properly. Do we need to care about this pathology in the receiver code? Or simply leave that unspecified, so that this particular brokenness is fix= ed either by disableing AccECN or removal of the broken box? The problem would be, that this effect would happen only a couple (dozen) s= egments into the session, and non-deterministically (due to CE / ECT(1) mar= ks received on a session), making troubleshooting a nightmare. >=20 > >Then, if URGPTR can NOT be used, have AccECN signal the most > >conservative congestion indication, whenever an overflow may have > >occurred (multiple ACKs being lost, even when ECI not changed). This > >should give a good incentive for sanitizing middleboxes to clean up > >their act :) Especially when these are close to the server and in the > >same admin domain as the poor performing service... >=20 > Can a receiver do anything more conservative that what it's doing anyway? > It's just a dumb reflector. I suppose it could turn off delayed ACKs. But > is that a good idea to recommend more ACKs whenever multiple pure ACKs > seem to be getting lost? And how does it know that? See above; if the negotiation for TopACE fails (SYN with URGPTR=3D=3D0; SYN= ACK with URGPTR=3D=3D0, or SYN / SYNACK need to be retransmitted, eventuall= y with TopACE set to 0), the receiver would never set TopACE. Path changes = may still cause problems when the new path suddenly drops TopACE packets...= and that we can not address anyhow. For the sender, when it detects that TopACE is unusable, it can (should) sw= itch into most conservative mode, IMHO. > My proposal was on the basis that the receiver doesn't need to know that > its Top ACE is being normalised, because it can't do anything about it > anyway. Can it? Silent discards would be the more pronounced issue, normalization can be de= alt with rather easily. But as mentioned, it appears that discard is very uncommon, normalization i= s rare but exists on numerous paths. I need to run my next set of tests (SMTP servers this time :), with code to= check for discarded SYNs). Give me a couple days. From nobody Fri Apr 11 08:58:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6297E1A06E3 for ; Fri, 11 Apr 2014 08:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 siKWdYASuvY6 for ; Fri, 11 Apr 2014 08:58:38 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id CBB9E1A01AD for ; Fri, 11 Apr 2014 08:58:37 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 11 Apr 2014 16:58:34 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 11 Apr 2014 16:58:34 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Fri, 11 Apr 2014 16:58:31 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.134.174]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s3BFwSS1006449; Fri, 11 Apr 2014 16:58:28 +0100 Message-ID: <201404111558.s3BFwSS1006449@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Apr 2014 16:58:08 +0100 To: "Scheffenegger, Richard" From: Bob Briscoe In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F4A3014C7@SACEXCMBX02-PRD.h q.netapp.com> References: <201404101338.s3ADc0tp000859@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F4A3001B1@SACEXCMBX02-PRD.hq.netapp.com> <201404101808.s3AI8ZK2002299@bagheera.jungle.bt.co.uk> <012C3117EDDB3C4781FD802A8C27DD4F4A3014C7@SACEXCMBX02-PRD.hq.netapp.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/Aty4YBLbHlw2J0DWBWXDxXESBIw Cc: tcpm IETF list Subject: Re: [tcpm] draft-kuehlewind-tcpm-accurate-ecn-02: Normative language needed X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Apr 2014 15:58:40 -0000 Richard, At 09:17 11/04/2014, Scheffenegger, Richard wrote: >Hi Bob, > > > >-> negotiate to both ends, if URGPTR may be used. > > > > Don't agree here. > > > > The point of my suggested text was that, for short connections, you'll > > never need to have a value higher than 0000 in the URG PTR anyway. So no > > point risking timeouts by negotiating it in SYN. > >Ok, point taken. > > > > Instead, the first time that the ACE field wraps, the receiver sets Top > > ACE to 0001 anyway. Then whenever the sender code detects a wrap in the > > ACE value, if there's no corresponding increment in the Top ACE value it > > knows a middlebox has normalised it. Then the sender must stop reading Top > > ACE for the rest of the connection (in case the normalisation isn't > > consistent (abnormal normalisation!)). > > > > The same procedure can happen independently on the other half connection. > > > > Ie the sender can detect the problem by inference rather than negotiation, > > because of the way ACE and Top ACE are defined to work together. > > > > If your experiments continue to find no middleboxes actually discarding > > Top ACE != 0 packets, so the problem is only 'normalisation', then I don't > > see the need for negotiation about using a field that is for optional > > accuracy anyway. > >So, in the unlikely event when a middlebox doesn't normalize but discard... > >Those ACKs wouldn't make it through. On the forward path, everything >would look ok (until a TopACE rollover happens). So the sender would >perform RTO retransmissions until session timeout, with the receiver >ACKing every segment properly. Do we need to care about this >pathology in the receiver code? > >Or simply leave that unspecified, so that this particular brokenness >is fixed either by disableing AccECN or removal of the broken box? > >The problem would be, that this effect would happen only a couple >(dozen) segments into the session, and non-deterministically (due to >CE / ECT(1) marks received on a session), making troubleshooting a nightmare. Yes, nightmare. This is why your experiments are important - to test whether we ever see a non-zero URG-PTR dropped. If the only visible pathology is normalisation (which is all you've found so far, and the windows bugs you mentioned help explain why), then I would agree with your approach: actively test for normalising middleboxes in the 3WHS. Ie. we don't need to care about the risk of timeouts from a pathology that testing cannot detect. However, if your tests find even a very few middleboxes discarding non-zero URG-PTR, then the balance of risks alters. Then we should probably take the risk of /not/ actively testing for normalisation in the 3WHS, to avoid the risk of a timeout due to a discarding middlebox. Instead, we consider adopting my original proposal: wait until the algo would actually start using a non-zero URG-PTR anyway then, if there is a normalising middlebox, there is a small risk that the sender won't immediately detect that ACKs are being normalised - but only in the unlikely case of long sequences of pure ACK loss. But this is worth the small risk, because the consequences of this corner-case become less than the timeout corner-case. In summary, the best design to pick depends on your experiments. > > > > >Then, if URGPTR can NOT be used, have AccECN signal the most > > >conservative congestion indication, whenever an overflow may have > > >occurred (multiple ACKs being lost, even when ECI not changed). This > > >should give a good incentive for sanitizing middleboxes to clean up > > >their act :) Especially when these are close to the server and in the > > >same admin domain as the poor performing service... > > > > Can a receiver do anything more conservative that what it's doing anyway? > > It's just a dumb reflector. I suppose it could turn off delayed ACKs. But > > is that a good idea to recommend more ACKs whenever multiple pure ACKs > > seem to be getting lost? And how does it know that? > >See above; if the negotiation for TopACE fails (SYN with URGPTR==0; >SYNACK with URGPTR==0, or SYN / SYNACK need to be retransmitted, >eventually with TopACE set to 0), the receiver would never set >TopACE. Path changes may still cause problems when the new path >suddenly drops TopACE packets...and that we can not address anyhow. No, I meant if the receiver knows TopACE is useless and never sets it, can its feedback pattern by any more conservative than we have specified anyway? (If it /can't/ change its behaviour, it doesn't need to know whether it /should/ change its behaviour.) >For the sender, when it detects that TopACE is unusable, it can >(should) switch into most conservative mode, IMHO. > > > My proposal was on the basis that the receiver doesn't need to know that > > its Top ACE is being normalised, because it can't do anything about it > > anyway. Can it? > > >Silent discards would be the more pronounced issue, normalization >can be dealt with rather easily. > >But as mentioned, it appears that discard is very uncommon, >normalization is rare but exists on numerous paths. > >I need to run my next set of tests (SMTP servers this time :), with >code to check for discarded SYNs). > >Give me a couple days. I'm v grateful you're doing these tests. Cheers Bob ________________________________________________________________ Bob Briscoe, BT From nobody Fri Apr 11 10:43: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 63E951A0736 for ; Fri, 11 Apr 2014 10:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 pOAFdC9Stlqf for ; Fri, 11 Apr 2014 10:43:07 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2261A0731 for ; Fri, 11 Apr 2014 10:43:07 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3BHgxOm025064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Apr 2014 12:43:00 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3BHgwY9027417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 19:42:58 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 11 Apr 2014 19:42:58 +0200 From: "Scharf, Michael (Michael)" To: Bob Briscoe , "ycheng@google.com" Thread-Topic: [tcpm] draft-tcpm-fastopen: interaction with ECN Thread-Index: AQHPVNZJKcdbbfIVAEGt+UXS/0V9V5sMq2nw Date: Fri, 11 Apr 2014 17:42:57 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2A2684@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> In-Reply-To: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/O__SejIVJ8f6YGf4uwYlkNPhAGc Cc: "draft-tcpm-fastopen@tools.ietf.org" , tcpm IETF list Subject: Re: [tcpm] draft-tcpm-fastopen: interaction with ECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Apr 2014 17:43:09 -0000 Bob, Indeed, the WGLC for draft-tcpm-fastopen has completed... I am about to for= ward the document to the AD. Apparently, right now, draft-tcpm-fastopen does not comment on ECN at all, = and I am not aware of any past discussion in TCPM. Thus, my initial thinking would be that if ECN should be addressed in this = document, it could be mentioned in section 7 as a topic for further experim= entation - instead of adding normative text late in the process.=20 Thoughts from the community (and the authors) would be welcome - but please= recall that we are really past WGLC and I'd like to move the document forw= ard within the next couple of days. Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > Sent: Thursday, April 10, 2014 6:02 PM > To: ycheng@google.com > Cc: draft-tcpm-fastopen@tools.ietf.org; tcpm IETF list > Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN >=20 > Yuchung, >=20 > In draft-tcpm-fastopen, you may be able to get away with saying > nothing about this, but.. >=20 > 1) Just in case someone thinks it would be clever for a TFO client to > resume use of ECN on a subsequent SYN, it may be best to clarify that: > "TFO does not allow a subsequent connection to reuse the ECN > capability negotiated in a previous connection. If TCP endpoints > negotiate the use of ECN, they MUST apply the initialization rules > (Section 6.1.1 of [RFC3168]) separately for each connection." >=20 >=20 > 2) You might also want to recommend using RFC 5562 (ECN on SYN-ACK), > just to give developers a tick-list of RFCs to use. However, if you > plan to quickly move TFO on from experimental status, make sure you > just say this 'for information', rather than as a normative > reference, because 5562 is experimental. >=20 >=20 >=20 > I know this is my second comment after WGLC, but I thought it best to > say something. (I was just getting the capability negotiation logic > in Accurate ECN to interwork with TFO, when I realised this issue > applied to classic ECN too.) >=20 >=20 > Bob >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Apr 11 13:14: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 4C65F1A076C; Fri, 11 Apr 2014 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejlUzT1uBsuC; Fri, 11 Apr 2014 13:14:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAA61A0794; Fri, 11 Apr 2014 13:13:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411201329.6304.96002.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 13:13:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Kls1Ih16nSgERi34TcDytof9OIM Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-21.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, 11 Apr 2014 20:14:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Extensions for High Performance Authors : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-21.txt Pages : 49 Date : 2014-04-11 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, PAWS (Protection Against Wrapped Sequences) and RTTM (Round Trip Time Measurement), that are also described herein. This document obsoletes RFC1323 and describes changes from it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-21 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 Apr 11 14:36: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 2AC531A074B; Fri, 11 Apr 2014 14:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 2a6nQbSf59Fb; Fri, 11 Apr 2014 14:36:30 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB41A0392; Fri, 11 Apr 2014 14:36:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,844,1389772800"; d="scan'208";a="116351549" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 11 Apr 2014 14:36:29 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 14:36:28 -0700 From: "Scheffenegger, Richard" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-21.txt Thread-Index: AQHPVcLRpxPDspQ6+kmEsjJ0ZyXA1JsM8HGQ Date: Fri, 11 Apr 2014 21:36:27 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A3033E0@SACEXCMBX02-PRD.hq.netapp.com> References: <20140411201329.6304.96002.idtracker@ietfa.amsl.com> In-Reply-To: <20140411201329.6304.96002.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] 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/SRT0aEPU8YLBPLeHfV0hmiDYmgs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-21.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, 11 Apr 2014 21:36:32 -0000 Hi, This is a minor update to add one reference to RFC6191 brought up during th= e IESG review (and fixed one nit). Diff can be found here: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-21 Richard Scheffenegger > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Freitag, 11. April 2014 21:13 > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-21.txt >=20 >=20 > 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. >=20 > Title : TCP Extensions for High Performance > Authors : David Borman > Bob Braden > Van Jacobson > Richard Scheffenegger > Filename : draft-ietf-tcpm-1323bis-21.txt > Pages : 49 > Date : 2014-04-11 >=20 > Abstract: > This document specifies a set of TCP extensions to improve > performance over paths with a large bandwidth * delay product and to > provide reliable operation over very high-speed paths. It defines > the TCP Window Scale (WS) option and the TCP Timestamps (TS) option > and their semantics. The Window Scale option is used to support > larger receive windows, while the Timestamps option can be used for > at least two distinct mechanisms, PAWS (Protection Against Wrapped > Sequences) and RTTM (Round Trip Time Measurement), that are also > described herein. >=20 > This document obsoletes RFC1323 and describes changes from it. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-21 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-21 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Apr 14 06:37:09 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46A1A02C4; Mon, 14 Apr 2014 06:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mkbyc-P7tDD; Mon, 14 Apr 2014 06:37:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C63F1A0476; Mon, 14 Apr 2014 06:36:52 -0700 (PDT) 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.2.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140414133652.32751.3208.idtracker@ietfa.amsl.com> Date: Mon, 14 Apr 2014 06:36:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/NAGsVCX3Ng6u1kbYKVpHkUXayaA Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Protocol Action: 'TCP Extensions for High Performance' to Proposed Standard (draft-ietf-tcpm-1323bis-21.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:37:06 -0000 The IESG has approved the following document: - 'TCP Extensions for High Performance' (draft-ietf-tcpm-1323bis-21.txt) as Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ Technical Summary This document replaces RFC 1323, making minor fixes and clarifications to the original document. The document specifies three performance enhancing extensions to TCP, using two TCP options. The first is window scale option, that allows representation of receive window sizes larger than 2^16 bytes originally allowed by the 16-bit window field. The second option is TCP timestamps option that allows round-trip time measurement on each TCP segment, and third is an algorithm to detect and reject old duplicate segments that happen to match the current TCP window (Protect Against Wrapped Sequence numbers). Working Group Summary This document has been a chartered TCPM working group item since year 2008. It has not been under significant controversy, but the progress has been slow because of earlier lack of WG (and authoring) cycles. Since adding a new co-editor, the progress on the draft became faster in the working group. Document Quality The predecessor of this document, RFC 1323, was published in 1992, and is deployed in most TCP implementations. This document includes fixes and clarifications based on the gained deployment experience. The recent versions of the document have been reviewed and discussed by multiple working group participants. Personnel Document Shepherd is Pasi Sarolahti. Reponsible Area Director is Martin Stiemerling. From nobody Tue Apr 15 18:10:24 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE741A0096 for ; Tue, 15 Apr 2014 18:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 Cbxa4EVNg2ao for ; Tue, 15 Apr 2014 18:10:19 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE71A00A7 for ; Tue, 15 Apr 2014 18:10:18 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 16 Apr 2014 02:10:13 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 16 Apr 2014 02:10:12 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Wed, 16 Apr 2014 02:10:11 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.49.103]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s3G1A8j5002032; Wed, 16 Apr 2014 02:10:09 +0100 Message-ID: <201404160110.s3G1A8j5002032@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Apr 2014 02:09:34 +0100 To: "Scharf, Michael (Michael)" From: Bob Briscoe In-Reply-To: <655C07320163294895BBADA28372AF5D2A2684@FR712WXCHMBA15.zeu. alcatel-lucent.com> References: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D2A2684@FR712WXCHMBA15.zeu.alcatel-lucent.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/hPqXklNiZk1dnnC37udm7gwYt9s Cc: "draft-tcpm-fastopen@tools.ietf.org" , tcpm IETF list Subject: Re: [tcpm] draft-tcpm-fastopen: interaction with ECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Apr 2014 01:10:22 -0000 Michael, It was only advice about what not to cache. I didn't intend it as a suggestion for experimentation. And it doesn't have to be normative text (see the non-normative suggestion below). /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Append new para to end of "4.1.3 Client Cookie Handling" "A client is unlikely to find it useful to cache the result of a successful ECN negotiation for a subsequent connection. Attempting to resume a connection with a SYN that is ECN-capable at the IP layer is likely to risk discard by security devices, and a consequent timeout. Initializing ECN separately for each connection using the procedure in Section 6.1.1 of [RFC3168] should introduce no worse risk of delay. " Additional Informative Reference: [RFC3168] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ This doesn't warrant holding up the draft now. If the authors want to incorporate this para while dealing with RFC Editor comments later, it would be up to them. They might not consider it necessary at all, but on balance I think it would be. Bob At 18:42 11/04/2014, Scharf, Michael (Michael) wrote: >Bob, > >Indeed, the WGLC for draft-tcpm-fastopen has completed... I am about >to forward the document to the AD. > >Apparently, right now, draft-tcpm-fastopen does not comment on ECN >at all, and I am not aware of any past discussion in TCPM. > >Thus, my initial thinking would be that if ECN should be addressed >in this document, it could be mentioned in section 7 as a topic for >further experimentation - instead of adding normative text late in >the process. > >Thoughts from the community (and the authors) would be welcome - but >please recall that we are really past WGLC and I'd like to move the >document forward within the next couple of days. > >Michael > > > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > > Sent: Thursday, April 10, 2014 6:02 PM > > To: ycheng@google.com > > Cc: draft-tcpm-fastopen@tools.ietf.org; tcpm IETF list > > Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN > > > > Yuchung, > > > > In draft-tcpm-fastopen, you may be able to get away with saying > > nothing about this, but.. > > > > 1) Just in case someone thinks it would be clever for a TFO client to > > resume use of ECN on a subsequent SYN, it may be best to clarify that: > > "TFO does not allow a subsequent connection to reuse the ECN > > capability negotiated in a previous connection. If TCP endpoints > > negotiate the use of ECN, they MUST apply the initialization rules > > (Section 6.1.1 of [RFC3168]) separately for each connection." > > > > > > 2) You might also want to recommend using RFC 5562 (ECN on SYN-ACK), > > just to give developers a tick-list of RFCs to use. However, if you > > plan to quickly move TFO on from experimental status, make sure you > > just say this 'for information', rather than as a normative > > reference, because 5562 is experimental. > > > > > > > > I know this is my second comment after WGLC, but I thought it best to > > say something. (I was just getting the capability negotiation logic > > in Accurate ECN to interwork with TFO, when I realised this issue > > applied to classic ECN too.) > > > > > > Bob > > > > > > ________________________________________________________________ > > Bob Briscoe, BT > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm ________________________________________________________________ Bob Briscoe, BT From nobody Wed Apr 16 04:42: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 D71DA1A0112; Wed, 16 Apr 2014 04:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YNv5UC8JkOCw; Wed, 16 Apr 2014 04:42:30 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.108]) by ietfa.amsl.com (Postfix) with ESMTP id 72EFC1A010B; Wed, 16 Apr 2014 04:42:29 -0700 (PDT) Received: from [193.109.255.147:22620] by server-4.bemta-14.messagelabs.com id 00/BE-02781-E9C6E435; Wed, 16 Apr 2014 11:42:22 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-72.messagelabs.com!1397648541!12557366!8 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11389 invoked from network); 16 Apr 2014 11:42:22 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-15.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 16 Apr 2014 11:42:22 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 16 Apr 2014 12:42:07 +0100 From: To: Date: Wed, 16 Apr 2014 12:42:05 +0100 Thread-Topic: [tcpm] Protocol Action: 'TCP Extensions for High Performance' to Proposed Standard (draft-ietf-tcpm-1323bis-21.txt) Thread-Index: Ac9ZaOTm2Yh5B2kYRSC8AzM0S/7JYA== Message-ID: <2FBD2D0F-C43E-49A6-B950-AA4121ADE677@surrey.ac.uk> References: <20140414133652.32751.3208.idtracker@ietfa.amsl.com> In-Reply-To: <20140414133652.32751.3208.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB 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/uN8aS_DuZvQwqrchDndeFieLaU4 Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, l.wood@surrey.ac.uk, rfc-editor@rfc-editor.org Subject: Re: [tcpm] Protocol Action: 'TCP Extensions for High Performance' to Proposed Standard (draft-ietf-tcpm-1323bis-21.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, 16 Apr 2014 11:42:35 -0000 And here's a first cut at that TCP Extensions draft, in 1993: http://www.isocws.isoc.org/inet98/doc/rstevens/tcplw-extensions.txt getting this published in only slightly over twenty years is quite an achievement, given that the transport area is very underresourced compared to other areas, and short on expertise and manpower. (I have a few promising drafts coming along nicely at the six-year mark. Still time to mature.) Congrats! Go team! Lloyd Wood http://about.me/lloydwood On 14 Apr 2014, at 23:36, The IESG wrote: > The IESG has approved the following document: > - 'TCP Extensions for High Performance' > (draft-ietf-tcpm-1323bis-21.txt) as Proposed Standard >=20 > This document is the product of the TCP Maintenance and Minor Extensions > Working Group. >=20 > The IESG contact persons are Martin Stiemerling and Spencer Dawkins. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ >=20 >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document replaces RFC 1323, making minor fixes and > clarifications to the original document. The document > specifies three performance enhancing extensions to TCP, using > two TCP options. The first is window scale option, that allows > representation of receive window sizes larger than 2^16 bytes > originally allowed by the 16-bit window field. The second > option is TCP timestamps option that allows round-trip time > measurement on each TCP segment, and third is an algorithm to > detect and reject old duplicate segments that happen to match > the current TCP window (Protect Against Wrapped Sequence > numbers). >=20 >=20 > Working Group Summary >=20 > This document has been a chartered TCPM working group item > since year 2008. It has not been under significant > controversy, but the progress has been slow because of earlier > lack of WG (and authoring) cycles. Since adding a new > co-editor, the progress on the draft became faster in the > working group. >=20 > Document Quality >=20 > The predecessor of this document, RFC 1323, was published in > 1992, and is deployed in most TCP implementations. This > document includes fixes and clarifications based on the gained > deployment experience. The recent versions of the document > have been reviewed and discussed by multiple working group > participants. >=20 >=20 > Personnel >=20 > Document Shepherd is Pasi Sarolahti. > Reponsible Area Director is Martin Stiemerling. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 16 05:31: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 925BE1A014D for ; Wed, 16 Apr 2014 05:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 9KUL6hMm3-aY for ; Wed, 16 Apr 2014 05:31:49 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 694E31A0146 for ; Wed, 16 Apr 2014 05:31:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,872,1389772800"; d="asc'?scan'208";a="117257461" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 16 Apr 2014 05:31:46 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 05:31:46 -0700 From: "Eggert, Lars" To: "l.wood@surrey.ac.uk" Thread-Topic: [tcpm] Protocol Action: 'TCP Extensions for High Performance' to Proposed Standard (draft-ietf-tcpm-1323bis-21.txt) Thread-Index: AQHPV+avB8rsMeU1rEeuHZJcGVEQfpsUl1KAgAAN3oA= Date: Wed, 16 Apr 2014 12:31:44 +0000 Message-ID: <29A3BAC2-9670-4684-9CD9-5C7721116838@netapp.com> References: <20140414133652.32751.3208.idtracker@ietfa.amsl.com> <2FBD2D0F-C43E-49A6-B950-AA4121ADE677@surrey.ac.uk> In-Reply-To: <2FBD2D0F-C43E-49A6-B950-AA4121ADE677@surrey.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.22] Content-Type: multipart/signed; boundary="Apple-Mail=_D3579473-32B2-4F52-95F9-7DCF7160452B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aA5lksIi3Lo0-mq5M8E9vKc6cYs Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" Subject: Re: [tcpm] Protocol Action: 'TCP Extensions for High Performance' to Proposed Standard (draft-ietf-tcpm-1323bis-21.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, 16 Apr 2014 12:31:54 -0000 --Apple-Mail=_D3579473-32B2-4F52-95F9-7DCF7160452B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii And thank you Lloyd for all the work you put into getting this done. Lars On 2014-4-16, at 4:42, l.wood@surrey.ac.uk wrote: > And here's a first cut at that TCP Extensions draft, in 1993: > http://www.isocws.isoc.org/inet98/doc/rstevens/tcplw-extensions.txt > > getting this published in only slightly over twenty years is quite > an achievement, given that the transport area is very underresourced > compared to other areas, and short on expertise and manpower. > > (I have a few promising drafts coming along nicely at the six-year mark. > Still time to mature.) > > Congrats! Go team! > > Lloyd Wood > http://about.me/lloydwood > > On 14 Apr 2014, at 23:36, The IESG wrote: > >> The IESG has approved the following document: >> - 'TCP Extensions for High Performance' >> (draft-ietf-tcpm-1323bis-21.txt) as Proposed Standard >> >> This document is the product of the TCP Maintenance and Minor Extensions >> Working Group. >> >> The IESG contact persons are Martin Stiemerling and Spencer Dawkins. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ >> >> >> >> >> >> Technical Summary >> >> This document replaces RFC 1323, making minor fixes and >> clarifications to the original document. The document >> specifies three performance enhancing extensions to TCP, using >> two TCP options. The first is window scale option, that allows >> representation of receive window sizes larger than 2^16 bytes >> originally allowed by the 16-bit window field. The second >> option is TCP timestamps option that allows round-trip time >> measurement on each TCP segment, and third is an algorithm to >> detect and reject old duplicate segments that happen to match >> the current TCP window (Protect Against Wrapped Sequence >> numbers). >> >> >> Working Group Summary >> >> This document has been a chartered TCPM working group item >> since year 2008. It has not been under significant >> controversy, but the progress has been slow because of earlier >> lack of WG (and authoring) cycles. Since adding a new >> co-editor, the progress on the draft became faster in the >> working group. >> >> Document Quality >> >> The predecessor of this document, RFC 1323, was published in >> 1992, and is deployed in most TCP implementations. This >> document includes fixes and clarifications based on the gained >> deployment experience. The recent versions of the document >> have been reviewed and discussed by multiple working group >> participants. >> >> >> Personnel >> >> Document Shepherd is Pasi Sarolahti. >> Reponsible Area Director is Martin Stiemerling. >> >> _______________________________________________ >> 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 --Apple-Mail=_D3579473-32B2-4F52-95F9-7DCF7160452B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU054L9ZcnpRveo1xAQJyZQP/XMLx8CxV49r+8W9B/D/QAlNjaV52lnwh xNZA7wVXY2J9nNuYQjyYwkNF3MBq675P+LL7FMCotdKPhZV7XZI4pgCbiTy8VAlx 8vJIe6XLkO55Y395o65P3q8m+e4IpcOA44/D7ml/wlIQtAvqCeL0SakevD+IUwsT ZflVKNOvXMs= =saeV -----END PGP SIGNATURE----- --Apple-Mail=_D3579473-32B2-4F52-95F9-7DCF7160452B-- From nobody Wed Apr 16 08:03: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 617761A0164 for ; Wed, 16 Apr 2014 08:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U9H7aVVMCXM for ; Wed, 16 Apr 2014 08:02:17 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 99D1C1A01B1 for ; Wed, 16 Apr 2014 08:02:17 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3GF2COE018439 for ; Wed, 16 Apr 2014 11:02:12 -0400 Received: (qmail 28685 invoked by uid 0); 16 Apr 2014 15:02:12 -0000 X-TCPREMOTEIP: 107.47.163.91 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.47.163.91) by 0 with ESMTPA; 16 Apr 2014 15:02:11 -0000 Message-ID: <534E9B6E.4040305@mti-systems.com> Date: Wed, 16 Apr 2014 11:02:06 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk References: <20140414133652.32751.3208.idtracker@ietfa.amsl.com> <2FBD2D0F-C43E-49A6-B950-AA4121ADE677@surrey.ac.uk> In-Reply-To: <2FBD2D0F-C43E-49A6-B950-AA4121ADE677@surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/mn1Dp6VoqI_0wGj4QY5XIidWuK0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Protocol Action: 'TCP Extensions for High Performance' to Proposed Standard (draft-ietf-tcpm-1323bis-21.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, 16 Apr 2014 15:02:31 -0000 On 4/16/2014 7:42 AM, l.wood@surrey.ac.uk wrote: > And here's a first cut at that TCP Extensions draft, in 1993: > http://www.isocws.isoc.org/inet98/doc/rstevens/tcplw-extensions.txt > > getting this published in only slightly over twenty years is quite > an achievement, given that the transport area is very underresourced > compared to other areas, and short on expertise and manpower. > I responded in unicast, but also thought I should say something on the list to make sure the situation is clear ... The current chairs, ADs, and driving editor (Richard) had *nothing to do* with it taking 20 years. In fact, they got it done in about 2 years. That's pretty good for fundamental TCP work, and in fact, there was not a lot of pressure from the people of the world to get it done any sooner than that. Past efforts had run out of steam due to multiple circumstances, and you're free to blame past co-chairs like myself for that, but the current set of folks deserve nothing but sincere thanks. But I feel your pain, as a co-author with you on some of those 6+ year drafts that you mentioned :) ... this WG doesn't have any culpability for those though. -- Wes Eddy MTI Systems From nobody Tue Apr 22 07:51: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 276181A0584 for ; Tue, 22 Apr 2014 07:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgn7Sm57bXYX for ; Tue, 22 Apr 2014 07:51:22 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id AE1A71A0505 for ; Tue, 22 Apr 2014 07:50:08 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3MEnmXO018639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Apr 2014 07:49:51 -0700 (PDT) Message-ID: <53568190.2090409@isi.edu> Date: Tue, 22 Apr 2014 07:49:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> In-Reply-To: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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/icVI9sar-bJwk4npWNlduz2Pvc4 Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 14:51:27 -0000 Hi, all, Wes and I wrote the following to try to put to rest the issue of extending TCP's option space. Although the primary reason was to summarize why the SYN space cannot be extended, it is written as Standards-Track because it includes an extension for non-SYN segments that could still be useful when SACK, TS, and authentication or encryption options are used together. We are seeking this as a TCPM WG doc. Feedback appreciated. Joe and Wes -------- Original Message -------- Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt Date: Fri, 18 Apr 2014 13:30:46 -0700 From: internet-drafts@ietf.org To: Wesley M. Eddy , Dr. Joseph D. Touch , Joe Touch , Wesley Eddy A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-tcp-edo Revision: 00 Title: TCP Extended Data Offset Option Document date: 2014-04-18 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00 Abstract: TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document specifies an optional extension to that space and explains why such extensions (including this) cannot be used in the initial SYN. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Apr 22 15:03:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C61A027C for ; Tue, 22 Apr 2014 15:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, 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 7RNg71OXYMGO for ; Tue, 22 Apr 2014 15:03:16 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D601F1A0278 for ; Tue, 22 Apr 2014 15:03:15 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id h3so254500igd.10 for ; Tue, 22 Apr 2014 15:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=cTNI49kGAErB5k8gad83j1EVf71Pgf8Fjcme2edftG0=; b=V2ApVAV4uYYYhjwzEkxB6oFNzljVTmUKb9Hpmx6f0TqPT+uLw73CzE3u3LoHsNpqkD WBklCwiKqKR3lH1ALl+1P8KNbTz1GQvcuVyusjHPMj+2mkj/7UJbFep3BgjPQpOuCbOZ CbaSExtj9IdrmdDlo00TtI7L7uoh/MnA2mXFMg3pAZUsA58DeLdNu3z0B1kSCpddLbjK uW2s8TNLfut+qW5z+XGzW3idotuDi+0GW/Myhp69JH1rj37p1GX2VelfkE6HwTCMjCv0 9pg+vPboxHpdnKiE1o9JjiUVehagSr9xxlWCWw5S/hEY/Dhe3Esn1NGF7kOkJSDW3d6j 7gIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=cTNI49kGAErB5k8gad83j1EVf71Pgf8Fjcme2edftG0=; b=LIF86Hn3BJbUsvY4VLKJPjaF6Po0O7r82PcrnHvxka4jQ9EJZJbwh/PiiV+O7QXKJ9 WKZfRsruOgEwLJSwG1Rb7AdJaucYoP8CZNDtWs6fw7nvWPSFO3wHPQObuU8DpU/a8bmX SXNetz0ZQZiCZSk7Ace7rLOKqk+bscW+xo4uyVHx3wqIiSLdrWTqMXytFS5ZIFVbP4Xn L85kknF2Mq5aqH97leiA0VG4XaYKORotlqbsobk4fmWw+2TIjzmJ0U00W9PvMUtW+qOl 7EdkxFFQE8/6l6yV8dY3cMjIdgD0aIRkHIykbeGclP1OTMVeGXpWtJbcNclmCNqjwRva VApg== X-Gm-Message-State: ALoCoQlc3W/o+Iz9SSiVWk3nkdab/uxQMdv4FCl6oEFTaHHBVpw/5CaOVBxMBmVPMiLrePT5Emk2er/rpmqqQiqRmSGE0RFIWv+JWzBR/e6pL5A0XuwHYtd7gY0Lohcwjtjpw2MIwYjqYYqid1cu+HEtfFMoEmi3wKNZNU66FwHnuQtLbdaaXP6mXhNRh5NkgYcqwHXU6bQn X-Received: by 10.42.173.68 with SMTP id q4mr38957565icz.41.1398204190166; Tue, 22 Apr 2014 15:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.163 with HTTP; Tue, 22 Apr 2014 15:02:29 -0700 (PDT) In-Reply-To: <201404160110.s3G1A8j5002032@bagheera.jungle.bt.co.uk> References: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D2A2684@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201404160110.s3G1A8j5002032@bagheera.jungle.bt.co.uk> From: Yuchung Cheng Date: Tue, 22 Apr 2014 15:02:29 -0700 Message-ID: To: Bob Briscoe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/AIP_VW_KThyvYTgI_R0xjbj_ksM Cc: "draft-tcpm-fastopen@tools.ietf.org" , tcpm IETF list Subject: Re: [tcpm] draft-tcpm-fastopen: interaction with ECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Apr 2014 22:03:19 -0000 On Tue, Apr 15, 2014 at 6:09 PM, Bob Briscoe wrote: > > Michael, > > It was only advice about what not to cache. I didn't intend it as a sugge= stion for experimentation. And it doesn't have to be normative text (see th= e non-normative suggestion below). > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/= \/\/\/\ > Append new para to end of "4.1.3 Client Cookie Handling" > > "A client is unlikely to find it useful to cache the result of a successf= ul ECN negotiation for a subsequent connection. Attempting to resume a conn= ection with a SYN that is ECN-capable at the IP layer is likely to risk dis= card by security devices, and a consequent timeout. Initializing ECN separa= tely for each connection using the procedure in Section 6.1.1 of [RFC3168] = should introduce no worse risk of delay. > " > > Additional Informative Reference: > > [RFC3168] > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/= \/\/\/\ > > This doesn't warrant holding up the draft now. If the authors want to inc= orporate this para while dealing with RFC Editor comments later, it would b= e up to them. They might not consider it necessary at all, but on balance I= think it would be. I am neutral about adding this part. But if we do edit this part, I'd prefer we explicitly suggest against caching anything other than what's mentioned in the RFC. So that covers ECN bit, sack, timestamp, etc. The fast open cache is supposed to cache information only for fastopen. nothing else. I want to note that the WG did ask about potential ECN interoperability issues (Orlando mtg?). After that meeting I did go over the ECN RFC and didn't find anything obvious. > > > Bob > > > At 18:42 11/04/2014, Scharf, Michael (Michael) wrote: >> >> Bob, >> >> Indeed, the WGLC for draft-tcpm-fastopen has completed... I am about to = forward the document to the AD. >> >> Apparently, right now, draft-tcpm-fastopen does not comment on ECN at al= l, and I am not aware of any past discussion in TCPM. >> >> Thus, my initial thinking would be that if ECN should be addressed in th= is document, it could be mentioned in section 7 as a topic for further expe= rimentation - instead of adding normative text late in the process. >> >> Thoughts from the community (and the authors) would be welcome - but ple= ase recall that we are really past WGLC and I'd like to move the document f= orward within the next couple of days. >> >> Michael >> >> >> >> > -----Original Message----- >> > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe >> > Sent: Thursday, April 10, 2014 6:02 PM >> > To: ycheng@google.com >> > Cc: draft-tcpm-fastopen@tools.ietf.org; tcpm IETF list >> > Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN >> > >> > Yuchung, >> > >> > In draft-tcpm-fastopen, you may be able to get away with saying >> > nothing about this, but.. >> > >> > 1) Just in case someone thinks it would be clever for a TFO client to >> > resume use of ECN on a subsequent SYN, it may be best to clarify that: >> > "TFO does not allow a subsequent connection to reuse the ECN >> > capability negotiated in a previous connection. If TCP endpoints >> > negotiate the use of ECN, they MUST apply the initialization rules >> > (Section 6.1.1 of [RFC3168]) separately for each connection." >> > >> > >> > 2) You might also want to recommend using RFC 5562 (ECN on SYN-ACK), >> > just to give developers a tick-list of RFCs to use. However, if you >> > plan to quickly move TFO on from experimental status, make sure you >> > just say this 'for information', rather than as a normative >> > reference, because 5562 is experimental. >> > >> > >> > >> > I know this is my second comment after WGLC, but I thought it best to >> > say something. (I was just getting the capability negotiation logic >> > in Accurate ECN to interwork with TFO, when I realised this issue >> > applied to classic ECN too.) >> > >> > >> > Bob >> > >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm > > > ________________________________________________________________ > Bob Briscoe, BT From nobody Wed Apr 23 01:23: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 72E031A012E for ; Wed, 23 Apr 2014 01:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 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, RP_MATCHES_RCVD=-0.272, 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 GAV-M8feH-5Q for ; Wed, 23 Apr 2014 01:23:19 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40E1A012C for ; Wed, 23 Apr 2014 01:23:19 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 79BDE278187 for ; Wed, 23 Apr 2014 17:23:12 +0900 (JST) Received: by mail-qa0-f45.google.com with SMTP id cm18so549322qab.32 for ; Wed, 23 Apr 2014 01:23:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.30.131 with SMTP id u3mr55395207qac.50.1398241390644; Wed, 23 Apr 2014 01:23:10 -0700 (PDT) Received: by 10.96.159.234 with HTTP; Wed, 23 Apr 2014 01:23:10 -0700 (PDT) In-Reply-To: <53568190.2090409@isi.edu> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> Date: Wed, 23 Apr 2014 01:23:10 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bdc90a0666f4204f7b17139 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nR3J8kkSI_7GoeEUMhzq7stClv0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 08:23:23 -0000 --047d7bdc90a0666f4204f7b17139 Content-Type: text/plain; charset=UTF-8 Hi Joe, Wes, Thanks for the draft. Yes, extending TCP's options space is an important topic for tcp and has been discussed for long time. It would be great if we can find once-and-for-all solution for it. I think the draft seems to address the problems identified through the previous approach, however, I still have concern on it. One difficulty for extending options space is that middleboxes might re-segments packets or discard options. In case of other options like timestamp, SACK, this might not be a fatal issue. However, in case of this, the result will be catastrophic. So, I'm thinking that this approach might need some mechanisms that can check whether the segument is re-segmented or not. This could be done internally or externally by combining other features (AO or tcpcrypt, etc). Please let me know if you have opinions on this or if I miss something. Thanks, -- Yoshi On Tue, Apr 22, 2014 at 7:49 AM, Joe Touch wrote: > Hi, all, > > Wes and I wrote the following to try to put to rest the issue of extending > TCP's option space. Although the primary reason was to summarize why the > SYN space cannot be extended, it is written as Standards-Track because it > includes an extension for non-SYN segments that could still be useful when > SACK, TS, and authentication or encryption options are used together. > > We are seeking this as a TCPM WG doc. Feedback appreciated. > > Joe and Wes > > -------- Original Message -------- > Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt > Date: Fri, 18 Apr 2014 13:30:46 -0700 > From: internet-drafts@ietf.org > To: Wesley M. Eddy , Dr. Joseph D. Touch < > touch@isi.edu>, Joe Touch , Wesley Eddy < > wes@mti-systems.com> > > > A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tcpm-tcp-edo > Revision: 00 > Title: TCP Extended Data Offset Option > Document date: 2014-04-18 > Group: Individual Submission > Pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ > Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00 > > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options, but the size of the field can limit the space available for > complex options that have evolved. This document specifies an > optional extension to that space and explains why such extensions > (including this) cannot be used in the initial SYN. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --047d7bdc90a0666f4204f7b17139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe, Wes,

Thanks for the draft. Yes,= extending TCP's options space is an important topic for tcp and has be= en discussed for long time. It would be great if we can find once-and-for-a= ll solution for it.
I think the draft seems to address the problems identified through the= previous approach, however, I still have concern on it.

One difficulty for extending options space is that middleboxes might= re-segments packets or discard options. In case of other options like time= stamp, SACK, this might not be a fatal issue. However, in case of this, the= result will be catastrophic.
So, I'm thinking that this approach might need some mechanisms tha= t can check whether the segument is re-segmented or not. This could be done= internally or externally by combining other features (AO or tcpcrypt, etc)= .
Please let me know if you have opinions on this or if I miss something= .

Thanks,
--
Yoshi


On Tue, Apr 22, 2014 = at 7:49 AM, Joe Touch <touch@isi.edu> wrote:
Hi, all,

Wes and I wrote the following to try to put to rest the issue of extending = TCP's option space. Although the primary reason was to summarize why th= e SYN space cannot be extended, it is written as Standards-Track because it= includes an extension for non-SYN segments that could still be useful when= SACK, TS, and authentication or encryption options are used together.

We are seeking this as a TCPM WG doc. Feedback appreciated.

Joe and Wes

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.tx= t
Date: Fri, 18 Apr 2014 13:30:46 -0700
From: interne= t-drafts@ietf.org
To: Wesley M. Eddy <wes@mti-systems.com>, =C2=A0 =C2=A0 =C2=A0 =C2=A0Dr. Joseph D. = Touch <touch@isi.edu<= /a>>, Joe Touch <t= ouch@isi.edu>, =C2=A0 =C2=A0 =C2=A0 =C2=A0Wesley Eddy <wes@mti-systems.com><= br>

A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-touch-tcpm-tcp-edo
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TCP Extended Data Offset Option Document date: =C2=A02014-04-18
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
URL: http://www.ietf.org/internet-drafts/draf= t-touch-tcpm-tcp-edo-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.= org/doc/draft-touch-tcpm-tcp-edo/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/= draft-touch-tcpm-tcp-edo-00


Abstract:
=C2=A0 =C2=A0TCP segments include a Data Offset field to indicate space for= TCP
=C2=A0 =C2=A0options, but the size of the field can limit the space availab= le for
=C2=A0 =C2=A0complex options that have evolved. This document specifies an<= br> =C2=A0 =C2=A0optional extension to that space and explains why such extensi= ons
=C2=A0 =C2=A0(including this) cannot be used in the initial SYN.





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

The IETF Secretariat


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

--047d7bdc90a0666f4204f7b17139-- From nobody Wed Apr 23 02:43: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 ABBEE1A016B for ; Wed, 23 Apr 2014 02:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 0JBgi0__XX8q for ; Wed, 23 Apr 2014 02:43:31 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4A1A0158 for ; Wed, 23 Apr 2014 02:43:31 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s3N9hK7F002398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 04:43:22 -0500 (CDT) 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 s3N9hKBr017005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Apr 2014 11:43:20 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 23 Apr 2014 11:43:20 +0200 From: "Scharf, Michael (Michael)" To: Yuchung Cheng , Bob Briscoe Thread-Topic: [tcpm] draft-tcpm-fastopen: interaction with ECN Thread-Index: AQHPVNZJKcdbbfIVAEGt+UXS/0V9V5sMq2nwgAbM7H2ACqmSgIAA4ZfQ Date: Wed, 23 Apr 2014 09:43:19 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2C0A34@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D2A2684@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201404160110.s3G1A8j5002032@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.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SilpJ4OFXXDKiy3aoJ7bwNRdR8w Cc: tcpm IETF list Subject: Re: [tcpm] draft-tcpm-fastopen: interaction with ECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Apr 2014 09:43:35 -0000 PiA+IEFwcGVuZCBuZXcgcGFyYSB0byBlbmQgb2YgIjQuMS4zIENsaWVudCBDb29raWUgSGFuZGxp bmciDQo+ID4NCj4gPiAiQSBjbGllbnQgaXMgdW5saWtlbHkgdG8gZmluZCBpdCB1c2VmdWwgdG8g Y2FjaGUgdGhlIHJlc3VsdCBvZiBhDQo+IHN1Y2Nlc3NmdWwgRUNOIG5lZ290aWF0aW9uIGZvciBh IHN1YnNlcXVlbnQgY29ubmVjdGlvbi4gQXR0ZW1wdGluZyB0bw0KPiByZXN1bWUgYSBjb25uZWN0 aW9uIHdpdGggYSBTWU4gdGhhdCBpcyBFQ04tY2FwYWJsZSBhdCB0aGUgSVAgbGF5ZXIgaXMNCj4g bGlrZWx5IHRvIHJpc2sgZGlzY2FyZCBieSBzZWN1cml0eSBkZXZpY2VzLCBhbmQgYSBjb25zZXF1 ZW50IHRpbWVvdXQuDQo+IEluaXRpYWxpemluZyBFQ04gc2VwYXJhdGVseSBmb3IgZWFjaCBjb25u ZWN0aW9uIHVzaW5nIHRoZSBwcm9jZWR1cmUgaW4NCj4gU2VjdGlvbiA2LjEuMSBvZiBbUkZDMzE2 OF0gc2hvdWxkIGludHJvZHVjZSBubyB3b3JzZSByaXNrIG9mIGRlbGF5Lg0KPiA+ICINCj4gPg0K PiA+IEFkZGl0aW9uYWwgSW5mb3JtYXRpdmUgUmVmZXJlbmNlOg0KPiA+DQo+ID4gW1JGQzMxNjhd DQo+ID4NCj4gL1wvXC9cL1wvXC9cL1wvXC9cL1wvXC9cL1wvXC9cL1wvXC9cL1wvXC9cL1wvXC9c L1wvXC9cL1wvXC9cL1wvXC9cL1wvXC8NCj4gXC9cL1wvXC9cDQo+ID4NCj4gPiBUaGlzIGRvZXNu J3Qgd2FycmFudCBob2xkaW5nIHVwIHRoZSBkcmFmdCBub3cuIElmIHRoZSBhdXRob3JzIHdhbnQg dG8NCj4gaW5jb3Jwb3JhdGUgdGhpcyBwYXJhIHdoaWxlIGRlYWxpbmcgd2l0aCBSRkMgRWRpdG9y IGNvbW1lbnRzIGxhdGVyLCBpdA0KPiB3b3VsZCBiZSB1cCB0byB0aGVtLiBUaGV5IG1pZ2h0IG5v dCBjb25zaWRlciBpdCBuZWNlc3NhcnkgYXQgYWxsLCBidXQNCj4gb24gYmFsYW5jZSBJIHRoaW5r IGl0IHdvdWxkIGJlLg0KPiANCj4gSSBhbSBuZXV0cmFsIGFib3V0IGFkZGluZyB0aGlzIHBhcnQu IEJ1dCBpZiB3ZSBkbyBlZGl0IHRoaXMgcGFydCwgSSdkDQo+IHByZWZlciB3ZSBleHBsaWNpdGx5 IHN1Z2dlc3QgYWdhaW5zdCBjYWNoaW5nIGFueXRoaW5nIG90aGVyIHRoYW4NCj4gd2hhdCdzIG1l bnRpb25lZCBpbiB0aGUgUkZDLiBTbyB0aGF0IGNvdmVycyBFQ04gYml0LCBzYWNrLCB0aW1lc3Rh bXAsDQo+IGV0Yy4gVGhlIGZhc3Qgb3BlbiBjYWNoZSBpcyBzdXBwb3NlZCB0byBjYWNoZSBpbmZv cm1hdGlvbiBvbmx5IGZvcg0KPiBmYXN0b3Blbi4gbm90aGluZyBlbHNlLg0KDQpBcyBpbmRpdmlk dWFsIGNvbnRyaWJ1dG9yIHRvIFRDUE0sIHRoaXMgcHJvcG9zYWwgc291bmRzIGxpa2UgYSBnb29k IGlkZWEgdG8gbWUgLSBJIHRoaW5rIHRoaXMgaXMgYWxyZWFkeSBpbXBsaWVkIGJ5IHRoZSBkcmFm dCwgYnV0IGlmIHRoZSBjdXJyZW50IHRleHQgc2hvdWxkIG5vdCBiZSBjbGVhciBlbm91Z2gsIGl0 IGNvdWxkIHBlcmhhcHMgYmUgc3RhdGVkIGV4cGxpY2l0bHkuDQoNCkFzIGRvY3VtZW50IHNoZXBo ZXJkLCBJJ2xsIG1vdmUgdGhpcyBkb2N1bWVudCBmb3J3YXJkIHRvIHRoZSBBRCBieSBlbmQgb2Yg dGhpcyB3ZWVrLiBJZiBhbnlib2R5IGhhcyB0aG91Z2h0cyBvbiBzdWNoIGEgcG9zdC1wb3N0LVdH TEMgY2hhbmdlLCBwbGVhc2Ugc3BlYWsgdXAgKm5vdyouIEluIHBhcnRpY3VsYXIsIEknZCByZWFs bHkgYmUgaW50ZXJlc3RlZCBpbiBleHBsaWNpdCBzdXBwb3J0IGZvciBhbnkgY2hhbmdlIG9mIHRo ZSBkb2N1bWVudCwgZ2l2ZW4gdGhhdCB0aGUgZHJhZnQgaGFzIGJlZW4gb3V0IGZvciBzdWNoIGEg bG9uZyB0aW1lIGFscmVhZHkuDQoNCk1pY2hhZWwNCg0K From nobody Wed Apr 23 06:07:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECD21A0377 for ; Wed, 23 Apr 2014 06:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 tZlf3FidL46I for ; Wed, 23 Apr 2014 06:07:34 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 577381A0392 for ; Wed, 23 Apr 2014 06:07:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,912,1389772800"; d="scan'208";a="118807198" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 23 Apr 2014 06:07:27 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 06:07:27 -0700 From: "Scheffenegger, Richard" To: Joe Touch , Wesley Eddy Thread-Topic: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt Thread-Index: AQHPXjpYSgC1BEAgbE2P9+XyoClhH5sfI+tQ Date: Wed, 23 Apr 2014 13:07:26 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A33CAEA@SACEXCMBX02-PRD.hq.netapp.com> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> In-Reply-To: <53568190.2090409@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] 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/nEvKKbEQmt_u8vTSoNKZmPgv418 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:07:37 -0000 Hi Joe, Wes, thanks for summing up these important points in one draft. Some minor (some pedantic) points: Sec 4, 3rd para: "the six reserved TCP header bits"... After RFC3168 (ECE / CWR) and RFC3540 (NS), there are only 3 bits left. [Ac= cECN would reuse these same three bits, hopefully] Same para: legacy endpoints are not required to drop packets, just ignore t= hese bits, or am I mistaken? At least the ignore=20 Further, during SYN (unless this is a SYN,URG packet), there are in fact tw= o fields (Acknowledgment Number, Urgent Pointer) that are unused; however, = these fields are not useable on the SYN,ACK, or when the URG flag is set (b= ut that use is discouraged). [AccECN would make opportunistic use of the pr= obably available URG Pointer field, to improve resiliency] Section 5: The text seems to imply that EDO overrides DataOffset, thus EDO should take= precedence when processing. (This is mentioned in sec 6.3) However, I would like more specific text on that interaction, and what shou= ld be done with DataOffset. Is DataOffset to be set to some currently invalid value (i.e. 0..4)? Or alw= ays to the maximum (15)? Or to a bounded maximum: min(15, ceil(edo/4)) (It seem to be implied in sec 6.3, that the bounded maximum variant is to b= e used...) Section 6.2: The most prevalent option, MSS, has been omitted from that lis= t. (also, MSS is often inserted early in the list of options, by intermedia= te devices independent of the end hosts). Section 7: Stateful inspecting firewalls seem to be missing here; if that D= PI box doesn't understand EDO, it would reassemble the stream incorrectly f= or inspection. That could lead to an bypass of that fence, or the failure o= f a stream in mid-session. Section 8 seems to have 3 partial sentences... Best regards, Richard Scheffenegger ################################################################## # To any security service agents reading my email: # # Please consider if any professional body code of conduct to # # which you subscribe requires you to follow Snowden's example. #=20 # Your professional membership, chartered or incorporated status # # may be at risk. # ################################################################## =20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Dienstag, 22. April 2014 16:50 > To: tcpm@ietf.org > Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp- > edo-00.txt >=20 > Hi, all, >=20 > Wes and I wrote the following to try to put to rest the issue of extendin= g > TCP's option space. Although the primary reason was to summarize why the > SYN space cannot be extended, it is written as Standards-Track because it > includes an extension for non-SYN segments that could still be useful whe= n > SACK, TS, and authentication or encryption options are used together. >=20 > We are seeking this as a TCPM WG doc. Feedback appreciated. >=20 > Joe and Wes >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt > Date: Fri, 18 Apr 2014 13:30:46 -0700 > From: internet-drafts@ietf.org > To: Wesley M. Eddy , Dr. Joseph D. Touch > , Joe Touch , Wesley Eddy > >=20 >=20 > A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt has been > successfully submitted by Joe Touch and posted to the IETF repository. >=20 > Name: draft-touch-tcpm-tcp-edo > Revision: 00 > Title: TCP Extended Data Offset Option > Document date: 2014-04-18 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo= / > Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00 >=20 >=20 > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options, but the size of the field can limit the space available for > complex options that have evolved. This document specifies an > optional extension to that space and explains why such extensions > (including this) cannot be used in the initial SYN. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 23 06:33: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 B0A4A1A03A7 for ; Wed, 23 Apr 2014 06:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 tathT5AKKTHr for ; Wed, 23 Apr 2014 06:33:48 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id D17451A0362 for ; Wed, 23 Apr 2014 06:33:47 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 23 Apr 2014 14:33:39 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 23 Apr 2014 14:33:38 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Wed, 23 Apr 2014 14:33:37 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.229.177]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s3NDXXtZ012337; Wed, 23 Apr 2014 14:33:34 +0100 Message-ID: <201404231333.s3NDXXtZ012337@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Apr 2014 14:33:32 +0100 To: Yuchung Cheng From: Bob Briscoe In-Reply-To: References: <201404101602.s3AG28nH001717@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D2A2684@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201404160110.s3G1A8j5002032@bagheera.jungle.bt.co.uk> 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/-zXDPLfXsa-LVHD2B--yeg_QChQ Cc: "draft-tcpm-fastopen@tools.ietf.org" , tcpm IETF list Subject: Re: [tcpm] draft-tcpm-fastopen: interaction with ECN X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Apr 2014 13:33:51 -0000 Yuchung, Thx. I hadn't realised you had already checked for ECN interactions. I do not agree with saying no-one should cache anything other than what's mentioned in the RFC. For example, at one stage we (me, Mirja, Richard ?) were proposing that the timestamp on the SYN could be used to negotiate timestamp precision (and other stuff I can't recall at the moment). If caching a particular item of negotiated connection state X will save negotiation delay, and a SYN on a resumed TFO connection can re-declare X rather than re-negotiating it, then a valid TFO cookie would save negotiation delay in a case where X would be useful on the SYN but would normally have to wait for the next round. Note: even tho the cookie wouldn't need to contain X itself, a valid cookie would prove that this client had talked to the server before, which may be sufficient proof. If we are going to say "don't cache anything else", I suggest we say "SHOULD NOT cache anything else" and say why. Then for cases where the reasons don't apply, we are not stopping people being innovative. Possible reasons against caching are case-dependent: * SACK: Negotiation adds no delay because SACK on SYN is irrelevant. * Window scale: Could save negotiation delay by allowing window scaling from the previous session to be meaningful on both SYNs (with data). * Timestamp: Adds no delay because TS should be on the SYN anyway. * ECN: An ECT SYN is likely to be discarded by security boxes. * etc etc. * In all cases, the client may communicate with a different replica of the server that does not have the same config as the original server. However, for some features this might be very unlikely. Apologies that this reply is a bit vague. I'm on holiday, but I didn't want to hold up this draft going to the IESG. Bob At 23:02 22/04/2014, Yuchung Cheng wrote: >On Tue, Apr 15, 2014 at 6:09 PM, Bob Briscoe wrote: > > > > Michael, > > > > It was only advice about what not to cache. I didn't intend it as > a suggestion for experimentation. And it doesn't have to be > normative text (see the non-normative suggestion below). > > > > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > Append new para to end of "4.1.3 Client Cookie Handling" > > > > "A client is unlikely to find it useful to cache the result of a > successful ECN negotiation for a subsequent connection. Attempting > to resume a connection with a SYN that is ECN-capable at the IP > layer is likely to risk discard by security devices, and a > consequent timeout. Initializing ECN separately for each connection > using the procedure in Section 6.1.1 of [RFC3168] should introduce > no worse risk of delay. > > " > > > > Additional Informative Reference: > > > > [RFC3168] > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > > This doesn't warrant holding up the draft now. If the authors > want to incorporate this para while dealing with RFC Editor > comments later, it would be up to them. They might not consider it > necessary at all, but on balance I think it would be. > >I am neutral about adding this part. But if we do edit this part, I'd >prefer we explicitly suggest against caching anything other than >what's mentioned in the RFC. So that covers ECN bit, sack, timestamp, >etc. The fast open cache is supposed to cache information only for >fastopen. nothing else. > >I want to note that the WG did ask about potential ECN >interoperability issues (Orlando mtg?). After that meeting I did go >over the ECN RFC and didn't find anything obvious. > > > > > > > > Bob > > > > > > At 18:42 11/04/2014, Scharf, Michael (Michael) wrote: > >> > >> Bob, > >> > >> Indeed, the WGLC for draft-tcpm-fastopen has completed... I am > about to forward the document to the AD. > >> > >> Apparently, right now, draft-tcpm-fastopen does not comment on > ECN at all, and I am not aware of any past discussion in TCPM. > >> > >> Thus, my initial thinking would be that if ECN should be > addressed in this document, it could be mentioned in section 7 as a > topic for further experimentation - instead of adding normative > text late in the process. > >> > >> Thoughts from the community (and the authors) would be welcome - > but please recall that we are really past WGLC and I'd like to move > the document forward within the next couple of days. > >> > >> Michael > >> > >> > >> > >> > -----Original Message----- > >> > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe > >> > Sent: Thursday, April 10, 2014 6:02 PM > >> > To: ycheng@google.com > >> > Cc: draft-tcpm-fastopen@tools.ietf.org; tcpm IETF list > >> > Subject: [tcpm] draft-tcpm-fastopen: interaction with ECN > >> > > >> > Yuchung, > >> > > >> > In draft-tcpm-fastopen, you may be able to get away with saying > >> > nothing about this, but.. > >> > > >> > 1) Just in case someone thinks it would be clever for a TFO client to > >> > resume use of ECN on a subsequent SYN, it may be best to clarify that: > >> > "TFO does not allow a subsequent connection to reuse the ECN > >> > capability negotiated in a previous connection. If TCP endpoints > >> > negotiate the use of ECN, they MUST apply the initialization rules > >> > (Section 6.1.1 of [RFC3168]) separately for each connection." > >> > > >> > > >> > 2) You might also want to recommend using RFC 5562 (ECN on SYN-ACK), > >> > just to give developers a tick-list of RFCs to use. However, if you > >> > plan to quickly move TFO on from experimental status, make sure you > >> > just say this 'for information', rather than as a normative > >> > reference, because 5562 is experimental. > >> > > >> > > >> > > >> > I know this is my second comment after WGLC, but I thought it best to > >> > say something. (I was just getting the capability negotiation logic > >> > in Accurate ECN to interwork with TFO, when I realised this issue > >> > applied to classic ECN too.) > >> > > >> > > >> > Bob > >> > > >> > > >> > ________________________________________________________________ > >> > Bob Briscoe, BT > >> > > >> > _______________________________________________ > >> > tcpm mailing list > >> > tcpm@ietf.org > >> > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > ________________________________________________________________ > > Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From nobody Wed Apr 23 07:13: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 7B7581A03C5 for ; Wed, 23 Apr 2014 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCZb8Db-P4Me for ; Wed, 23 Apr 2014 07:13:30 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BBCD21A03B3 for ; Wed, 23 Apr 2014 07:13:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0BEC4C94BD; Wed, 23 Apr 2014 10:13:22 -0400 (EDT) Date: Wed, 23 Apr 2014 10:13:22 -0400 From: John Leslie To: Yoshifumi Nishida Message-ID: <20140423141322.GF86778@verdi> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YOhqtmaMIkG-tlFV7vZvrHrtE_M Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:13:32 -0000 Yoshifumi Nishida wrote: > > I think the draft seems to address the problems identified through the > previous approach, however, I still have concern on it. I strongly support this work. > One difficulty for extending options space is that middleboxes might > re-segments packets or discard options. In case of other options like > timestamp, SACK, this might not be a fatal issue. However, in case of > this, the result will be catastrophic. We will have to discuss middlebox damage; but I believe it can be detected: thus I suggest we adopt the document, warts and all, rather than try to fix middlebox damage before adopting it. > So, I'm thinking that this approach might need some mechanisms that > can check whether the segument is re-segmented or not. This could be > done internally or externally by combining other features (AO or > tcpcrypt, etc). I _really_ don't want to go into "combining other features" at this point... > Please let me know if you have opinions on this or if I miss something. I have some concerns of my own; but I see no reason to raise them before WG adoption. -- John Leslie From nobody Wed Apr 23 08:15: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 AE53A1A039B for ; Wed, 23 Apr 2014 08:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_bSk76tD4li for ; Wed, 23 Apr 2014 08:15:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A9BB91A03C0 for ; Wed, 23 Apr 2014 08:14:55 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3NFDiJf019919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 08:13:57 -0700 (PDT) Message-ID: <5357D8AD.4030608@isi.edu> Date: Wed, 23 Apr 2014 08:13:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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/2toL5TOW8zbsFgReN4m62Kc9UrY Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:15:05 -0000 On 4/23/2014 1:23 AM, Yoshifumi Nishida wrote: > Hi Joe, Wes, > > Thanks for the draft. Yes, extending TCP's options space is an important > topic for tcp and has been discussed for long time. It would be great if > we can find once-and-for-all solution for it. > I think the draft seems to address the problems identified through the > previous approach, however, I still have concern on it. > > One difficulty for extending options space is that middleboxes might > re-segments packets or discard options. In case of other options like > timestamp, SACK, this might not be a fatal issue. However, in case of > this, the result will be catastrophic. Discarding options is always dangerous. There's no good way to detect this other than to require that, once enabled, the option MUST appear in all subsequent segments. But that alone doesn't ensure it's been followed - resegmentation could still copy the visible options and move the data around, and you wouldn't know. > So, I'm thinking that this approach might need some mechanisms that can > check whether the segument is re-segmented or not. This could be done > internally or externally by combining other features (AO or tcpcrypt, etc). > Please let me know if you have opinions on this or if I miss something. You can surely detect whether a middlebox has done something that might impact this option by using any sort of integrity protection. That's useful to mention, but I don't think it's either necessary or useful to *require* it. Joe From nobody Wed Apr 23 08:48: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 B5B691A00CB for ; Wed, 23 Apr 2014 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoA60MbPN0A0 for ; Wed, 23 Apr 2014 08:48:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E978C1A0016 for ; Wed, 23 Apr 2014 08:48:46 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3NFlg1D029934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 08:47:53 -0700 (PDT) Message-ID: <5357E0A4.5080800@isi.edu> Date: Wed, 23 Apr 2014 08:47:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" , Wesley Eddy References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F4A33CAEA@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F4A33CAEA@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/DrKsda4TFlxbZIyQ6WmWNtJM5WI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:48:48 -0000 On 4/23/2014 6:07 AM, Scheffenegger, Richard wrote: > Hi Joe, Wes, > > thanks for summing up these important points in one draft. > > > > Some minor (some pedantic) points: > > > Sec 4, 3rd para: "the six reserved TCP header bits"... > > After RFC3168 (ECE / CWR) and RFC3540 (NS), there are only 3 bits left. [AccECN would reuse these same three bits, hopefully] Thanks - I will fix that. > Same para: legacy endpoints are not required to drop packets, just ignore these bits, or am I mistaken? At least the ignore RFC793 is very specific: Reserved: 6 bits Reserved for future use. Must be zero. It doesn't say "must be set to zero until defined, and must be ignored at the receiver until defined". A compliant receiver should check these bits and drop if not zero. If community consensus is that this is not how the text should be interpreted, then that needs to be fixed in an errata (it hasn't), and corrected in the 793 update. (yes, this is in conflict with the redefinition of those bits). It's easy to note that using those bits to extend the option space isn't particularly useful, because there's not enough bits left to make a dent (the 4 bits might save a total of 8 bytes for 'flag' options, but can't add more space). I will correct that discussion in our draft. > Further, during SYN (unless this is a SYN,URG packet), there are in > fact two fields (Acknowledgment Number, Urgent Pointer) that are unused; > however, these fields are not useable on the SYN,ACK, or when the URG > flag is set (but that use is discouraged). [AccECN would make > opportunistic use of the probably available URG Pointer field, to > improve resiliency] Other controls or processing in the SYN are supposed to be queued for processing after the connection is established. We can't use URG unless the URG bit is cleared; even though its use is discouraged, it's still possible, which means that field isn't available. You're right about the ACK field; the ACK bit cannot be set, so that field would be available. I'll update the text accordingly. > Section 5: > > The text seems to imply that EDO overrides DataOffset, thus EDO > should take precedence when processing. (This is mentioned in sec > 6.3) It does only when present in a segment. To find the option, you need to look at the existing Data Offset to process the options first - only when you see EDO can you look further. That's why, in Section 8: >> When the EDO length option is present, the EDO length option SHOULD be the last non-null option covered by the TCP Data Offset, because it would be. > However, I would like more specific text on that interaction, and what should be done with DataOffset. It would be useful to put that text earlier, in Sec 5. > Is DataOffset to be set to some currently invalid value (i.e. 0..4)? > Or always to the maximum (15)? Or to a bounded maximum: min(15, ceil(edo/4)) > > (It seem to be implied in sec 6.3, that the bounded maximum variant is to be used...) Again, this would be useful to describe in total in Sec 5, but the summary of the rule is the one above in Sec 8 and the following in Sec 5: >> Because it overrides an existing TCP header field when present, the EDO length option MUST occur within the length of the TCP Data Offset. The EDO length option SHOULD occur as early as possible, either first or just after any authentication or encryption. I.e., if there's no authentication/encryption, DO would be 6 (to accommodate the EDO option itself). If there is auth/enc, DO would be (A-E wordlength + 6). It's worth going through those cases to explain. Again, as noted, the idea is that DO works like it does now, just that *once you reach the EDO option* it overrides DO. DO isn't overridden on every segment. > Section 6.2: The most prevalent option, MSS, has been omitted from > that list. (also, MSS is often inserted early in the list of options, by > intermediate devices independent of the end hosts). It's worth adding. Devices that insert MSS wouldn't be a problem (except in violating the basic E2E principle in general); in fact, using EDO ensures there's space for that addition. > Section 7: Stateful inspecting firewalls seem to be missing here; if > that DPI box doesn't understand EDO, it would reassemble the stream > incorrectly for inspection. That could lead to an bypass of that fence, > or the failure of a stream in mid-session. Good point, and worth adding. The only way to support these sort of devices would have been to put the additional options *after* the TCP data, rather than before - i.e., where the IP length would disagree with the TCP length. That seems like it opens more cans of worms, though, in terms of undetectable interactions (the options wouldn't be covered by the checksum, etc.) > Section 8 seems to have 3 partial sentences... Yeah, not enough coffee during that draft. I'll fix that. Joe From nobody Wed Apr 23 10:58:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F441A047B for ; Wed, 23 Apr 2014 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, 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 WVnuvwIEVA8m for ; Wed, 23 Apr 2014 10:58:20 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 022961A047A for ; Wed, 23 Apr 2014 10:58:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,913,1389772800"; d="scan'208";a="118890249" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 23 Apr 2014 10:58:14 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.105]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 23 Apr 2014 10:58:13 -0700 From: "Scheffenegger, Richard" To: Joe Touch , Wesley Eddy Thread-Topic: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt Thread-Index: AQHPXwuD+hWhNFRu20azfOmpF50eRZsfdIbA Date: Wed, 23 Apr 2014 17:58:13 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F4A33E873@SACEXCMBX02-PRD.hq.netapp.com> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F4A33CAEA@SACEXCMBX02-PRD.hq.netapp.com> <5357E0A4.5080800@isi.edu> In-Reply-To: <5357E0A4.5080800@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.19] 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/dl6WsqQVpSOpjudmMWEBTTHzJv0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:58:21 -0000 Hi Joe, > > Sec 4, 3rd para: "the six reserved TCP header bits"... > > > > After RFC3168 (ECE / CWR) and RFC3540 (NS), there are only 3 bits > > left. [AccECN would reuse these same three bits, hopefully] >=20 > Thanks - I will fix that. >=20 > > Same para: legacy endpoints are not required to drop packets, just > > ignore these bits, or am I mistaken? At least the ignore >=20 > RFC793 is very specific: >=20 > Reserved: 6 bits >=20 > Reserved for future use. Must be zero. >=20 > It doesn't say "must be set to zero until defined, and must be ignored at > the receiver until defined". > > A compliant receiver should check these bits and drop if not zero. Well, 793 states (2.10): be conservative in what you do, be liberal=20 in what you accept from others. Factually, most TCP stacks have interpreted this pre-2119 "must"=20 equivalent to an RFC2119 "SHOULD". But lets leave out that tangent; I just wanted to point out that some Additional bits have been defined, and > It's easy to note that using those bits to extend the option space isn't > particularly useful, because there's not enough bits left to make a dent > (the 4 bits might save a total of 8 bytes for 'flag' options, but can't > add more space). I will correct that discussion in our draft. That is absolutely the case! > If community consensus is that this is not how the text should be > interpreted, then that needs to be fixed in an errata (it hasn't), and > corrected in the 793 update. >=20 > (yes, this is in conflict with the redefinition of those bits). I just submitted an errata; Wes, when you continue on 793bis and do the=20 2119 wording overhaul, you probably want to check these instances where there is a "must" in 793, that is probably more a SHOULD nowadays.=20 (Acknowledgment Number and Urgent Pointer do lack a "SHOULD be zero" too). > > However, I would like more specific text on that interaction, and what > should be done with DataOffset. >=20 > It would be useful to put that text earlier, in Sec 5. >=20 > > Is DataOffset to be set to some currently invalid value (i.e. 0..4)? > > Or always to the maximum (15)? Or to a bounded maximum: min(15, > > ceil(edo/4)) > > > > (It seem to be implied in sec 6.3, that the bounded maximum variant is > > to be used...) >=20 > Again, this would be useful to describe in total in Sec 5, but the summar= y > of the rule is the one above in Sec 8 and the following in Sec 5: >=20 > >> Because it overrides an existing TCP header field when present, > the EDO length option MUST occur within the length of the TCP Data > Offset. The EDO length option SHOULD occur as early as possible, > either first or just after any authentication or encryption. This wording would allow a variant like this: Data Offset =3D 6; 24 < EDO (#1) <=3D 60 < EDO (#2) <=3D MSS #1 - discouraged, but valid #2 - EDO adds value If one chooses to implement EDO with small (DataOffset would suffice) option spaces for some reason, it appears more sane to have both EDO and Da= taOffset indicate the same length, or DataOffset set to its maximum... If these two disagree (EDO < DataOffset || (DataOffset < 15 && DataOffset <= EDO)) It should be regarded as a peculiar / or even invalid combination... > Again, as noted, the idea is that DO works like it does now, just that > *once you reach the EDO option* it overrides DO. DO isn't overridden on > every segment. Understand; just the corner cases should be defined (IMHO, having EDO when = you actually need the space, makes sense, thus DO should be at maximum, whe= n EDO is present; if DO is between 5 and 15, having EDO indicating a simila= r size (excluding NOP / EOL perhaps, thus EDO <=3D DO) would be valid, but = I'm not sure if DO=3D6, EDO=3D60 is a sensible combination... > The only way to support these sort of devices would have been to put the > additional options *after* the TCP data, rather than before - i.e., where > the IP length would disagree with the TCP length. >=20 > That seems like it opens more cans of worms, though, in terms of > undetectable interactions (the options wouldn't be covered by the > checksum, etc.) Well, on a pure SYN, you could logically append the ACK Number at the end o= f the option space; that would yield a net increase of 2 bytes to the SYN o= ption space, when EDO=3Denable is present. But I doubt that it would be wor= thwhile to special-case the SYN here - or would we gain something by going = from 40 to 42 bytes option space in a SYN? Besides, having data past the IP length would probably (and rightfully so) = get truncated with most routers. I wouldn't want to see us go there... =20 Best regards, Richard From nobody Fri Apr 25 08:01: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 4C54C1A04AF for ; Fri, 25 Apr 2014 08:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 R332nUr4ylvq for ; Fri, 25 Apr 2014 08:00:52 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4AC1A0522 for ; Fri, 25 Apr 2014 08:00:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,927,1389772800"; d="asc'?scan'208";a="119348518" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 25 Apr 2014 08:00:37 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 08:00:36 -0700 From: "Zimmermann, Alexander" To: Joe Touch , Wesley Eddy Thread-Topic: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt Thread-Index: AQHPYJccNXMoA51F1Emwf+TBXLBX8g== Date: Fri, 25 Apr 2014 15:00:35 +0000 Message-ID: <0EA7EF6A-26A6-48D2-B6BF-CCCEF494F815@netapp.com> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> In-Reply-To: <53568190.2090409@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.19] Content-Type: multipart/signed; boundary="Apple-Mail=_D3EF170E-FFB9-4EB9-AAFC-8038F014E33A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0hnR8PhtNg5tLkTtNEzoCjRPLf8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:00:56 -0000 --Apple-Mail=_D3EF170E-FFB9-4EB9-AAFC-8038F014E33A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Joe, Wes, thank you for this work. I also strongly support this work/doc. Some comments * Sec 1: - Please add a reference to RFC 793. - Please add one or two examples of common option combinations where = we have a problem, e.g. TCP TS, SACK, and Multipath TCP * Sec 2: - =84A SYN may include user data =85=93 Please add a reference to RFC = 793/TFO * Sec 4: - Should we mention =84draft-paasch-mptcp-control-stream=93 here? - =84The six reserved =85 to be ignored=93 =97> maybe we can required = this in RFC793bis ;-) - While it may be not possible to extend the option in a SYN, it=92s = possible to reduce the space needed, e.g. late negotiation. Maybe we can add some text here.=20 * Sec 5: - =84For initial SYN segments (i.e., those whose ACK bit is not = set)=93. IMO a SYN is a segment where the SYN bit is set. - The explanation of the EDO option is in a different order than the = figures. Please explain first figure 1 and then 2 (or swap the figures) - =84An endpoint confirming EDO support MAY=85 in its SYN-ACK=93 =97> = So, a receiver can extend its options space directly in his first segment. Right? - =84Because it overrides an existing TCP header field when present=93 = -> I don=92t get this. You override the data field, no? (After reading Sec. 6.3, I have the feeling that I understand what = you mean here=85) - Last para. Add ref to TCP-AO * Sec 6.3 - =84Once detected, the TCP EDO length option=85 for all subsequent = option processing OF THIS SEGMENT=93. Please make it clear that subsequent segments may not have the EDO length option and the = Data Offset field becomes valid again. - BTW I=92m not sure if the word override is the best one in this = context. Is =84invalid=93 not more appropriate? General comment at this point: - Should we not require that the Data Offset field must be zero if = TCP EDO length option is present, because it has no meaning in that case - As more I think about TCP EDO updates RFC793=85 Alex Am 22.04.2014 um 16:49 schrieb Joe Touch : > Hi, all, >=20 > Wes and I wrote the following to try to put to rest the issue of = extending TCP's option space. Although the primary reason was to = summarize why the SYN space cannot be extended, it is written as = Standards-Track because it includes an extension for non-SYN segments = that could still be useful when SACK, TS, and authentication or = encryption options are used together. >=20 > We are seeking this as a TCPM WG doc. Feedback appreciated. >=20 > Joe and Wes >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt > Date: Fri, 18 Apr 2014 13:30:46 -0700 > From: internet-drafts@ietf.org > To: Wesley M. Eddy , Dr. Joseph D. Touch = , Joe Touch , Wesley Eddy = >=20 >=20 > A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. >=20 > Name: draft-touch-tcpm-tcp-edo > Revision: 00 > Title: TCP Extended Data Offset Option > Document date: 2014-04-18 > Group: Individual Submission > Pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt > Status: = https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ > Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00 >=20 >=20 > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options, but the size of the field can limit the space available for > complex options that have evolved. This document specifies an > optional extension to that space and explains why such extensions > (including this) cannot be used in the initial SYN. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_D3EF170E-FFB9-4EB9-AAFC-8038F014E33A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNaeJEACgkQdyiq39b9uS5gvQCgq9qvBZFkM+mM5xiPbBo0MKas Fb8AoOxjuewO5oUZG28YEQ+Y3Yr8Y5KR =krwW -----END PGP SIGNATURE----- --Apple-Mail=_D3EF170E-FFB9-4EB9-AAFC-8038F014E33A-- From nobody Fri Apr 25 08:22: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 8009E1A0345 for ; Fri, 25 Apr 2014 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vv_YOOgmHES for ; Fri, 25 Apr 2014 08:22:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 27C471A0300 for ; Fri, 25 Apr 2014 08:22:16 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3PFLa5d014072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Apr 2014 08:21:46 -0700 (PDT) Message-ID: <535A7D85.6060909@isi.edu> Date: Fri, 25 Apr 2014 08:21:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" , Wesley Eddy References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <0EA7EF6A-26A6-48D2-B6BF-CCCEF494F815@netapp.com> In-Reply-To: <0EA7EF6A-26A6-48D2-B6BF-CCCEF494F815@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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/ZNbJHPwIgQ7W4BMekmujqlF5wm8 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:22:19 -0000 Hi, Alex, Thanks for the feedback. Additional questions below... Joe On 4/25/2014 8:00 AM, Zimmermann, Alexander wrote: > Hi Joe, Wes, > > thank you for this work. I also strongly support this work/doc. > > Some comments > > * Sec 1: > - Please add a reference to RFC 793. > - Please add one or two examples of common option combinations where we have a problem, e.g. TCP TS, SACK, and Multipath TCP Will do. > * Sec 2: > - „A SYN may include user data …“ Please add a reference to RFC 793/TFO Will do. > * Sec 4: > - Should we mention „draft-paasch-mptcp-control-stream“ here? I don't think so, any more than mentioning FTP's control channel. In both cases, a separate data channel is used for control info. The MPTCP approach isn't applicable to individual TCP connections - it only works in MPTCP because the group of connections is co-associated. > - „The six reserved … to be ignored“ —> maybe we can required this in RFC793bis ;-) It's certainly something we should address in 793bis. > - While it may be not possible to extend the option in a SYN, it’s possible to reduce the space needed, e.g. > late negotiation. Maybe we can add some text here. Compression should be discussed (e.g., taking flag options and representing them as bits in a single option), but they're very uncommon (except that EDO in the SYN would be an example). It might also be possible to combine options so that a single type/length can replace repeated ones, but that saves very little space overall because SYN space is consumed by a relatively small number of large options. Late negotiation should be discussed, but in the context that initiating new capabilities after the TWHS isn't viable. > * Sec 5: > - „For initial SYN segments (i.e., those whose ACK bit is not set)“. IMO a SYN is a segment where the SYN bit is set. We're both right. I was clear in explaining that "initial SYN" is SYN and no ACK, which is a connection initiator. SYN-ACK is a response to an initial SYN. Given I explained what an initial SYN is, I don't see the issue. Can you clarify your concern? > - The explanation of the EDO option is in a different order than the figures. Please explain first figure 1 and > then 2 (or swap the figures) Sure/ > - „An endpoint confirming EDO support MAY… in its SYN-ACK“ —> So, a receiver can extend its options space directly > in his first segment. Right? Yes; I'll make it more clear that the "initial SYN" is the one that can't be extended, and that responses to that can. > - „Because it overrides an existing TCP header field when present“ -> I don’t get this. You override the data field, no? > (After reading Sec. 6.3, I have the feeling that I understand what you mean here…) Others pointed that ambiguity out, and I'll both clarify, integrate in one place, and give an example there. > - Last para. Add ref to TCP-AO OK. > * Sec 6.3 > - „Once detected, the TCP EDO length option… for all subsequent option processing OF THIS SEGMENT“. Please make it clear > that subsequent segments may not have the EDO length option and the Data Offset field becomes valid again. Will do as part of the clarification and example noted above. > - BTW I’m not sure if the word override is the best one in this context. Is „invalid“ not more appropriate? I'll check that throughout. The DO continues to have partial meaning in this method - i.e., it never really becomes useless (implied by invalid), it's just that once you see EDO (which you need to interpret DO correctly to do), EDO overrides DO for the interpretation of the rest of the options and data of that segment. That's why I used "override". Again, I'll check that, but I'm open to suggestions too. > General comment at this point: > - Should we not require that the Data Offset field must be zero if TCP EDO length option is present, because it has > no meaning in that case Right - that's why this method never does that (see above regarding "overrides"). > - As more I think about TCP EDO updates RFC793… Strictly, every TCP option ought to do that IMO. However, because it's optional rather than mandatory, it's not clear - I've seen optional extensions treated both ways ("updates" and not-updates). I don't really care, but I agree that this issue should be determined as we move forward. > Alex > > > Am 22.04.2014 um 16:49 schrieb Joe Touch : > >> Hi, all, >> >> Wes and I wrote the following to try to put to rest the issue of extending TCP's option space. Although the primary reason was to summarize why the SYN space cannot be extended, it is written as Standards-Track because it includes an extension for non-SYN segments that could still be useful when SACK, TS, and authentication or encryption options are used together. >> >> We are seeking this as a TCPM WG doc. Feedback appreciated. >> >> Joe and Wes >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt >> Date: Fri, 18 Apr 2014 13:30:46 -0700 >> From: internet-drafts@ietf.org >> To: Wesley M. Eddy , Dr. Joseph D. Touch , Joe Touch , Wesley Eddy >> >> >> A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt >> has been successfully submitted by Joe Touch and posted to the >> IETF repository. >> >> Name: draft-touch-tcpm-tcp-edo >> Revision: 00 >> Title: TCP Extended Data Offset Option >> Document date: 2014-04-18 >> Group: Individual Submission >> Pages: 9 >> URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt >> Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ >> Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00 >> >> >> Abstract: >> TCP segments include a Data Offset field to indicate space for TCP >> options, but the size of the field can limit the space available for >> complex options that have evolved. This document specifies an >> optional extension to that space and explains why such extensions >> (including this) cannot be used in the initial SYN. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Apr 25 08:47: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 1E7131A0538 for ; Fri, 25 Apr 2014 08:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 UQRBIkXLNvp5 for ; Fri, 25 Apr 2014 08:47:39 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7C78D1A05D3 for ; Fri, 25 Apr 2014 08:47:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,927,1389772800"; d="asc'?scan'208";a="119357937" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 25 Apr 2014 08:47:13 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 08:47:14 -0700 From: "Zimmermann, Alexander" To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt Thread-Index: AQHPYJolyHrf4g64hkKitIe4jD9iUZsi72KA Date: Fri, 25 Apr 2014 15:47:12 +0000 Message-ID: <30F0D369-CFB9-42FB-933E-58B596E7BDD7@netapp.com> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <0EA7EF6A-26A6-48D2-B6BF-CCCEF494F815@netapp.com> <535A7D85.6060909@isi.edu> In-Reply-To: <535A7D85.6060909@isi.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/signed; boundary="Apple-Mail=_8732EE0F-DE5E-46AF-A431-3575BBAB2E7E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Wr20mV2opmd6XZS6ro0H4UH_yr4 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:47:42 -0000 --Apple-Mail=_8732EE0F-DE5E-46AF-A431-3575BBAB2E7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Joe, that was quick :-) Inline. Am 25.04.2014 um 17:21 schrieb Joe Touch : > Hi, Alex, >=20 > Thanks for the feedback. Additional questions below... >=20 > Joe >=20 > On 4/25/2014 8:00 AM, Zimmermann, Alexander wrote: >> Hi Joe, Wes, >>=20 >> thank you for this work. I also strongly support this work/doc. >>=20 >> Some comments >>=20 >> * Sec 1: >> - Please add a reference to RFC 793. >> - Please add one or two examples of common option combinations = where we have a problem, e.g. TCP TS, SACK, and Multipath TCP >=20 > Will do. >=20 >> * Sec 2: >> - =84A SYN may include user data =85=93 Please add a reference to = RFC 793/TFO >=20 > Will do. >=20 >> * Sec 4: >> - Should we mention =84draft-paasch-mptcp-control-stream=93 here? >=20 > I don't think so, any more than mentioning FTP's control channel. In = both cases, a separate data channel is used for control info. The MPTCP = approach isn't applicable to individual TCP connections - it only works = in MPTCP because the group of connections is co-associated. >=20 >> - =84The six reserved =85 to be ignored=93 =97> maybe we can = required this in RFC793bis ;-) >=20 > It's certainly something we should address in 793bis. >=20 >> - While it may be not possible to extend the option in a SYN, it=92s= possible to reduce the space needed, e.g. >> late negotiation. Maybe we can add some text here. >=20 > Compression should be discussed (e.g., taking flag options and = representing them as bits in a single option), but they're very uncommon = (except that EDO in the SYN would be an example). >=20 > It might also be possible to combine options so that a single = type/length can replace repeated ones, but that saves very little space = overall because SYN space is consumed by a relatively small number of = large options. >=20 > Late negotiation should be discussed, but in the context that = initiating new capabilities after the TWHS isn't viable. >=20 >> * Sec 5: >> - =84For initial SYN segments (i.e., those whose ACK bit is not = set)=93. IMO a SYN is a segment where the SYN bit is set. >=20 > We're both right. I was clear in explaining that "initial SYN" is SYN = and no ACK, which is a connection initiator. SYN-ACK is a response to an = initial SYN. >=20 > Given I explained what an initial SYN is, and exactly this is what I miss and which confused me :-) What do you think about the following text: =84For initial SYN segments (i.e., the first SYN during the 3-way = handshake) =20 > I don't see the issue. Can you clarify your concern? >=20 >> - The explanation of the EDO option is in a different order than = the figures. Please explain first figure 1 and >> then 2 (or swap the figures) >=20 > Sure/ >=20 >> - =84An endpoint confirming EDO support MAY=85 in its SYN-ACK=93 = =97> So, a receiver can extend its options space directly >> in his first segment. Right? >=20 > Yes; I'll make it more clear that the "initial SYN" is the one that = can't be extended, and that responses to that can. >=20 >> - =84Because it overrides an existing TCP header field when = present=93 -> I don=92t get this. You override the data field, no? >> (After reading Sec. 6.3, I have the feeling that I understand = what you mean here=85) >=20 > Others pointed that ambiguity out, and I'll both clarify, integrate in = one place, and give an example there. >=20 >> - Last para. Add ref to TCP-AO >=20 > OK. >=20 >> * Sec 6.3 >> - =84Once detected, the TCP EDO length option=85 for all = subsequent option processing OF THIS SEGMENT=93. Please make it clear >> that subsequent segments may not have the EDO length option and = the Data Offset field becomes valid again. >=20 > Will do as part of the clarification and example noted above. >=20 >> - BTW I=92m not sure if the word override is the best one in this = context. Is =84invalid=93 not more appropriate? >=20 > I'll check that throughout. The DO continues to have partial meaning = in this method - i.e., it never really becomes useless (implied by = invalid), it's just that once you see EDO (which you need to interpret = DO correctly to do), EDO overrides DO for the interpretation of the rest = of the options and data of that segment. That's why I used "override". = Again, I=92ll check that, but I'm open to suggestions too. With this explanation it becomes clearer. Before I didn=92t realize that = we still need to interpret DO if EDO is present. Now, after I got your point and I think =84invalid=93 = is not the right word and =84override=93 is exactly what we do. I think if we extend the processing section w/ = some explanation why we still need the DO it becomes clear. >=20 >> General comment at this point: >> - Should we not require that the Data Offset field must be zero if = TCP EDO length option is present, because it has >> no meaning in that case >=20 > Right - that's why this method never does that (see above regarding = "overrides"). >=20 >> - As more I think about TCP EDO updates RFC793=85 >=20 > Strictly, every TCP option ought to do that IMO. Yes, but w/ TCP EDO we reorganize the header in that sense that we have = later on options in the data field. So we change the meaning of bits of a TCP segment.=20 > However, because it's optional rather than mandatory, it's not clear - = I've seen optional extensions treated both ways ("updates" and = not-updates). I don't really care, but I agree that this issue should be = determined as we move forward. >=20 >> Alex >>=20 >>=20 >> Am 22.04.2014 um 16:49 schrieb Joe Touch : >>=20 >>> Hi, all, >>>=20 >>> Wes and I wrote the following to try to put to rest the issue of = extending TCP's option space. Although the primary reason was to = summarize why the SYN space cannot be extended, it is written as = Standards-Track because it includes an extension for non-SYN segments = that could still be useful when SACK, TS, and authentication or = encryption options are used together. >>>=20 >>> We are seeking this as a TCPM WG doc. Feedback appreciated. >>>=20 >>> Joe and Wes >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for = draft-touch-tcpm-tcp-edo-00.txt >>> Date: Fri, 18 Apr 2014 13:30:46 -0700 >>> From: internet-drafts@ietf.org >>> To: Wesley M. Eddy , Dr. Joseph D. Touch = , Joe Touch , Wesley Eddy = >>>=20 >>>=20 >>> A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt >>> has been successfully submitted by Joe Touch and posted to the >>> IETF repository. >>>=20 >>> Name: draft-touch-tcpm-tcp-edo >>> Revision: 00 >>> Title: TCP Extended Data Offset Option >>> Document date: 2014-04-18 >>> Group: Individual Submission >>> Pages: 9 >>> URL: = http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ >>> Htmlized: = http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00 >>>=20 >>>=20 >>> Abstract: >>> TCP segments include a Data Offset field to indicate space for TCP >>> options, but the size of the field can limit the space available = for >>> complex options that have evolved. This document specifies an >>> optional extension to that space and explains why such extensions >>> (including this) cannot be used in the initial SYN. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 --Apple-Mail=_8732EE0F-DE5E-46AF-A431-3575BBAB2E7E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNag38ACgkQdyiq39b9uS4QmQCgvLBVj2GVM2sSIZeSPsZiJ4yh NqcAnR3WdRVc4Z5eHphFZFh9v8GAPI9I =AaEH -----END PGP SIGNATURE----- --Apple-Mail=_8732EE0F-DE5E-46AF-A431-3575BBAB2E7E-- From nobody Fri Apr 25 09:28: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 4CEEC1A06FF for ; Fri, 25 Apr 2014 09:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZcXbHsT7Qzj for ; Fri, 25 Apr 2014 09:28:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DDD721A06E5 for ; Fri, 25 Apr 2014 09:26:39 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3PGPQtx000009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Apr 2014 09:25:36 -0700 (PDT) Message-ID: <535A8C7C.3050408@isi.edu> Date: Fri, 25 Apr 2014 09:25:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <0EA7EF6A-26A6-48D2-B6BF-CCCEF494F815@netapp.com> <535A7D85.6060909@isi.edu> <30F0D369-CFB9-42FB-933E-58B596E7BDD7@netapp.com> In-Reply-To: <30F0D369-CFB9-42FB-933E-58B596E7BDD7@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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/znotdQEysbmOp5e7Od1jfPdLeLU Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:28:15 -0000 Hi, Alex, Cutting to the open issues; I think these can be fixed in the 01 version easily but may be harder to confirm in email, so I'll take a shot at the revision ASAP. Joe On 4/25/2014 8:47 AM, Zimmermann, Alexander wrote: > Hi Joe, > > that was quick :-) > > Inline. ... >>> * Sec 5: >>> - „For initial SYN segments (i.e., those whose ACK bit is not set)“. IMO a SYN is a segment where the SYN bit is set. >> >> We're both right. I was clear in explaining that "initial SYN" is SYN and no ACK, which is a connection initiator. SYN-ACK is a response to an initial SYN. >> >> Given I explained what an initial SYN is, > > and exactly this is what I miss and which confused me :-) > > What do you think about the following text: > > „For initial SYN segments (i.e., the first SYN during the 3-way handshake) A SYN-only can also be part of a simultaneous open; I might say: For initial SYN segments (SYN but not SYN-ACK, i.e., the first SYN in a three-way handshake or simultaneous open) ... >>> - BTW I’m not sure if the word override is the best one in this context. Is „invalid“ not more appropriate? >> >> I'll check that throughout. The DO continues to have partial meaning in this method - i.e., it never really becomes useless (implied by invalid), it's just that once you see EDO (which you need to interpret DO correctly to do), EDO overrides DO for the interpretation of the rest of the options and data of that segment. That's why I used "override". Again, I’ll check that, but I'm open to suggestions too. > > With this explanation it becomes clearer. Before I didn’t realize that we still need to interpret DO > if EDO is present. Now, after I got your point and I think „invalid“ is not the right word and „override“ > is exactly what we do. I think if we extend the processing section w/ some explanation why we still need > the DO it becomes clear. AOK - let's leave that one for the clarification revision, and let me know if the result works in v01 or not... ... >>> - As more I think about TCP EDO updates RFC793… >> >> Strictly, every TCP option ought to do that IMO. > > Yes, but w/ TCP EDO we reorganize the header in that sense that we have later on options in > the data field. So we change the meaning of bits of a TCP segment. Again, I've seen it handled both ways. I don't mind how we decide to do it, or how the ADs recommend, but I figure we don't need to decide that between the two of us. Either way, whatever is decided, I'm glad to adjust the text/doc header. --- From nobody Fri Apr 25 09:54:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBADB1A055D for ; Fri, 25 Apr 2014 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 W1BXRBrzIjx4 for ; Fri, 25 Apr 2014 09:53:56 -0700 (PDT) Received: from atl4mhob16.myregisteredsite.com (atl4mhob16.myregisteredsite.com [209.17.115.109]) by ietfa.amsl.com (Postfix) with ESMTP id 407E91A065D for ; Fri, 25 Apr 2014 09:53:53 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob16.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3PGrbpY017266 for ; Fri, 25 Apr 2014 12:53:37 -0400 Received: (qmail 1833 invoked by uid 0); 25 Apr 2014 16:53:37 -0000 X-TCPREMOTEIP: 107.45.66.66 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.66.66) by 0 with ESMTPA; 25 Apr 2014 16:53:36 -0000 Message-ID: <535A930A.4070404@mti-systems.com> Date: Fri, 25 Apr 2014 12:53:30 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Joe Touch , "Zimmermann, Alexander" References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <0EA7EF6A-26A6-48D2-B6BF-CCCEF494F815@netapp.com> <535A7D85.6060909@isi.edu> In-Reply-To: <535A7D85.6060909@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uQ6GSjDWt6tvmVKo6f6SqUuV-Nk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:53:57 -0000 On 4/25/2014 11:21 AM, Joe Touch wrote: >> - „The six reserved … to be ignored“ —> maybe we can required this >> in RFC793bis ;-) > > It's certainly something we should address in 793bis. I just added it to the back of the 793bis TODO list. At some point, I hope to get 793bis adopted as a WG document too :). -- Wes Eddy MTI Systems From nobody Fri Apr 25 15:19: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 7128C1A068E for ; Fri, 25 Apr 2014 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4mUxxKcOVpi for ; Fri, 25 Apr 2014 15:19:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8EB1A0673 for ; Fri, 25 Apr 2014 15:19:39 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s3PMJ2Ph028326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Apr 2014 15:19:02 -0700 (PDT) Message-ID: <535ADF56.9050106@isi.edu> Date: Fri, 25 Apr 2014 15:19:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> In-Reply-To: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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/F4d4WrrW1RxWw5v9uNnslYmBVCc Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 22:19:41 -0000 Updated with all the pending suggestions. In some cases, I didn't quite use the exact text I suggested in email, but I figure the doc is in its early stages, so I opted for speed vs. accuracy ;-) I'd like to ask the chairs if we can consider a call to make this a WG doc? (given the work of the group is supposed to happen on the list - and I don't attend meetings in person these days -this doesn't seem like it needs to wait for a meeting to proceed) Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt Date: Fri, 25 Apr 2014 15:12:57 -0700 From: internet-drafts@ietf.org To: Wesley M. Eddy , Dr. Joseph D. Touch , Joe Touch , Wesley Eddy A new version of I-D, draft-touch-tcpm-tcp-edo-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tcpm-tcp-edo Revision: 01 Title: TCP Extended Data Offset Option Document date: 2014-04-25 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/ Htmlized: http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-touch-tcpm-tcp-edo-01 Abstract: TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document updates RFC 793 with an optional TCP extension to that space and explains why such extensions cannot be used in the initial SYN of a connection. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Apr 26 02: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 6E5FD1A0458 for ; Sat, 26 Apr 2014 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 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, RP_MATCHES_RCVD=-0.272, 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 tQH1icjZp7FS for ; Sat, 26 Apr 2014 02:47:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7E1A020C for ; Sat, 26 Apr 2014 02:47:00 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 221792781D5 for ; Sat, 26 Apr 2014 18:46:50 +0900 (JST) Received: by mail-la0-f41.google.com with SMTP id el20so1436989lab.28 for ; Sat, 26 Apr 2014 02:46:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.27.133 with SMTP id t5mr9066627lbg.21.1398505608347; Sat, 26 Apr 2014 02:46:48 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Sat, 26 Apr 2014 02:46:48 -0700 (PDT) In-Reply-To: <5357D8AD.4030608@isi.edu> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <5357D8AD.4030608@isi.edu> Date: Sat, 26 Apr 2014 02:46:48 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=001a1133b04a00846704f7eef652 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/VhEtjjx9e4fB7iIE4T_D4B8veHs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 09:47:02 -0000 --001a1133b04a00846704f7eef652 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Wed, Apr 23, 2014 at 8:13 AM, Joe Touch wrote: > > > On 4/23/2014 1:23 AM, Yoshifumi Nishida wrote: > >> Hi Joe, Wes, >> >> Thanks for the draft. Yes, extending TCP's options space is an important >> topic for tcp and has been discussed for long time. It would be great if >> we can find once-and-for-all solution for it. >> I think the draft seems to address the problems identified through the >> previous approach, however, I still have concern on it. >> >> One difficulty for extending options space is that middleboxes might >> re-segments packets or discard options. In case of other options like >> timestamp, SACK, this might not be a fatal issue. However, in case of >> this, the result will be catastrophic. >> > > Discarding options is always dangerous. There's no good way to detect this > other than to require that, once enabled, the option MUST appear in all > subsequent segments. But that alone doesn't ensure it's been followed - > resegmentation could still copy the visible options and move the data > around, and you wouldn't know. > > > So, I'm thinking that this approach might need some mechanisms that can >> check whether the segument is re-segmented or not. This could be done >> internally or externally by combining other features (AO or tcpcrypt, >> etc). >> Please let me know if you have opinions on this or if I miss something. >> > > You can surely detect whether a middlebox has done something that might > impact this option by using any sort of integrity protection. That's useful > to mention, but I don't think it's either necessary or useful to *require* > it. I am wondering how you want people to use this. You are saying that this is going to be a PS, which I guess it means people can use this in the wild anytime they want. I know we don't have to have experimental v.s. PS discussion now, but i'm just curious how to use this. Thanks, -- Yoshi --001a1133b04a00846704f7eef652 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Wed, Apr 23, 2014 at 8:13 AM, Joe Touch <touch@isi.e= du> wrote:


On 4/23/2014 1:23 AM, Yoshifumi Nishida wrote:
Hi Joe, Wes,

Thanks for the draft. Yes, extending TCP's options space is an importan= t
topic for tcp and has been discussed for long time. It would be great if we can find once-and-for-all solution for it.
I think the draft seems to address the problems identified through the
previous approach, however, I still have concern on it.

One difficulty for extending options space is that middleboxes might
re-segments packets or discard options. In case of other options like
timestamp, SACK, this might not be a fatal issue. However, in case of
this, the result will be catastrophic.

Discarding options is always dangerous. There's no good way to detect t= his other than to require that, once enabled, the option MUST appear in all= subsequent segments. But that alone doesn't ensure it's been follo= wed - resegmentation could still copy the visible options and move the data= around, and you wouldn't know.


So, I'm thinking that this approach might need some mechanisms that can=
check whether the segument is re-segmented or not. This could be done
internally or externally by combining other features (AO or tcpcrypt, etc).=
Please let me know if you have opinions on this or if I miss something.

You can surely detect whether a middlebox has done something that might imp= act this option by using any sort of integrity protection. That's usefu= l to mention, but I don't think it's either necessary or useful to = *require* it.
=C2=A0
I am wondering how you want people to use this.
=
You are saying that this is going to be a PS, which I guess it means = people can use this in the wild anytime they want.=C2=A0
I know we don't have to have experimental v.s. PS discussion now, but i= 'm just curious how to use this.

Thanks,
--
Yoshi
--001a1133b04a00846704f7eef652-- From nobody Sat Apr 26 03:53:30 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8511A048F for ; Sat, 26 Apr 2014 03:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 RyMbdByqhcbJ for ; Sat, 26 Apr 2014 03:53:25 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 319FD1A03A8 for ; Sat, 26 Apr 2014 03:53:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,933,1389772800"; d="asc'?scan'208";a="119471560" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 26 Apr 2014 03:53:18 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 03:53:17 -0700 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt Thread-Index: AQHPYT27ot8a1U7euEWS3U+KQIJI9w== Date: Sat, 26 Apr 2014 10:53:17 +0000 Message-ID: <6A08BE12-476B-48F1-BFDB-66F7825F54FE@netapp.com> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <5357D8AD.4030608@isi.edu> In-Reply-To: <5357D8AD.4030608@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.22] Content-Type: multipart/signed; boundary="Apple-Mail=_D3BEB19C-A366-432D-B09A-454269671AB1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/gnn9jV0yES6pm2_zDgJWn2dMc68 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 10:53:28 -0000 --Apple-Mail=_D3BEB19C-A366-432D-B09A-454269671AB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-4-23, at 17:13, Joe Touch wrote: > Discarding options is always dangerous. There's no good way to detect = this other than to require that, once enabled, the option MUST appear in = all subsequent segments. The two ends could agree to only include the option in a subset of the = segments sent (every nth, or some random sequence). If options get = dropped, you would find out eventually. But not immediately, as with = sending them in all options. (Yes, I feel pedantic this morning.) Lars --Apple-Mail=_D3BEB19C-A366-432D-B09A-454269671AB1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU1uQG9ZcnpRveo1xAQKdXgP+J58LNyvDEFcKhh+/oO4fw/qfObxaX29g jT1ffq1w4m9S7LYTMifjE+e7VqV/vKlSCVh4IHLjaFIxA+GRDnmILH+6Gp/hHkL9 dPXX52/GmOaow4c4ZHTvnFb8fBEYAuOf07oBvyS9SGtiGKSdz4ZgkLJR4n3aNpmb uCGHWPZ7Fuw= =leum -----END PGP SIGNATURE----- --Apple-Mail=_D3BEB19C-A366-432D-B09A-454269671AB1-- From nobody Sun Apr 27 23:53: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 D3C8A1A0734; Sun, 27 Apr 2014 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btQ_ClxvUD2T; Sun, 27 Apr 2014 23:52:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDD11A072A; Sun, 27 Apr 2014 23:52:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428065259.1863.61850.idtracker@ietfa.amsl.com> Date: Sun, 27 Apr 2014 23:52:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hcJbTFqzh98fBOuGjKU9DAK16qM Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 06:53:01 -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 : A Roadmap for Transmission Control Protocol (TCP) Specification Documents Authors : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-05.txt Pages : 52 Date : 2014-04-27 Abstract: This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-rfc4614bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 17:42: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 8971A1A8844 for ; Mon, 28 Apr 2014 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfJYCTH6VM01 for ; Mon, 28 Apr 2014 17:42:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A76E01A8855 for ; Mon, 28 Apr 2014 17:42:29 -0700 (PDT) Received: from [128.9.184.173] ([128.9.184.173]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3T0g1wY012281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Apr 2014 17:42:02 -0700 (PDT) Message-ID: <535EF561.4070702@isi.edu> Date: Mon, 28 Apr 2014 17:42:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <5357D8AD.4030608@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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/ilsyo_dw3A9nqE1RfY8pb35obk0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:42:31 -0000 Hi, Youshifumi, On 4/26/2014 2:46 AM, Yoshifumi Nishida wrote: > Hi Joe, > ... > I am wondering how you want people to use this. > You are saying that this is going to be a PS, which I guess it means > people can use this in the wild anytime they want. > I know we don't have to have experimental v.s. PS discussion now, but > i'm just curious how to use this. presented it as standards-track only because it is intended to update TCP; if this is considered risky, then we can consider a different track. My view is that it isn't any more or less risky than most other new TCP options, though. Joe From nobody Mon Apr 28 17:50: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 E38F81A885B for ; Mon, 28 Apr 2014 17:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-VXWaz0-3rg for ; Mon, 28 Apr 2014 17:50:23 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 343BC1A8844 for ; Mon, 28 Apr 2014 17:50:23 -0700 (PDT) Received: from [128.9.184.173] ([128.9.184.173]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s3T0o6Fo013823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Apr 2014 17:50:06 -0700 (PDT) Message-ID: <535EF745.8000706@isi.edu> Date: Mon, 28 Apr 2014 17:50:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Eggert, Lars" References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <5357D8AD.4030608@isi.edu> <6A08BE12-476B-48F1-BFDB-66F7825F54FE@netapp.com> In-Reply-To: <6A08BE12-476B-48F1-BFDB-66F7825F54FE@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/BusDhiQsDB8P1omomI4xZ6CYXow Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:50:32 -0000 On 4/26/2014 3:53 AM, Eggert, Lars wrote: > On 2014-4-23, at 17:13, Joe Touch wrote: >> Discarding options is always dangerous. There's no good way to >> detectthis other than to require that, once enabled, the option MUST appear in >> all subsequent segments. > > The two ends could agree to only include the option in a subset of > the segments sent (every nth, or some random sequence). If options > get dropped, you would find out eventually. But not immediately, as > with sending them in all options. Anything that drops EDO in segments would drop the initial SYN segment, and the connection would never start. If the path changes during a connection and a device on the new path drops EDO segments, then TCP would be stuck at some point anyway. If you send EDO in every Nth segment, then you just delay that response and make it more difficult for the endpoints to know why the connection failed. However, I don't think it's useful to design default protocol behavior solely to test for Internet bugs like this. IMO, we can leave it where it is - as "use when needed". But we can hash out details like this in the WG as consensus, too. I don't care all that much. Joe From nobody Mon Apr 28 22:17:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0801A8843 for ; Mon, 28 Apr 2014 22:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.36 X-Spam-Level: * X-Spam-Status: No, score=1.36 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, RP_MATCHES_RCVD=-0.651, 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 JtzR7BA4l6dd for ; Mon, 28 Apr 2014 22:17:41 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB871A883D for ; Mon, 28 Apr 2014 22:17:41 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3AA902781E7 for ; Tue, 29 Apr 2014 14:17:38 +0900 (JST) Received: by mail-la0-f47.google.com with SMTP id pn19so5646556lab.20 for ; Mon, 28 Apr 2014 22:17:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.5.202 with SMTP id u10mr7328lau.42.1398748656549; Mon, 28 Apr 2014 22:17:36 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Mon, 28 Apr 2014 22:17:36 -0700 (PDT) In-Reply-To: <535EF561.4070702@isi.edu> References: <20140418203046.19834.31916.idtracker@ietfa.amsl.com> <53568190.2090409@isi.edu> <5357D8AD.4030608@isi.edu> <535EF561.4070702@isi.edu> Date: Mon, 28 Apr 2014 22:17:36 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=089e013d1dd6cdc58c04f8278c54 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/fTYIIMlhiPH_9jcmpeBxnumRHSE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 05:17:43 -0000 --089e013d1dd6cdc58c04f8278c54 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Mon, Apr 28, 2014 at 5:42 PM, Joe Touch wrote: > Hi, Youshifumi, > > > On 4/26/2014 2:46 AM, Yoshifumi Nishida wrote: > >> Hi Joe, >> >> ... > > I am wondering how you want people to use this. >> You are saying that this is going to be a PS, which I guess it means >> people can use this in the wild anytime they want. >> I know we don't have to have experimental v.s. PS discussion now, but >> i'm just curious how to use this. >> > > presented it as standards-track only because it is intended to update TCP; > if this is considered risky, then we can consider a different track. > OK. make sense to me. > > My view is that it isn't any more or less risky than most other new TCP > options, though. My view may be a bit different, but I might be wrong and I think we can discuss later, not now. Thanks, -- Yoshi --089e013d1dd6cdc58c04f8278c54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Mon, Apr 28, 2014 at 5:42 PM, Joe Touch <touch@isi.edu> wrote:
Hi, Youshifumi,


On 4/26/2014 2:46 AM, Yoshifumi Nishida wrote:
Hi Joe,

...

I am wondering how you want people to use this.
You are saying that this is going to be a PS, which I guess it means
people can use this in the wild anytime they want.
I know we don't have to have experimental v.s. PS discussion now, but i'm just curious how to use this.

presented it as standards-track only because it is intended to update TCP; = if this is considered risky, then we can consider a different track.

OK. make sense to me.

My view is that it isn't any more or less risky than most other new TCP= options, though.

My view may be a bit diff= erent, but I might be wrong and I think we can discuss later, not now.

Thanks,
--
Yoshi
--089e013d1dd6cdc58c04f8278c54-- From nobody Tue Apr 29 08:25: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 754BD1A0905 for ; Tue, 29 Apr 2014 08:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 M5kzPQF06BOK for ; Tue, 29 Apr 2014 08:25:51 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 86CFF1A0909 for ; Tue, 29 Apr 2014 08:25:50 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3TFPlTl002988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Apr 2014 10:25:49 -0500 (CDT) 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 s3TFPlcY016894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Apr 2014 17:25:47 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.94]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 29 Apr 2014 17:25:47 +0200 From: "Scharf, Michael (Michael)" To: tcpm IETF list Thread-Topic: Publication has been requested for draft-ietf-tcpm-fastopen-08 Thread-Index: AQHPY76Ab2UvZeu9wkuSoYv21lMo6ZsoteOA Date: Tue, 29 Apr 2014 15:25:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2C5546@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7_Zt6iXHp8gY56kvG-DaB9rGdKI Subject: [tcpm] FW: Publication has been requested for draft-ietf-tcpm-fastopen-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 15:25:53 -0000 RllJDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIFNjaGFyZiBb bWFpbHRvOm1pY2hhZWwuc2NoYXJmQGFsY2F0ZWwtbHVjZW50LmNvbV0gDQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAyOSwgMjAxNCA1OjE5IFBNDQpUbzogbWxzLmlldGZAZ21haWwuY29tDQpDYzogdGNw bS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGllc2ctc2VjcmV0YXJ5QGlldGYub3JnOyB0Y3BtLWNo YWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi10Y3BtLWZhc3RvcGVuQHRvb2xzLmlldGYu b3JnDQpTdWJqZWN0OiBQdWJsaWNhdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWll dGYtdGNwbS1mYXN0b3Blbi0wOA0KDQpNaWNoYWVsIFNjaGFyZiBoYXMgcmVxdWVzdGVkIHB1Ymxp Y2F0aW9uIG9mIGRyYWZ0LWlldGYtdGNwbS1mYXN0b3Blbi0wOCBhcyBFeHBlcmltZW50YWwgb24g YmVoYWxmIG9mIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAuDQoNClBsZWFzZSB2ZXJpZnkgdGhlIGRv Y3VtZW50J3Mgc3RhdGUgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXRjcG0tZmFzdG9wZW4vDQoNCg== From nobody Wed Apr 30 07:44:18 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8A61A08D7 for ; Wed, 30 Apr 2014 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4yO5SeFiW5t for ; Wed, 30 Apr 2014 07:44:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id B59621A08F1 for ; Wed, 30 Apr 2014 07:44:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ED9A4474C6 for ; Wed, 30 Apr 2014 14:44:11 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E0DE1474C2 for ; Wed, 30 Apr 2014 14:44:11 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id D4985FE054 for ; Wed, 30 Apr 2014 14:44:11 +0000 (GMT) Message-ID: <53610C3B.6070006@akamai.com> Date: Wed, 30 Apr 2014 10:44:11 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> In-Reply-To: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lM9-Frq945LP12GKbp02hnynuWw Subject: [tcpm] Fwd: New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:44:16 -0000 We have updated the draft based on feedback on the list and in London. In particular, we have attempted to provide a clearer explanation of the use cases we are attempting to address and why solutions at other layers in the protocol stack do not work for these use cases. Previous updates had already attempted to provide stronger limiting guidance for option usage. As we have indicated previously on the list, we would prefer to see WG adoption of this I.D. rather than working toward publishing as an individual submission. We think WG adoption has a few benefits, even in the absence of clear consensus on the question of whether this is a good idea. First and foremost, WG adoption would mean that the limiting guidance on usage carries more weight. And second, WG adoption would more strongly encourage individual implementations that are already in use to converge on a single option format. We look forward to your feedback. Thanks, --Brandon -------- Original Message -------- Subject: New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt Date: Wed, 30 Apr 2014 10:22:20 -0400 From: internet-drafts@ietf.org To: Williams, Brandon , Dan Wing , Mohamed Boucadair , Mohamed Boucadair , Dan Wing , Williams, Brandon A new version of I-D, draft-williams-exp-tcp-host-id-opt-03.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-exp-tcp-host-id-opt Revision: 03 Title: Experimental Option for TCP Host Identification Document date: 2014-04-29 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-williams-exp-tcp-host-id-opt-03.txt Status: https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/ Htmlized: http://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-exp-tcp-host-id-opt-03 Abstract: Recent IETF proposals have identified benefits to more distinctly identifying the hosts that are hidden behind a shared address/prefix sharing device or application-layer proxy. Analysis indicates that the use of a TCP option for this purpose can be successfully applied to a broad range of use cases. This document describes a common experimental TCP option format for host identification. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Apr 30 07:51: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 7127E1A6F6E for ; Wed, 30 Apr 2014 07:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 mrAvN0r93juz for ; Wed, 30 Apr 2014 07:51:48 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id A7C641A08D3 for ; Wed, 30 Apr 2014 07:51:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,958,1389772800"; d="asc'?scan'208";a="85177860" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 30 Apr 2014 07:51:47 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 07:51:47 -0700 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt Thread-Index: AQHPZIO1u/26rztc9k+fT3iqOb4u6A== Date: Wed, 30 Apr 2014 14:51:45 +0000 Message-ID: References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> In-Reply-To: <53610C3B.6070006@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.19] Content-Type: multipart/signed; boundary="Apple-Mail=_2CDD78AD-479F-49F7-A410-49B3F59B8E4D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sV1Bk9t0L_fT1ubDC3hwjPuktlo Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:51:49 -0000 --Apple-Mail=_2CDD78AD-479F-49F7-A410-49B3F59B8E4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For the record, I am opposed to the WG taking this document on, and I am = opposed to it being published as an RFC on any stream. Lars --Apple-Mail=_2CDD78AD-479F-49F7-A410-49B3F59B8E4D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU2EOAdZcnpRveo1xAQITEQQAsTEzjVP8iRwAnZ1OG7pxoqmpy1TPbTLR ludN1rCRJi+Kv2KRb9exHIsJ9Re0WaGG7Kk7IPXPJ0pCONt2OcxIns1zBa+5hFp7 cXFhTHGqg+xsSHAWtPXnrxUgnM2mfoVDIvBxZhDbuM5JzD+6CZ1wC1kj4m6VReEf T8E/Y/A2uNE= =ccWx -----END PGP SIGNATURE----- --Apple-Mail=_2CDD78AD-479F-49F7-A410-49B3F59B8E4D-- From nobody Wed Apr 30 08:04: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 7A6AE1A0905 for ; Tue, 29 Apr 2014 09:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VbpR1-3D2dM for ; Tue, 29 Apr 2014 09:08:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1848C1A090E for ; Tue, 29 Apr 2014 09:08:22 -0700 (PDT) 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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429160822.15828.46552.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 09:08:22 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/D4URuTXMqX1C2TKCMurqUz6EDjU X-Mailman-Approved-At: Wed, 30 Apr 2014 08:04:26 -0700 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: Tue, 29 Apr 2014 16:08:24 -0000 Changed milestone "Submit update to RFC 1323 to the IESG for Proposed Standard RFC", resolved as "Done". Changed milestone "Submit document on a TCP fast open mechanism to the IESG for publication as an Experimental RFC", resolved as "Done", added draft-ietf-tcpm-fastopen to milestone. Deleted milestone " Decide the intended status of the document on TCP support for rate-limited traffic". URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nobody Wed Apr 30 12:18: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 8FBB51A886D for ; Wed, 30 Apr 2014 12:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTPM50XdjdKl for ; Wed, 30 Apr 2014 12:18:11 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id F2FB01A094A for ; Wed, 30 Apr 2014 12:18:10 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s3UJI6SG021372 for ; Wed, 30 Apr 2014 15:18:06 -0400 Received: (qmail 3584 invoked by uid 0); 30 Apr 2014 19:18:06 -0000 X-TCPREMOTEIP: 107.48.66.212 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.66.212) by 0 with ESMTPA; 30 Apr 2014 19:18:06 -0000 Message-ID: <53614C68.8040301@mti-systems.com> Date: Wed, 30 Apr 2014 15:18:00 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Eggert, Lars" , "tcpm@ietf.org" References: <20140430142220.21274.18191.idtracker@ietfa.amsl.com> <53610C3B.6070006@akamai.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aqR6DzW3W6qxmMoA4IIT0XVIBcU Subject: Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:18:13 -0000 On 4/30/2014 10:51 AM, Eggert, Lars wrote: > For the record, I am opposed to the WG taking this document on, and I > am opposed to it being published as an RFC on any stream. > My opinion is similar. An RFC isn't necessary to use an ExID. It doesn't require IETF approval, and is unlikely to get IETF approval, in order to do this in a system, if you really want to discount the problems and do it anyways. -- Wes Eddy MTI Systems