From gorry@erg.abdn.ac.uk Thu Aug 1 00:20:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B0921F9BA2 for ; Thu, 1 Aug 2013 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.555 X-Spam-Level: X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5cyZe4m0Z56 for ; Thu, 1 Aug 2013 00:20:52 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4C54421F9A98 for ; Thu, 1 Aug 2013 00:20:52 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id E57792B44B3; Thu, 1 Aug 2013 08:20:50 +0100 (BST) Received: from [130.129.23.225] (dhcp-17e1.meeting.ietf.org [130.129.23.225]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id EDC142B4098; Thu, 1 Aug 2013 08:20:45 +0100 (BST) References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6EE16.2020504@kau.se> <51F86253.4040009@bluecoat.com> <655C07320163294895BBADA28372AF5D07982E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 (1.0) In-Reply-To: <655C07320163294895BBADA28372AF5D07982E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6D6546D4-681C-44B0-BDE9-8226C42F0A34@erg.abdn.ac.uk> X-Mailer: iPad Mail (10B329) From: Gorry Date: Thu, 1 Aug 2013 09:20:43 +0200 To: "Scharf, Michael (Michael)" Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Aug 2013 07:20:59 -0000 Interesting? I should also add this to my list. Gorry On 31 Jul 2013, at 09:01 AM, "Scharf, Michael (Michael)" wrote: > Hi Andrew, >=20 > I wonder if you have experimented with setting ssthresh after an idle peri= od to a value that is of the order of the pipeACK parameter (cf. draft-ietf-= tcpm-newcwv-02 Section 4.2 - not flightsize)? >=20 > (Yes, I am aware of several other alternatives.) >=20 > Michael (without blue dot) >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Andrew Knutsen >> Sent: Wednesday, July 31, 2013 3:03 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] New revision:=20 >> draft-ietf-tcpm-newcwv-02.txt: ssthresh >>=20 >>=20 >> Given this observation, and the apparent general=20 >> agreement that reducing bursts while avoiding slow-start is=20 >> more important, I'm going to go ahead and bump ssthresh=20 >> higher than recommended by the draft (and >> RFC2861) in our TCP. Increasing the RW can wait for the=20 >> draft to be finalized, if we need it. >>=20 >> Thanks for your attention. >>=20 >> Andrew >>=20 >> On 7/29/2013 11:38 PM, Karen.Nielsen@tieto.com wrote: >>> HI, >>>=20 >>> We also have observed issues with ssthresh setting after idle. >>> This regards both TCP and SCTP usecase scenarios. >>>=20 >>> Our thoughts have been to reset ssthresh to inifinity after idle. >>> Setting to awnd is not a good solution in SCTP (or for >> mptcp) as the=20 >>> awnd may be small even if an idle period has been observed >> on a specific path on which traffic now resumes. >>>=20 >>> Possible SCTP or multipath issues are not within cwv, but >> still I would like to point to this fact. >>>=20 >>> BR, Karen >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] >> On Behalf=20 >>>> Of Anna Brunstrom >>>> Sent: Tuesday, July 30, 2013 12:35 AM >>>> To: tcpm@ietf.org >>>> Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt:=20 >>>> ssthresh >>>>=20 >>>> Hi Andrew, >>>>=20 >>>> I agree with you that the value of ssthresh is important and that=20 >>>> this part may need to be updated. If subsequent bursts are >> not long=20 >>>> enough to take you out of an unlucky state, a random loss >> in the the=20 >>>> first burst may hamper performance for all later bursts by >> invoking CA too early. >>>>=20 >>>> We have seen the equivalent problem when you have a >> sequence of short=20 >>>> flows and the ssthresh value is cached. A random loss in one short=20 >>>> flow can reduce performance for all the short flows that >> follow. See=20 >>>> our ICC paper from last year for details >> http://dx.doi.org/10.1109/ICC.2012.6364516. >>>>=20 >>>> BR, >>>> Anna >>>>=20 >>>>=20 >>>> On 2013-07-29 21:34, Andrew Knutsen wrote: >>>>> I'd like to ask one question again, before we implement=20 >>>>> something to avoid issues with a customer. >>>>>=20 >>>>> Most of the discussion here seems to be about >> avoiding bursts=20 >>>>> after idle while at the same time avoiding slow-start. >>>>>=20 >>>>> The problem we have is not slow-start after idle; its going=20 >>>>> into congestion-avoidance after idle, due to an obsolete ssthresh. >>>>>=20 >>>>> The current draft, like RFC2861, suggests setting >> ssthresh to=20 >>>>> 3/4 the old cwnd value after idle. We've tested this, and found=20 >>>>> that although it is an improvement over not doing anything (ie,=20 >>>>> rfc5681), cwnd does not recover with this factor when >> presented with=20 >>>>> a series of bursts if ssthresh is low. We've also tested with=20 >>>>> setting it to full cwnd, and to the advertised window >> (which is the=20 >>>>> receive window when idle). Note that all of these are more=20 >>>>> conservative than closing and re-opening the connection, >> which sets=20 >>>>> ssthresh to infinity (if it isn't cached). >>>>>=20 >>>>> We've found that setting cwnd to IW after idle, and setting=20 >>>>> ssthresh to awnd, allows acceptable recovery from a >> congestion event=20 >>>>> while running burst traffic. In other words, slow-start >> works well=20 >>>>> enough from IW (it's fast compared to CA). >>>>>=20 >>>>> We've tried to start discussion about this, but it >> looks like=20 >>>>> the consensus is a lack of concern. While we would >> prefer to see a=20 >>>>> spec which addresses our concerns, we do have pressing >> need to fix this issue. >>>>>=20 >>>>> Andrew >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Thu Aug 1 00:51:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70B21F896D for ; Thu, 1 Aug 2013 00:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXiNdg-E0Bgn for ; Thu, 1 Aug 2013 00:51:26 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C02BF21F89A6 for ; Thu, 1 Aug 2013 00:51:26 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r717pJVw026872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Aug 2013 02:51:21 -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 r717pICq019851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 09:51:18 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 1 Aug 2013 09:51:18 +0200 From: "Scharf, Michael (Michael)" To: Gorry Thread-Topic: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh Thread-Index: AQHOjJL6m/ShjGKxDEicWZgddkmTepl8HQ0AgACG/oCAATTAgIAAfn0AgAF9ToCAAChZIA== Date: Thu, 1 Aug 2013 07:51:17 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07BC04@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20130701194925.25967.70174.idtracker@ietfa.amsl.com> <618CDE13-6926-4088-B318-1DA15E38985E@netapp.com> <20130729143100.GA17380@localhost.localdomain> <51F6934B.3040808@erg.abdn.ac.uk> <51F6C3E0.7040205@bluecoat.com> <51F6EE16.2020504@kau.se> <51F86253.4040009@bluecoat.com> <655C07320163294895BBADA28372AF5D07982E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <6D6546D4-681C-44B0-BDE9-8226C42F0A34@erg.abdn.ac.uk> In-Reply-To: <6D6546D4-681C-44B0-BDE9-8226C42F0A34@erg.abdn.ac.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt: ssthresh X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Aug 2013 07:51:32 -0000 This may only be a piece of an overall solution, e.g., combined with resett= ing of ssthresh to the initial value (infinity in some stacks) after a long= er idle period. Basically, the idle period for resetting ssthresh could be = of the same order of magnitude like the local host cache timeout, in order = to make restart similar to a new connection setup. Michael > -----Original Message----- > From: Gorry [mailto:gorry@erg.abdn.ac.uk]=20 > Sent: Thursday, August 01, 2013 9:21 AM > To: Scharf, Michael (Michael) > Cc: Andrew Knutsen; tcpm@ietf.org > Subject: Re: [tcpm] New revision:=20 > draft-ietf-tcpm-newcwv-02.txt: ssthresh >=20 > Interesting? I should also add this to my list. >=20 > Gorry >=20 > On 31 Jul 2013, at 09:01 AM, "Scharf, Michael (Michael)"=20 > wrote: >=20 > > Hi Andrew, > >=20 > > I wonder if you have experimented with setting ssthresh=20 > after an idle period to a value that is of the order of the=20 > pipeACK parameter (cf. draft-ietf-tcpm-newcwv-02 Section 4.2=20 > - not flightsize)? > >=20 > > (Yes, I am aware of several other alternatives.) > >=20 > > Michael (without blue dot) > >=20 > >=20 > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf=20 > >> Of Andrew Knutsen > >> Sent: Wednesday, July 31, 2013 3:03 AM > >> To: tcpm@ietf.org > >> Subject: Re: [tcpm] New revision:=20 > >> draft-ietf-tcpm-newcwv-02.txt: ssthresh > >>=20 > >>=20 > >> Given this observation, and the apparent general agreement that=20 > >> reducing bursts while avoiding slow-start is more important, I'm=20 > >> going to go ahead and bump ssthresh higher than recommended by the=20 > >> draft (and > >> RFC2861) in our TCP. Increasing the RW can wait for the=20 > draft to be=20 > >> finalized, if we need it. > >>=20 > >> Thanks for your attention. > >>=20 > >> Andrew > >>=20 > >> On 7/29/2013 11:38 PM, Karen.Nielsen@tieto.com wrote: > >>> HI, > >>>=20 > >>> We also have observed issues with ssthresh setting after idle. > >>> This regards both TCP and SCTP usecase scenarios. > >>>=20 > >>> Our thoughts have been to reset ssthresh to inifinity after idle. > >>> Setting to awnd is not a good solution in SCTP (or for > >> mptcp) as the > >>> awnd may be small even if an idle period has been observed > >> on a specific path on which traffic now resumes. > >>>=20 > >>> Possible SCTP or multipath issues are not within cwv, but > >> still I would like to point to this fact. > >>>=20 > >>> BR, Karen > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] > >> On Behalf > >>>> Of Anna Brunstrom > >>>> Sent: Tuesday, July 30, 2013 12:35 AM > >>>> To: tcpm@ietf.org > >>>> Subject: Re: [tcpm] New revision: draft-ietf-tcpm-newcwv-02.txt:=20 > >>>> ssthresh > >>>>=20 > >>>> Hi Andrew, > >>>>=20 > >>>> I agree with you that the value of ssthresh is important=20 > and that=20 > >>>> this part may need to be updated. If subsequent bursts are > >> not long > >>>> enough to take you out of an unlucky state, a random loss > >> in the the > >>>> first burst may hamper performance for all later bursts by > >> invoking CA too early. > >>>>=20 > >>>> We have seen the equivalent problem when you have a > >> sequence of short > >>>> flows and the ssthresh value is cached. A random loss in=20 > one short=20 > >>>> flow can reduce performance for all the short flows that > >> follow. See > >>>> our ICC paper from last year for details > >> http://dx.doi.org/10.1109/ICC.2012.6364516. > >>>>=20 > >>>> BR, > >>>> Anna > >>>>=20 > >>>>=20 > >>>> On 2013-07-29 21:34, Andrew Knutsen wrote: > >>>>> I'd like to ask one question again, before we implement=20 > >>>>> something to avoid issues with a customer. > >>>>>=20 > >>>>> Most of the discussion here seems to be about > >> avoiding bursts > >>>>> after idle while at the same time avoiding slow-start. > >>>>>=20 > >>>>> The problem we have is not slow-start after idle; its going=20 > >>>>> into congestion-avoidance after idle, due to an=20 > obsolete ssthresh. > >>>>>=20 > >>>>> The current draft, like RFC2861, suggests setting > >> ssthresh to > >>>>> 3/4 the old cwnd value after idle. We've tested this,=20 > and found=20 > >>>>> that although it is an improvement over not doing anything (ie,=20 > >>>>> rfc5681), cwnd does not recover with this factor when > >> presented with > >>>>> a series of bursts if ssthresh is low. We've also tested with=20 > >>>>> setting it to full cwnd, and to the advertised window > >> (which is the > >>>>> receive window when idle). Note that all of these are more=20 > >>>>> conservative than closing and re-opening the connection, > >> which sets > >>>>> ssthresh to infinity (if it isn't cached). > >>>>>=20 > >>>>> We've found that setting cwnd to IW after idle, and setting=20 > >>>>> ssthresh to awnd, allows acceptable recovery from a > >> congestion event > >>>>> while running burst traffic. In other words, slow-start > >> works well > >>>>> enough from IW (it's fast compared to CA). > >>>>>=20 > >>>>> We've tried to start discussion about this, but it > >> looks like > >>>>> the consensus is a lack of concern. While we would > >> prefer to see a > >>>>> spec which addresses our concerns, we do have pressing > >> need to fix this issue. > >>>>>=20 > >>>>> Andrew > >>>>>=20 > >>>>> _______________________________________________ > >>>>> tcpm mailing list > >>>>> tcpm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > = From wes@mti-systems.com Thu Aug 1 08:39:38 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DDB21F9E68 for ; Thu, 1 Aug 2013 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAmXxbNRXf2Q for ; Thu, 1 Aug 2013 08:39:32 -0700 (PDT) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4121F9E4D for ; Thu, 1 Aug 2013 08:39:13 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r71FdCLg026777 for ; Thu, 1 Aug 2013 11:39:12 -0400 Received: (qmail 7906 invoked by uid 0); 1 Aug 2013 15:39:12 -0000 X-TCPREMOTEIP: 130.129.68.101 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?130.129.68.101?) (wes@mti-systems.com@130.129.68.101) by 0 with ESMTPA; 1 Aug 2013 15:39:12 -0000 Message-ID: <51FA810B.4050209@mti-systems.com> Date: Thu, 01 Aug 2013 11:38:51 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Lahey References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Aug 2013 15:39:38 -0000 On 8/1/2013 2:07 AM, Kevin Lahey wrote: > > It would be nice if, instead of saying, "Read RFC793, then read the > additions from RFC1122, then update it with info from RFC2873, RFC3390, > etc.," we could say, "Read RFC8888 for the on-wire protocol details, and > RFC8889 for the congestion control details." It's tough to keep all > those details in your head while trying to write code, and it's > frustrating to explain all this to new engineers trying to work on the > TCP stack (RFC4614 certainly helps a great deal!). > > On the other hand, watching Richard work so hard to get consensus on > the (relatively) simple updates to RFC1323, I'm not sure who's ready to > bell the RFC793bis cat. Actually, I'm interested in working on this, and have some thoughts about what it should look like and what the ground rules would need to be in order to make it tractable. I can see that it would be useful as there are errata, and at least a few strings of updates to 793 that have been made. Plus some material should be removed that was important at the time, but is not really today. -- Wes Eddy MTI Systems From touch@isi.edu Thu Aug 1 17:51:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F1211E82E7 for ; Thu, 1 Aug 2013 17:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.062 X-Spam-Level: X-Spam-Status: No, score=-104.062 tagged_above=-999 required=5 tests=[AWL=-1.462, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyJ5yRAMg87C for ; Thu, 1 Aug 2013 17:51:03 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E4F1C11E834F for ; Thu, 1 Aug 2013 16:54:27 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r71NrxXu018303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 16:53:59 -0700 (PDT) Message-ID: <51FAF516.1020308@isi.edu> Date: Thu, 01 Aug 2013 16:53:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Lahey References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: 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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 00:51:24 -0000 On 7/31/2013 11:07 PM, Kevin Lahey wrote: > It would be nice if,... we could say, "Read RFC8888 for the on-wire protocol > details, and RFC8889 for the congestion control details." It would be nicer, IMO, if we could avoid the erroneous concept of "on the wire" as meaningful. A protocol consists of all three of the following; any subset is meaningless: state (at endpoints or intermediate nodes, which includes time events) messages ('on the wire') rules that relate the above two I think I understand your intent, which is to differentiate rigorous protocol requirements from vague ones, e.g., where TCP is more dependent on the precision of its 12 connection states than the details of its congestion control mechanism. However, both rely on all three components above. I don't have a pithy term for that distinction, but "on the wire" isn't it. Joe From touch@isi.edu Thu Aug 1 18:03:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4D811E835E for ; Thu, 1 Aug 2013 18:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.975 X-Spam-Level: X-Spam-Status: No, score=-105.975 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZM0wgPlHUCf for ; Thu, 1 Aug 2013 18:03:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 97AD011E827C for ; Thu, 1 Aug 2013 17:04:11 -0700 (PDT) Received: from [128.9.184.224] ([128.9.184.224]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r72038W5022880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Aug 2013 17:03:08 -0700 (PDT) Message-ID: <51FAF740.50701@isi.edu> Date: Thu, 01 Aug 2013 17:03:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Lahey References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <51FAF516.1020308@isi.edu> In-Reply-To: <51FAF516.1020308@isi.edu> 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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 01:03:58 -0000 On 8/1/2013 4:53 PM, Joe Touch wrote: > > > On 7/31/2013 11:07 PM, Kevin Lahey wrote: >> It would be nice if,... we could say, "Read RFC8888 for the on-wire >> protocol >> details, and RFC8889 for the congestion control details." > > It would be nicer, IMO, if we could avoid the erroneous concept of "on > the wire" as meaningful. > > A protocol consists of all three of the following; any subset is > meaningless: > > state (at endpoints or intermediate nodes, > which includes time events) Depending on whether you want to group these in here, this also includes upper layer events (messages from/to 'above'). Those can be modeled as state events or treated separately. FWIW. > messages ('on the wire') > > rules that relate the above two > > I think I understand your intent, which is to differentiate rigorous > protocol requirements from vague ones, e.g., where TCP is more dependent > on the precision of its 12 connection states than the details of its > congestion control mechanism. However, both rely on all three components > above. > > I don't have a pithy term for that distinction, but "on the wire" isn't it. > > Joe From kevin.lahey@oracle.com Thu Aug 1 23:53:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286CC11E8253 for ; Thu, 1 Aug 2013 23:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiWGrayLJoBs for ; Thu, 1 Aug 2013 23:53:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DA35411E824D for ; Thu, 1 Aug 2013 23:53:32 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r726rUcp020687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 06:53:31 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r726rTuM021432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 06:53:30 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r726rThI021428; Fri, 2 Aug 2013 06:53:29 GMT Received: from dhcp-548f.meeting.ietf.org (/130.129.84.143) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 23:53:29 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Kevin Lahey In-Reply-To: <51FAF516.1020308@isi.edu> Date: Fri, 2 Aug 2013 08:53:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9905EC63-1273-472E-9815-B00141B385D1@oracle.com> References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <51FAF516.1020308@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: tcpm@ietf.org Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 06:53:40 -0000 On Aug 2, 2013, at 1:53 AM, Joe Touch wrote: > On 7/31/2013 11:07 PM, Kevin Lahey wrote: >> It would be nice if,... we could say, "Read RFC8888 for the on-wire = protocol >> details, and RFC8889 for the congestion control details." >=20 > It would be nicer, IMO, if we could avoid the erroneous concept of "on = the wire" as meaningful. And, yet, it's kind of useful to know what I'm seeing when I look at a = packet trace. :-) > I think I understand your intent, which is to differentiate rigorous = protocol requirements from vague ones, e.g., where TCP is more dependent = on the precision of its 12 connection states than the details of its = congestion control mechanism. However, both rely on all three components = above. Sorry to get you started, Joe -- I was casually trying to suggest that = we didn't necessarily need one all-singing, all-dancing RFC to combine = all of the different TCP RFCs. Dividing it up along reasonable lines = would allow for easier updates, etc. In any case, my pain comes from reading something in RFC793, then = thinking to myself, "Gee, I seem to recall that this was updated, but = where, exactly?" It might be kind of cool to have, say, the description = of ABC folded into a RFC793-bis, but it also seems reasonable to have = just a reference to RFC3465 at the right place. Bless you, Wes. :-) Kevin kevin.lahey@oracle.com From pasi.sarolahti@iki.fi Fri Aug 2 03:06:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A36121E82E6 for ; Fri, 2 Aug 2013 03:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIym6myGoJf4 for ; Fri, 2 Aug 2013 03:06:23 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1409011E8331 for ; Fri, 2 Aug 2013 03:06:10 -0700 (PDT) Received: from dhcp-54b2.meeting.ietf.org (130.129.84.178) by jenni2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 51BB235B037FD084 for tcpm@ietf.org; Fri, 2 Aug 2013 13:06:02 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4587CF92-A66E-4EE7-AE99-D6174BFC167C@iki.fi> Date: Fri, 2 Aug 2013 12:06:00 +0200 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [tcpm] Draft TCPM meeting minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 10:06:28 -0000 Hi, Draft minutes from our meeting on Tuesday are available at = http://www.ietf.org/proceedings/87/minutes/minutes-87-tcpm . Please let = the chairs know if you find something incorrectly recorded. Many thanks to Michael W. and Gorry for taking the notes! - Pasi From michael.scharf@alcatel-lucent.com Fri Aug 2 03:10:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56521E826D for ; Fri, 2 Aug 2013 03:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5VhS6aym7yf for ; Fri, 2 Aug 2013 03:10:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C499021E8084 for ; Fri, 2 Aug 2013 03:10:52 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r72AAo4K016980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2013 05:10:51 -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 r72AAjKQ026370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 12:10:49 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 12:10:49 +0200 From: "Scharf, Michael (Michael)" To: "ietf-http-wg@w3.org" Thread-Topic: Feedback on TCP Fast Open? Thread-Index: Ac6PaI4pnwTAopi7RjGsw4hp5IioMg== Date: Fri, 2 Aug 2013 10:10:47 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07CBF8@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "tcpm@ietf.org" Subject: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 10:10:58 -0000 Hi all, As mentioned today on the mic, the TCPM working group has a working group i= tem that allows data to be carried in the SYN and SYN-ACK packets and that = is consumed by the receiving end during the initial connection handshake, w= hich is saves TCP handshakes. The document was discussed aleady extensively= in TCPM and will be updated. TCPM's understanding is that it is not far aw= ay from WGLC. The link is: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-04 In the spirit of today's session, feedback from the httpbis community would= be very appreciated. Please note that this mechanism slightly changes the = standard TCP semantics, as explained in the abstract: However TFO deviates from the standard TCP semantics in that the data in= the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, which is detailed in the Applicability section. Further information can be found in Section 6 of the document. Comments or reviews would be highly welcome. The discussion should take pla= ce on the TCPM mailing list. Thanks! Michael (TCPM co-chair) From michael.scharf@alcatel-lucent.com Fri Aug 2 03:25:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2216A21E82D3 for ; Fri, 2 Aug 2013 03:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EWsiunw6gx3 for ; Fri, 2 Aug 2013 03:25:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1601321E8376 for ; Fri, 2 Aug 2013 03:24:59 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r72AOn3k028043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2013 05:24:50 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r72AOjIQ001428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 12:24:48 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 12:24:46 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: TCP checksum issues? Thread-Index: Ac6PaoG+uB+WaQJXRmWPfTpc0gRQNw== Date: Fri, 2 Aug 2013 10:24:45 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07CC4E@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.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Mankin, Allison" , Mark Nottingham Subject: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 10:25:27 -0000 Hi all, In today's httpbis joint meeting, there was a brief discussion about potent= ial issues related to the TCP checksum. Since I am not aware of a recent discussion regarding the TCP checksum (it = surely has been discussed quite a bit in the past, e.g., RFC 1146), this e-= mail tries to trigger a follow-up discussion. I am particularly interested = in better understanding any potential issues in the context of HTTP/2. Thanks Michael PS: The TCP offloading issues and RFC 1936 should be obvious. From willchan@google.com Fri Aug 2 06:51:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB8D21E804D for ; Fri, 2 Aug 2013 06:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2R+NX9WcMLS for ; Fri, 2 Aug 2013 06:51:34 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7B21221E80A5 for ; Fri, 2 Aug 2013 06:51:33 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so1357041oag.4 for ; Fri, 02 Aug 2013 06:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KJqXbjk5OPdPb7n5IrhXeApavJ5zBpNmZrb6d/PVlPs=; b=TwhzPvgvEpy/WADDMUggFasapdnOYwtx/S8a3cYTBSdqV/rtLgw10+lWFx74sE3Ey1 GCap9bedLZfS9yVnLNsl2m+E1toGanibROqeE6E6VTESW9osiPc5JD8K90hiJKRTWML/ 6jttuZlqWF2y1NI+6ZGo6CtzrJcLABijS0SiJqoejJQdwlg60swrV/NpO4ScNinE9RG4 +Zu5UkUK32pcYIuoYRfFOz+pEPDCJC5Y7HuMnUaLXiL5MrNwr0JAURTFKNK2H1QaUSRW gwahcZX6mofBItNeEwF7igIB4FUfrKIRZ1IV5Zl0YfuAnqpVETXPWvdZWKPvXLaazzzq pjPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KJqXbjk5OPdPb7n5IrhXeApavJ5zBpNmZrb6d/PVlPs=; b=Z9dvHUMBQfFIhtiIGmh/s5276XgJutcRFK9LD483fwII18VTVcZShpDMzkIXAekVoz kHNWW2+c2I/Ql/yWHl5nEUfsEwrztamWtIOOgFHJ/bFIhcG44+apoqI1XOZZJXYuutsm 2/fFXfKFOukv8nddFw6v9JATyeM3Ypl3929wM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KJqXbjk5OPdPb7n5IrhXeApavJ5zBpNmZrb6d/PVlPs=; b=kUo14hL5qJJbUEiRxK+tSyYReROe5yx2iYJOx3vfP7LyoIeB1AcWycKK6UAqcs/FFI fBsJLscIlnKR43VbMDWfKdLP0O4rWDNyIZuf4P2ivVWRS/uyXc4dDIEbqIMUC0SCFs2Z iJvc1QVpa8ppNJXQu1DtidrEF/Ay7A+7GSDF+43oe15Fg4nR0bbdhK35xXVC8/DWyTPN n6F9evsEY7HGuWxeRZu23RKuB144Xf0x//84Ewzi8O3CRCnQZemnwGbTMxIssrs+6mI1 /erkR3W58HJdipNuQL/VDvrxny7JWJQ9aqfb3ZAlO4TrEFFncnFCCjlZEOF+Oy/E+Aki GUZQ== MIME-Version: 1.0 X-Received: by 10.43.128.66 with SMTP id hd2mr598151icc.89.1375451491826; Fri, 02 Aug 2013 06:51:31 -0700 (PDT) Sender: willchan@google.com Received: by 10.64.23.7 with HTTP; Fri, 2 Aug 2013 06:51:31 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 2 Aug 2013 06:51:31 -0700 X-Google-Sender-Auth: Sz86Jwd7QWdsKo_b68ekRAsMQTY Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=001a11c3117093aa9404e2f741dc X-Gm-Message-State: ALoCoQlYxXSGCut5mOJwOuQXx0emTPL0CTbmQMJVKcRUWArgutUQ+aldcszltIk0ExJ5N23nBwdKtj6D64UZUhlIvpWF7fJWMcE6zniqmOdHVHhAFV0Jo3kWyDgJcyMcxXjOWCKM9e1WF1L3BfpNjwI7Q0S6usSgWGY8HCrnD4YTkzkACA8VuPh1K2p3w9R8dakGt3qxQKEW Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 13:51:39 -0000 --001a11c3117093aa9404e2f741dc Content-Type: text/plain; charset=ISO-8859-1 Thanks for the invitation for feedback. I've been the primary contact on the Chromium / Google Chrome network stack team for Yuchung and the other TCP Fast Open authors at Google, so while I only lurk in tcpm, I've been reasonably involved in this particular feature. I've thought a lot about how we would use this in Chromium if available. For some detailed thoughts intended for a browser implementor audience, you can read those details at my blog ( https://insouciant.org/tech/some-quick-thoughts-on-tcp-fast-open-and-chromium/ ). The short of it is, for vanilla HTTP, it's unclear how beneficial it would be for us since we already have such gains for browser preconnect (our browser feature that learns from past web browsing to speculatively establish connections, typically just TCP connections but perhaps doing a TLS or other handshakes too as needed). There's a fundamental tension between our preconnect feature and TCP Fast Open for vanilla HTTP. Further experimentation is necessary and we've been working on this. I'm hopeful we can find a way to leverage this for our gain, but it requires more investigation. For TLS over TCP, there is a much more obvious win since we can squeeze the TLS CLIENT_HELLO into the TCP SYN, and there is no concern about violating idempotency. This combines with our preconnect feature very nicely, so I am rather excited about the potential for this use case. While HTTPS adoption is still low, I'm hopeful that it will increase over time (especially given the context of recent revelations). So I think the importance of the HTTPS use case will grow, and thus the potential importance of TCP Fast Open in decreasing user perceived latency. Cheers, Will On Fri, Aug 2, 2013 at 3:10 AM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Hi all, > > As mentioned today on the mic, the TCPM working group has a working group > item that allows data to be carried in the SYN and SYN-ACK packets and that > is consumed by the receiving end during the initial connection handshake, > which is saves TCP handshakes. The document was discussed aleady > extensively in TCPM and will be updated. TCPM's understanding is that it is > not far away from WGLC. > > The link is: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-04 > > In the spirit of today's session, feedback from the httpbis community > would be very appreciated. Please note that this mechanism slightly changes > the standard TCP semantics, as explained in the abstract: > > However TFO deviates from the standard TCP semantics in that the data > in the > SYN could be replayed to an application in some rare circumstances. > Applications should not use TFO unless they can tolerate this issue, > which is detailed in the Applicability section. > > Further information can be found in Section 6 of the document. > > Comments or reviews would be highly welcome. The discussion should take > place on the TCPM mailing list. > > Thanks! > > Michael (TCPM co-chair) > > --001a11c3117093aa9404e2f741dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the invitation for feedback.

I've been the primary contact on the Chromium / Google Chrome network = stack team for Yuchung and the other TCP Fast Open authors at Google, so wh= ile I only lurk in tcpm, I've been reasonably involved in this particul= ar feature. I've thought a lot about how we would use this in Chromium = if available. For some detailed thoughts intended for a browser implementor= audience, you can read those details at my blog (https://i= nsouciant.org/tech/some-quick-thoughts-on-tcp-fast-open-and-chromium/).=

The short of it is, for vanilla HTTP, it's unclear = how beneficial it would be for us since we already have such gains for brow= ser preconnect (our browser feature that learns from past web browsing to s= peculatively establish connections, typically just TCP connections but perh= aps doing a TLS or other handshakes too as needed). There's a fundament= al tension between our preconnect feature and TCP Fast Open for vanilla HTT= P. Further experimentation is necessary and we've been working on this.= I'm hopeful we can find a way to leverage this for our gain, but it re= quires more investigation.

For TLS over TCP, there is a much more obvious win sinc= e we can squeeze the TLS CLIENT_HELLO into the TCP SYN, and there is no con= cern about violating idempotency. This combines with our preconnect feature= very nicely, so I am rather excited about the potential for this use case.= While HTTPS adoption is still low, I'm hopeful that it will increase o= ver time (especially given the context of recent revelations). So I think t= he importance of the HTTPS use case will grow, and thus the potential impor= tance of TCP Fast Open in decreasing user perceived latency.

Cheers,
Will


On Fri, Aug 2, 2013 at 3:10 AM, Sc= harf, Michael (Michael) <michael.scharf@alcatel-lucent.com= > wrote:
Hi all,

As mentioned today on the mic, the TCPM working group has a working group i= tem that allows data to be carried in the SYN and SYN-ACK packets and that = is consumed by the receiving end during the initial connection handshake, w= hich is saves TCP handshakes. The document was discussed aleady extensively= in TCPM and will be updated. TCPM's understanding is that it is not fa= r away from WGLC.

The link is: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-= 04

In the spirit of today's session, feedback from the httpbis community w= ould be very appreciated. Please note that this mechanism slightly changes = the standard TCP semantics, as explained in the abstract:

=A0 =A0However TFO deviates from the standard TCP semantics in that the dat= a in the
=A0 =A0SYN could be replayed to an application in some rare circumstances.<= br> =A0 =A0Applications should not use TFO unless they can tolerate this issue,=
=A0 =A0which is detailed in the Applicability section.

Further information can be found in Section 6 of the document.

Comments or reviews would be highly welcome. The discussion should take pla= ce on the TCPM mailing list.

Thanks!

Michael (TCPM co-chair)


--001a11c3117093aa9404e2f741dc-- From rs@netapp.com Fri Aug 2 06:55:23 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E833C21E8087 for ; Fri, 2 Aug 2013 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.391 X-Spam-Level: X-Spam-Status: No, score=-7.391 tagged_above=-999 required=5 tests=[AWL=2.608, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llv6IdB+8TjI for ; Fri, 2 Aug 2013 06:55:17 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id B35E321E80BC for ; Fri, 2 Aug 2013 06:55:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,801,1367996400"; d="scan'208";a="77962883" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 02 Aug 2013 06:55:01 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.105]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 06:55:00 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , Pasi Sarolahti Thread-Topic: [tcpm] draft-ietf-tcpm-1323bis-14.txt Thread-Index: AQHOhlJ0mDsCw3frk0+Y7NXoRQhe4Jl8AbGAgAX5QeA= Date: Fri, 2 Aug 2013 13:55:00 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 13:55:23 -0000 Hi Yuchung, thanks for the review. > Some minor suggestions on wordings. > 1. RTTM Rule: A TSecr value received in a segment MAY be used to updat= e > the averaged RTT measurement only if the segment advances > the left edge of the send window, i.e. SND.UNA is > increased. > s/segment/ACK I have not incorporated that change, as this could be interpreted to be tru= e only for pure ACKs. Segments here could be any valid segments, with or wi= thout data (bidirectional data flow). > 2. "An for an out-of-order segment > SHOULD therefore contain the timestamp from the most recent > segment that advanced the window." > s/advanced the window/advanced RCV.NXT Modified. The contended section describing the semantics of the Timestamps option now= (in 1323bis-15 to-be) reads: Once TSopt has been successfully negotiated (sent and received) during the , exchange, TSopt MUST be sent in every non- segment for the duration of the connection, and SHOULD be sent in an segment (see Section 4.2 for details). If a non- segment is received without a TSopt, a TCP SHOULD silently drop the segment. A TCP MUST NOT abort a TCP connection because any segment lacks an expected TSopt. So, the SHOULD / SHOULD NOT are condensed in a simpler to read sentence.=20 As there have been multiple comments to describe the effects of this SHOULD= , the following paragraph was added right after. This is new text, and the = first throw. Text donations are highly appreciated if this text does not ca= pture the purpose to the required extent: Implementations are strongly encouraged to follow the above rules for handling a missing Timestamps option, and the order of precedence mentioned in Section 4.3 when deciding on the acceptance of a segment. This is to maintain the integrity of the payload data at the receiver in particular on high speed networks. However, it has been mentioned that under some circumstances, the above guidelines are too strict, and some paths sporadically suppress the Timestamps option, while maintaining payload integrity. A path behaving in this manner should be deemed inacceptable, but it has been noted that relaxing the acceptance rules can serve as a workaround, and allows TCP to run across such paths. Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Yuchung Cheng > Sent: Montag, 29. Juli 2013 13:12 > To: Pasi Sarolahti > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >=20 > I only reviewed section 3 and it looks good to me. >=20 > Some minor suggestions on wordings. > 1. RTTM Rule: A TSecr value received in a segment MAY be used to updat= e > the averaged RTT measurement only if the segment advances > the left edge of the send window, i.e. SND.UNA is > increased. > s/segment/ACK >=20 > 2. "An for an out-of-order segment > SHOULD therefore contain the timestamp from the most recent > segment that advanced the window." > s/advanced the window/advanced RCV.NXT >=20 >=20 > FWIW Linux recently changed to only use TS for RTTM if normal timings > aren't available. It now also measure RTT on new SACK for better RTO > during loss recovery http://patchwork.ozlabs.org/patch/260836/ > http://patchwork.ozlabs.org/patch/260838/ > http://patchwork.ozlabs.org/patch/260837/ >=20 >=20 > On Sun, Jul 21, 2013 at 10:39 PM, Pasi Sarolahti > wrote: > > Lots of mails have been exchanged on this since the WGLC, but here is a= n > attempt to shortly summarize the main points: > > > > * Mark Allman made a thorough set of comments during the WGLC. My > understanding is that these comments are now addressed. Some paragraphs > have changed quite a bit as a result, so it would be good if people can > check if the current text looks good. > > > > * After the WGLC there was an update on the text regarding handling of > segments without timestamp option after they have been successfully > negotiated (MUST drop in ver-14), and a follow-up discussion about > possible interactions with middleboxes. In a recent mail Richard proposes > changing this to SHOULD. This change is not yet visible in the I-D > repository. > > > > If I'm forgetting something important, please remind me (and the list). > > > > I think in the meeting we should go through the main recent changes, an= d > check if people are ok with the current wordings. Additional comments on > the list are much appreciated. > > > > - Pasi > > > > > > On Jul 16, 2013, at 2:03 PM, "Scheffenegger, Richard" > wrote: > > > >> Hi, > >> > >> I would like to take this opportunity to stir up the recent discussion= s > (from April/May timeframe) again. > >> > >> There have been some comments past the posting of this version on the > list, which I wasn't able to fully qualify how they would impact this > latest text. > >> > >> I would like to encourage the participants in these discussions to > review the latest version, and point out if they cannot agree with any of > the wording. > >> > >> > >> > >> There will probably be a slot at the upcoming IETF to try to find out > what the consensus is on this document, too... > >> > >> Best regards, > >> > >> Richard Scheffenegger > >> > >> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Donnerstag, 23. Mai 2013 16:10 > >>> To: Bob Braden; Scheffenegger, Richard; Robert T. Braden; David > >>> Borman; Van Jacobson > >>> Subject: New Version Notification for draft-ietf-tcpm-1323bis-14.txt > >>> > >>> > >>> A new version of I-D, draft-ietf-tcpm-1323bis-14.txt has been > >>> successfully submitted by David Borman and posted to the IETF > repository. > >>> > >>> Filename: draft-ietf-tcpm-1323bis > >>> Revision: 14 > >>> Title: TCP Extensions for High Performance > >>> Creation date: 2013-05-23 > >>> Group: tcpm > >>> Number of pages: 46 > >>> URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm- > >>> 1323bis-14.txt > >>> Status: http://datatracker.ietf.org/doc/draft-ietf-tcpm- > 1323bis > >>> Htmlized: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-1= 4 > >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm- > 1323bis- > >>> 14 > >>> > >>> Abstract: > >>> This document specifies a set of TCP extensions to improve > >>> performance over paths with a large bandwidth * delay product and t= o > >>> provide reliable operation over very high-speed paths. It defines > >>> TCP options for scaled windows and timestamps. The timestamps are > >>> used for two distinct mechanisms, RTTM (Round Trip Time Measurement= ) > >>> and PAWS (Protection Against Wrapped Sequences). > >>> > >>> This document updates and obsoletes RFC 1323. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Fri Aug 2 07:26:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFC811E828A for ; Fri, 2 Aug 2013 07:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=-2.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFPGlng3OBuS for ; Fri, 2 Aug 2013 07:26:41 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id C3C5B11E8252 for ; Fri, 2 Aug 2013 07:26:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,801,1367996400"; d="scan'208,217";a="38459922" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 02 Aug 2013 07:26:32 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.105]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 07:26:32 -0700 From: "Scheffenegger, Richard" To: =?gb2312?B?V2lsbGlhbSBDaGFuICizwtbHsv0p?= , "Jerry Chu" Thread-Topic: httpbis chromium data Thread-Index: Ac6Pizj4P9zaLO+iQbmdc5ojqSStkg== Date: Fri, 2 Aug 2013 14:26:31 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C551B4@SACEXCMBX06-PRD.hq.netapp.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: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F25C551B4SACEXCMBX06PRDh_" MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: [tcpm] httpbis chromium data X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 14:26:47 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F25C551B4SACEXCMBX06PRDh_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV2lsbGlhbSwgSmVycnksDQoNCkR1cmluZyB0b2RheaGvcyBwcmVzZW50YXRpb24gaW4gdGhl IGh0dHBiaXMgc2Vzc2lvbiwgYSBDREYvaGlzdG9ncmFtIHdhcyBzaG93biBvZiB0aGUgZWZmZWN0 aXZlIGN3bmQgc2l6ZSBhdCBncmFjZWZ1bCBzZXNzaW9uIGNsb3NlLg0KDQpPbmUgb2YgdGhlIGlu dGVyZXN0aW5nIGZhY3RzIGZyb20gdGhhdCB3YXMgYSBzcGlrZS9wZWFrIGF0IGxhcmdlIHdpbmRv dyBzaXplcyAoMjAwIHBhY2tldHMgSUlSQykuIEl0IHdvdWxkIGJlIGludGVyZXN0aW5nLCBob3cg dGhlc2UgbGFyZ2Ugd2luZG93cyBjYW1lIHRvIGJloa0NCg0KUHJvdmlkZWQgdGhhdCB0aGVzZSBk YXRhICBwb2ludHMgYXJlIG5vdCBpbnZhbGlkIGZvciBzb21lIGRhdGEgY29sbGVjdGlvbiBpc3N1 ZSBzb21ld2hlcmUsIHRoaXMgc2hvdWxkIG9ubHkgYmUgdHJ1ZSBmb3IgdmVyeSBsb25nIGxhdGVu Y2llcyAobGlrZSBicm93c2luZyBmcm9tIEphcGFuIHZpYSBFdXJvcGUgb24gYSBXZXN0LUNvYXN0 IFNlcnZlciksIHZlcnkgaGlnaCBiYW5kd2lkdGhzIChnb29nbGUgZGVwbG95cyBnaWdhYml0LXRv LXRoZS1ob21lIGluIHBsYWNlcywgcmlnaHQpLCBvciBwb3RlbnRpYWxseSB3aGVuIHRoZSB0Y3Ag c2Vzc2lvbiBpcyBhcHBsaWNhdGlvbiBsaW1pdGVkIGJ1dCBjb25zdGFudGx5IHN0YXlzIGJlbG93 IHRoZSBib3R0bGVuZWNrIGJhbmR3aWR0aCwgd2hpbGUgdGhlIE9TIGNvbnRpbnVlcyB0byBpbmNy ZWFzZSB0aGUgY3duZCBvdmVyIG1hbnkgUlRUcyBieSAxIChjb25nZXN0aW9uIGF2b2lkYW5jZSBm bGF3IGluIGFwcC1saW1pdGVkIHN0cmVhbXMgaW4gc29tZSBPUykuDQoNCklmIHRoZSBtYWpvcml0 eSBvZiBzZXNzaW9ucyBlbmQgdXAgaW4gdGhhdCBsYXN0IGJpbiwgdGhhdCBtYXkgYmUgYSBzaWdu aWZpY2FudCBmaW5kaW5nIGZvciBUQ1BNIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZCCoQyBhcyB0 aGlzIHBsYXlzIGludG8gdGhlIGdlbmVyYWwgIGN3bmQgdmFsaWRhdGlvbiBhcmVhIHdoaWNoIGN1 cnJlbnRseSByZWNlaXZlcyBzb21lIGF0dGVudGlvbi4NCg0KT3IgdGhpcyBtaWdodCBiZSBhIGRh dGEgc2FtcGxpbmcgZXJyb3Igc29tZWhvdywgYW5kIHJlcHJlc2VudHMgaW52YWxpZCBkYXRhoa0N Cg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCg0K --_000_012C3117EDDB3C4781FD802A8C27DD4F25C551B4SACEXCMBX06PRDh_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi William, Jerry,

 <= /p>

During tod= ay=A1=AFs presentation in the httpbis session, a CDF/histogram was shown of= the effective cwnd size at graceful session close.

 = ;

One of the= interesting facts from that was a spike/peak at large window sizes (200 pa= ckets IIRC). It would be interesting, how these large windows came to be=A1=AD

 = ;

Provided t= hat these data  points are not invalid for some data collection issue = somewhere, this should only be true for very long latencies (like browsing from Japan via Europe on a West-Coast Server), very high bandwidt= hs (google deploys gigabit-to-the-home in places, right), or potentially wh= en the tcp session is application limited but constantly stays below the bo= ttleneck bandwidth, while the OS continues to increase the cwnd over many RTTs by 1 (congestion avoidance f= law in app-limited streams in some OS).

 = ;

If the maj= ority of sessions end up in that last bin, that may be a significant findin= g for TCPM that should be addressed =A8C as this plays into the general  cwnd validation area which currently receives some attention= .

 = ;

Or this mi= ght be a data sampling error somehow, and represents invalid data=A1=AD

 = ;



 

--_000_012C3117EDDB3C4781FD802A8C27DD4F25C551B4SACEXCMBX06PRDh_-- From pasi.sarolahti@iki.fi Fri Aug 2 08:23:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889721E8096 for ; Fri, 2 Aug 2013 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IjJ9PC-Nc-N for ; Fri, 2 Aug 2013 08:22:55 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id 7464111E80E7 for ; Fri, 2 Aug 2013 08:22:54 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0E8191152E1_1FBCECDB; Fri, 2 Aug 2013 15:22:53 +0000 (GMT) Received: from smtp.netlab.hut.fi (sx2.tct.hut.fi [130.233.154.177]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 42C961152D9_1FBCECCF; Fri, 2 Aug 2013 15:22:52 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 279FB1E15B; Fri, 2 Aug 2013 18:22:52 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v22GW0SWd48G; Fri, 2 Aug 2013 18:22:46 +0300 (EEST) Received: from [213.28.50.90] (gprs-internet-d51c32-90.dhcp.inet.fi [213.28.50.90]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 7F1061E145; Fri, 2 Aug 2013 18:22:46 +0300 (EEST) References: <7852_1375453619_51FBC1B2_7852_112_1_012C3117EDDB3C4781FD802A8C27DD4F25C551B4@SACEXCMBX06-PRD.hq.netapp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7852_1375453619_51FBC1B2_7852_112_1_012C3117EDDB3C4781FD802A8C27DD4F25C551B4@SACEXCMBX06-PRD.hq.netapp.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4717BD8F-D0EC-49D7-84BC-7BF7700EF8AC Content-Transfer-Encoding: 7bit Message-Id: <4D8D1959-8597-469E-BE38-76CAAB795C6A@iki.fi> X-Mailer: iPhone Mail (10B329) From: Pasi Sarolahti Date: Fri, 2 Aug 2013 17:22:41 +0200 To: "Scheffenegger, Richard" Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] httpbis chromium data X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 15:23:02 -0000 --Apple-Mail-4717BD8F-D0EC-49D7-84BC-7BF7700EF8AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2.8.2013, at 16.26, "Scheffenegger, Richard" wrote: > One of the interesting facts from that was a spike/peak at large window si= zes (200 packets IIRC). It would be interesting, how these large windows cam= e to be=E2=80=A6 > =20 > Provided that these data points are not invalid for some data collection i= ssue somewhere, this should only be true for very long latencies (like brows= ing from Japan via Europe on a West-Coast Server), very high bandwidths (goo= gle deploys gigabit-to-the-home in places, right), or potentially when the t= cp session is application limited but constantly stays below the bottleneck b= andwidth, while the OS continues to increase the cwnd over many RTTs by 1 (c= ongestion avoidance flaw in app-limited streams in some OS). There is another possible reason that I find more likely explanation: excess= buffering in the network. - Pasi --Apple-Mail-4717BD8F-D0EC-49D7-84BC-7BF7700EF8AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 2.8.2013, at 16.26, "= Scheffenegger, Richard" <rs@netapp.com> wrote:

One of the interesting facts from tha= t was a spike/peak at large window sizes (200 packets IIRC). It would be int= eresting, how these large windows came to be=E2=80=A6

 <= /o:p>

Provided tha= t these data  points are not invalid for some data collection issue som= ewhere, this should only be true for very long latencies (like browsing from Japan via Europe on a West-Coast Server), very high bandwidth= s (google deploys gigabit-to-the-home in places, right), or potentially when= the tcp session is application limited but constantly stays below the bottl= eneck bandwidth, while the OS continues to increase the cwnd over many RTTs by 1 (congestion avoidance fl= aw in app-limited streams in some OS).


=

= --Apple-Mail-4717BD8F-D0EC-49D7-84BC-7BF7700EF8AC-- From willchan@google.com Fri Aug 2 08:47:41 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3EB11E80DF for ; Fri, 2 Aug 2013 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=-2.349, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_POSSIBLE=2.697, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj8dqqiLo1UB for ; Fri, 2 Aug 2013 08:47:09 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id AE23611E80D3 for ; Fri, 2 Aug 2013 08:47:06 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so1690254oag.10 for ; Fri, 02 Aug 2013 08:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xpMWK4rrkmuxCymL79iS6g9sF7ExBd4artJh8plez9Y=; b=KPXx/ltyP5kvkChxHmJ6mUZWO5ymaJWQ6aHMeFXmRPN7XZ4IRCYg0mPgLxyOC3syAC 7LdpAebteTpUDLTqAVs5bTMBP5AGD5IH9+wAfLhBipG4+mCghi+LB7Yafqmugx0rnOkQ jQHlnDHhRkoRKLRRUKT1wBm0Nh5guS4FmC92fCAC8RnuFAvk7rta2PCp7oAwdg9VCNO/ wDBDUYiTGqMEoVO2LT4/C7kMbuNfIS4UlLi7PNaVaThQajh0BJityQ/Pn7EszzcyZlFS 5+jAquFCte0E0/SlFmkw5nbvO+tQTg/yLT0qJm9oBGFImFD0RXjn0ioIPXQKTl5Kw8VR MC3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xpMWK4rrkmuxCymL79iS6g9sF7ExBd4artJh8plez9Y=; b=WseggSm1JBewcqM5/f85dQw7WuuB/Z1miyx8t+Fa7Zsvk6EotUUdF/lbpDGWeV5LMQ RRGEAdS673+8gDXgji54NcfdF8uZe575ExvIXkbATIfN7keQcXnyMdxCtbyo6xXNLsaF 8Pc2X/8fx6MAWfMdKfsfoZX0z4gEZadBu2duU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=xpMWK4rrkmuxCymL79iS6g9sF7ExBd4artJh8plez9Y=; b=mTqlzBPfAX1MUrFbF1AuSo1XJnItMp3IE9ZGH1baLpTkyg0z/cIUrAAdQnCR8mRTOv cNyuFuXyIhOFXGXz0HgGzP77bAPmw19oXonyYH222niWPEF+rOAWhA3E8bDyn7XxOJmO ew/3L8eR1GXTRkxcnRd4yqzDQY0qzJAq5ROkDzLlQpeAzmK5rXJM1YwS2wK1Gqi7gRpt NsUf42MGJLgmk4SLj5MXpdTdOFBrH+MiQHtKTNHFmKPlcpTK8o+H+EX21/qluT/HT7/G nipxXALq0s9ZKCcDsxOXlPO2Ix/Sc7E7laAxMK29Oz6ihBW4bdQL9DNnlVlU+q0pAk85 obgQ== MIME-Version: 1.0 X-Received: by 10.42.152.4 with SMTP id g4mr644935icw.115.1375458425827; Fri, 02 Aug 2013 08:47:05 -0700 (PDT) Sender: willchan@google.com Received: by 10.64.23.7 with HTTP; Fri, 2 Aug 2013 08:47:05 -0700 (PDT) In-Reply-To: <20130802141529.GA30308@1wt.eu> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130802141529.GA30308@1wt.eu> Date: Fri, 2 Aug 2013 08:47:05 -0700 X-Google-Sender-Auth: asQ_JPXzkT_9IWwyjmAWgKOQ2jA Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Willy Tarreau Content-Type: multipart/alternative; boundary=90e6ba6e873ee01f8704e2f8de8f X-Gm-Message-State: ALoCoQlCIQg2/sZsju/J2Ci5AwEw45toWChMBREy0WrkwLGddDoWHcWDavegi2ZoxYc1KnQ5hKFOgxSNM+fkoMVVOfREisQajLMt+mC1hheruNDXPs1RSuuLD+f1l09CzpiUtLBgMG5QnSSCdvd+F6bK5t+/sJe2VcQS8dZ3PR1RCBB5DtRFpiK32BZkhYA3oRweXIEv01VC Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 15:47:41 -0000 --90e6ba6e873ee01f8704e2f8de8f Content-Type: text/plain; charset=ISO-8859-1 Hey Willy! Your description sounds very familiar. Please see this bug: https://code.google.com/p/chromium/issues/detail?id=85229. I am hesitant to open to the door to turning off preconnect in favor of TFO (although it's definitely on the table). Preconnect has shown substantial improvements in page load time. Indeed, it's one of our hugest improvements ever. But I'm super sensitive to harming servers, and would love to get details from any servers that are encountering issues. Please contact me if you have details to share here. And yes, the concern about the reliability of TFO is totally valid. And that's another reason I'm hesitant to switch preconnect over to TFO because preconnect Just Works from a client's perspective (yes, it may cost the server). Cheers. On Fri, Aug 2, 2013 at 7:15 AM, Willy Tarreau wrote: > Hi William, > > On Fri, Aug 02, 2013 at 06:51:31AM -0700, William Chan (?????????) wrote: > > The short of it is, for vanilla HTTP, it's unclear how beneficial it > would > > be for us since we already have such gains for browser preconnect (our > > browser feature that learns from past web browsing to speculatively > > establish connections, typically just TCP connections but perhaps doing a > > TLS or other handshakes too as needed). > > That's pretty interesting. Is this already enabled by default ? I'm asking > because I've got several users of haproxy report me that their web site was > regularly "attacked" by many connections in which no request is sent, and > that because of this they had to increase the number of concurrent > connections > otherwise they can't stand the load. I asked if they thought it could be > something like a bug in some JS application or something like this as I was > no aware of the preconnect feature. It's been a bit hard to analyse, since > they see no request, they can't get any information on the user agent for > example. The thing is that it does not look like a regular attack since the > load is more or less constant, and not very high. So till now it was always > possible to work around this by increasing the connection limits 2-10 > times. > > But now I'm thinking that *if it was a preconnect behaviour*, there could > possibly be some harm there. I have no idea how many connections a browser > can send to recently visited sites, but for sites which use a short > keep-alive > timeout to limit the concurrency, having a significant increase on the > number > of concurrent connections can be a problem. > > Note that I'm talking using a conditional form, as I can't provide evidence > for this to be related to a preconnect feature, but your description really > matches what I observed, and I am really wondering about the risks and > possibile impacts based on something that could appear related. If the > increase in connection count may be significant for small sites, then maybe > TFO could be a decent alternative (though it will clearly not pass through > every firewall). > > Best regards, > Willy > > --90e6ba6e873ee01f8704e2f8de8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey Willy!

I am hesitant to open to the door to turning off precon= nect in favor of TFO (although it's definitely on the table). Preconnec= t has shown substantial improvements in page load time. Indeed, it's on= e of our hugest improvements ever. But I'm super sensitive to harming s= ervers, and would love to get details from any servers that are encounterin= g issues. Please contact me if you have details to share here.

And yes, the concern about the reliability of TFO is to= tally valid. And that's another reason I'm hesitant to switch preco= nnect over to TFO because preconnect Just Works from a client's perspec= tive (yes, it may cost the server).

Cheers.


<= div class=3D"gmail_quote">On Fri, Aug 2, 2013 at 7:15 AM, Willy Tarreau <w@1wt.eu> wrote:
Hi William,

On Fri, Aug 02, 2013 at 06:51:31AM -0700, William Chan (?????????) wrote: > The short of it is, for vanilla HTTP, it's unclear how beneficial = it would
> be for us since we already have such gains for browser preconnect (our=
> browser feature that learns from past web browsing to speculatively > establish connections, typically just TCP connections but perhaps doin= g a
> TLS or other handshakes too as needed).

That's pretty interesting. Is this already enabled by default ? I= 'm asking
because I've got several users of haproxy report me that their web site= was
regularly "attacked" by many connections in which no request is s= ent, and
that because of this they had to increase the number of concurrent connecti= ons
otherwise they can't stand the load. I asked if they thought it could b= e
something like a bug in some JS application or something like this as I was=
no aware of the preconnect feature. It's been a bit hard to analyse, si= nce
they see no request, they can't get any information on the user agent f= or
example. The thing is that it does not look like a regular attack since the=
load is more or less constant, and not very high. So till now it was always=
possible to work around this by increasing the connection limits 2-10 times= .

But now I'm thinking that *if it was a preconnect behaviour*, there cou= ld
possibly be some harm there. I have no idea how many connections a browser<= br> can send to recently visited sites, but for sites which use a short keep-al= ive
timeout to limit the concurrency, having a significant increase on the numb= er
of concurrent connections can be a problem.

Note that I'm talking using a conditional form, as I can't provide = evidence
for this to be related to a preconnect feature, but your description really=
matches what I observed, and I am really wondering about the risks and
possibile impacts based on something that could appear related. If the
increase in connection count may be significant for small sites, then maybe=
TFO could be a decent alternative (though it will clearly not pass through<= br> every firewall).

Best regards,
Willy


--90e6ba6e873ee01f8704e2f8de8f-- From touch@isi.edu Fri Aug 2 09:36:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74521E80F5 for ; Fri, 2 Aug 2013 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.01 X-Spam-Level: X-Spam-Status: No, score=-104.01 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TUrbsnPklbV for ; Fri, 2 Aug 2013 09:36:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A7B5B21E80E1 for ; Fri, 2 Aug 2013 09:36:07 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r72GZgS7003886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 09:35:42 -0700 (PDT) Message-ID: <51FBDFDE.8030900@isi.edu> Date: Fri, 02 Aug 2013 09:35:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-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 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 16:36:13 -0000 On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: ... > As there have been multiple comments to describe the effects of this > SHOULD, the following paragraph was added right after. This is new text, > and the first throw. Text donations are highly appreciated if this text > does not capture the purpose to the required extent: > > > Implementations are strongly encouraged to follow the above rules for > handling a missing Timestamps option, and the order of precedence > mentioned in Section 4.3 when deciding on the acceptance of a > segment. This is to maintain the integrity of the payload data at > the receiver in particular on high speed networks. However, it has > been mentioned that under some circumstances, the above guidelines > are too strict, and some paths sporadically suppress the Timestamps > option, while maintaining payload integrity. A path behaving in this > manner should be deemed inacceptable, but it has been noted that > relaxing the acceptance rules can serve as a workaround, and allows > TCP to run across such paths. This misses the key issue, and it should not be glossed-over. A TCP that SHOULD drop segment missing an expected TSOpt (as when TS is negotiated during the SYN) MAY experience ***undetectable*** wrapped-sequence effects. A TCP that MUST drop such segments WILL NOT experience such effects. So relaxing this constraint turns PAWS protection from a guarantee to a maybe - and it does so in ways that the source cannot determine. The source presumably asked for PAWS, and the receiver agreed to it, but that guarantee is being turned into a maybe. The big problem with allowing this SHOULD is it thus turns all TS requests into "no PAWS provided". So you've just killed PAWS. Another victory for "rough consensus". Joe From touch@isi.edu Fri Aug 2 10:47:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228E611E8116 for ; Fri, 2 Aug 2013 10:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.936 X-Spam-Level: X-Spam-Status: No, score=-105.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtFA-F0TuR5w for ; Fri, 2 Aug 2013 10:47:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 491DE11E80E7 for ; Fri, 2 Aug 2013 10:47:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r72HkfLQ018843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Aug 2013 10:46:41 -0700 (PDT) Message-ID: <51FBF080.7030105@isi.edu> Date: Fri, 02 Aug 2013 10:46:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Lahey References: <655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <51FAF516.1020308@isi.edu> <9905EC63-1273-472E-9815-B00141B385D1@oracle.com> In-Reply-To: <9905EC63-1273-472E-9815-B00141B385D1@oracle.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 Cc: tcpm@ietf.org Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 17:47:14 -0000 On 8/1/2013 11:53 PM, Kevin Lahey wrote: > On Aug 2, 2013, at 1:53 AM, Joe Touch wrote: > >> On 7/31/2013 11:07 PM, Kevin Lahey wrote: >>> It would be nice if,... we could say, "Read RFC8888 for the on-wire protocol >>> details, and RFC8889 for the congestion control details." >> >> It would be nicer, IMO, if we could avoid the erroneous concept of "on the wire" as meaningful. > > And, yet, it's kind of useful to know what I'm seeing when I look at a packet trace. :-) Agreed. I didn't see that as your goal, though. I agree it's useful to have a section on the packet format, e.g., for wireshark and tcpdump implementers. However, the "on the wire" vs. "cong control" difference typically differentiates critical protocol functionality from performance optimization - either for the health of the net or for better individual connection performance. Regardless, IMO the term "on the wire" is one we ought to know better than to use, at least because of the ambiguity it presents. ... > Sorry to get you started, Joe -- I was casually trying to suggest > thatwe didn't necessarily need one all-singing, all-dancing RFC to combine > all of the different TCP RFCs. Dividing it up along reasonable lines > would allow for easier updates, etc. If you do, where do you start looking? We clearly need a roadmap to start. That then argues for a hierarchical roadmap, but IMO that's going to be nearly impossible to do orthogonally. I see a lot of docs that might end up being in most partitions that might result, which means that updating one RFC then updates many of these partitions. That might be more work than updating a single, unifying roadmap. Joe From rs@netapp.com Fri Aug 2 11:17:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41EB11E8134 for ; Fri, 2 Aug 2013 11:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-2.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mpc8POPc8j3 for ; Fri, 2 Aug 2013 11:17:27 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id B1C2111E8136 for ; Fri, 2 Aug 2013 11:17:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,802,1367996400"; d="scan'208,217";a="38504930" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 02 Aug 2013 11:17:22 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.105]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 11:17:22 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti Thread-Topic: [tcpm] httpbis chromium data Thread-Index: AQHOj5Q/6fz7xp1qNkOsYb4GA4MIppmCOecn Date: Fri, 2 Aug 2013 18:17:22 +0000 Message-ID: <346E0AE5-CA39-4120-B9FE-115D4112986F@netapp.com> References: <7852_1375453619_51FBC1B2_7852_112_1_012C3117EDDB3C4781FD802A8C27DD4F25C551B4@SACEXCMBX06-PRD.hq.netapp.com>, <4D8D1959-8597-469E-BE38-76CAAB795C6A@iki.fi> In-Reply-To: <4D8D1959-8597-469E-BE38-76CAAB795C6A@iki.fi> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_346E0AE5CA394120B9FE115D4112986Fnetappcom_" MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] httpbis chromium data X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 18:17:33 -0000 --_000_346E0AE5CA394120B9FE115D4112986Fnetappcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgcGFzaSwNCg0KVGhhdCBzaG91bGQgc2hvdyB1cCBhcyBleGNlc3NpdmUgcGF0aCBsYXRlbmN5 IC0gYXMgaSBzYWlkIGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGtub3cgd2hpY2ggb2YgdGhl IHRocmVlIGlzIHJlc3BvbnNpYmxlIGluIHdoYXQgZnJhY3Rpb24hDQoNCkJlc3QgcmVnYXJkcywN CiAgIFJpY2hhcmQNCg0KVm9uIG1laW5lbSBpUGhvbmUgZ2VzZW5kZXQNCg0KQW0gMDIuMDguMjAx MyB1bSAxNzoyMyBzY2hyaWViICJQYXNpIFNhcm9sYWh0aSIgPHBhc2kuc2Fyb2xhaHRpQGlraS5m aTxtYWlsdG86cGFzaS5zYXJvbGFodGlAaWtpLmZpPj46DQoNCg0KT24gMi44LjIwMTMsIGF0IDE2 LjI2LCAiU2NoZWZmZW5lZ2dlciwgUmljaGFyZCIgPHJzQG5ldGFwcC5jb208bWFpbHRvOnJzQG5l dGFwcC5jb20+PiB3cm90ZToNCg0KT25lIG9mIHRoZSBpbnRlcmVzdGluZyBmYWN0cyBmcm9tIHRo YXQgd2FzIGEgc3Bpa2UvcGVhayBhdCBsYXJnZSB3aW5kb3cgc2l6ZXMgKDIwMCBwYWNrZXRzIElJ UkMpLiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZywgaG93IHRoZXNlIGxhcmdlIHdpbmRvd3MgY2Ft ZSB0byBiZaGtDQoNClByb3ZpZGVkIHRoYXQgdGhlc2UgZGF0YSAgcG9pbnRzIGFyZSBub3QgaW52 YWxpZCBmb3Igc29tZSBkYXRhIGNvbGxlY3Rpb24gaXNzdWUgc29tZXdoZXJlLCB0aGlzIHNob3Vs ZCBvbmx5IGJlIHRydWUgZm9yIHZlcnkgbG9uZyBsYXRlbmNpZXMgKGxpa2UgYnJvd3NpbmcgZnJv bSBKYXBhbiB2aWEgRXVyb3BlIG9uIGEgV2VzdC1Db2FzdCBTZXJ2ZXIpLCB2ZXJ5IGhpZ2ggYmFu ZHdpZHRocyAoZ29vZ2xlIGRlcGxveXMgZ2lnYWJpdC10by10aGUtaG9tZSBpbiBwbGFjZXMsIHJp Z2h0KSwgb3IgcG90ZW50aWFsbHkgd2hlbiB0aGUgdGNwIHNlc3Npb24gaXMgYXBwbGljYXRpb24g bGltaXRlZCBidXQgY29uc3RhbnRseSBzdGF5cyBiZWxvdyB0aGUgYm90dGxlbmVjayBiYW5kd2lk dGgsIHdoaWxlIHRoZSBPUyBjb250aW51ZXMgdG8gaW5jcmVhc2UgdGhlIGN3bmQgb3ZlciBtYW55 IFJUVHMgYnkgMSAoY29uZ2VzdGlvbiBhdm9pZGFuY2UgZmxhdyBpbiBhcHAtbGltaXRlZCBzdHJl YW1zIGluIHNvbWUgT1MpLg0KDQpUaGVyZSBpcyBhbm90aGVyIHBvc3NpYmxlIHJlYXNvbiB0aGF0 IEkgZmluZCBtb3JlIGxpa2VseSBleHBsYW5hdGlvbjogZXhjZXNzIGJ1ZmZlcmluZyBpbiB0aGUg bmV0d29yay4NCg0KLSBQYXNpDQoNCg== --_000_346E0AE5CA394120B9FE115D4112986Fnetappcom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi pasi,

That should show up as excessive path latency - as i said it would be = interesting to know which of the three is responsible in what fraction!

Best regards,
   Richard

Von meinem iPhone gesendet

On 2.8.2013, at 16.26, "Scheffenegger, Richard" <rs@netapp.com> wrote:

One of the interesting facts from = that was a spike/peak at large window sizes (200 packets IIRC). It would be= interesting, how these large windows came to be=A1=AD

 = ;

Provided t= hat these data  points are not invalid for some data collection issue = somewhere, this should only be true for very long latencies (like browsing from Japan via Europe on a West-Coast Server), very high bandwidt= hs (google deploys gigabit-to-the-home in places, right), or potentially wh= en the tcp session is application limited but constantly stays below the bo= ttleneck bandwidth, while the OS continues to increase the cwnd over many RTTs by 1 (congestion avoidance f= law in app-limited streams in some OS).


There is another possible reason that I find more likely explanation: = excess buffering in the network.

- Pasi

--_000_346E0AE5CA394120B9FE115D4112986Fnetappcom_-- From w@1wt.eu Fri Aug 2 07:15:42 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28021E80AB for ; Fri, 2 Aug 2013 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-5.481, BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK-WDSzSUFmI for ; Fri, 2 Aug 2013 07:15:37 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2221E8083 for ; Fri, 2 Aug 2013 07:15:36 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r72EFTKf030848; Fri, 2 Aug 2013 16:15:29 +0200 Date: Fri, 2 Aug 2013 16:15:29 +0200 From: Willy Tarreau To: "William Chan (?????????)" Message-ID: <20130802141529.GA30308@1wt.eu> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sat, 03 Aug 2013 11:52:43 -0700 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 14:15:42 -0000 Hi William, On Fri, Aug 02, 2013 at 06:51:31AM -0700, William Chan (?????????) wrote: > The short of it is, for vanilla HTTP, it's unclear how beneficial it would > be for us since we already have such gains for browser preconnect (our > browser feature that learns from past web browsing to speculatively > establish connections, typically just TCP connections but perhaps doing a > TLS or other handshakes too as needed). That's pretty interesting. Is this already enabled by default ? I'm asking because I've got several users of haproxy report me that their web site was regularly "attacked" by many connections in which no request is sent, and that because of this they had to increase the number of concurrent connections otherwise they can't stand the load. I asked if they thought it could be something like a bug in some JS application or something like this as I was no aware of the preconnect feature. It's been a bit hard to analyse, since they see no request, they can't get any information on the user agent for example. The thing is that it does not look like a regular attack since the load is more or less constant, and not very high. So till now it was always possible to work around this by increasing the connection limits 2-10 times. But now I'm thinking that *if it was a preconnect behaviour*, there could possibly be some harm there. I have no idea how many connections a browser can send to recently visited sites, but for sites which use a short keep-alive timeout to limit the concurrency, having a significant increase on the number of concurrent connections can be a problem. Note that I'm talking using a conditional form, as I can't provide evidence for this to be related to a preconnect feature, but your description really matches what I observed, and I am really wondering about the risks and possibile impacts based on something that could appear related. If the increase in connection count may be significant for small sites, then maybe TFO could be a decent alternative (though it will clearly not pass through every firewall). Best regards, Willy From w@1wt.eu Fri Aug 2 08:59:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3374521E80AA for ; Fri, 2 Aug 2013 08:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.568 X-Spam-Level: X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=-3.525, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NADpQ6+Z7Awh for ; Fri, 2 Aug 2013 08:59:25 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB111E80C5 for ; Fri, 2 Aug 2013 08:59:23 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r72Fx9Fk031418; Fri, 2 Aug 2013 17:59:09 +0200 Date: Fri, 2 Aug 2013 17:59:09 +0200 From: Willy Tarreau To: "William Chan (?????????)" Message-ID: <20130802155909.GB30308@1wt.eu> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20130802141529.GA30308@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sat, 03 Aug 2013 11:52:43 -0700 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 15:59:30 -0000 On Fri, Aug 02, 2013 at 08:47:05AM -0700, William Chan (?????????) wrote: > Hey Willy! > > Your description sounds very familiar. Please see this bug: > https://code.google.com/p/chromium/issues/detail?id=85229. Indeed, thanks for the link. Next time I get such a report, I'll pass it. > I am hesitant to open to the door to turning off preconnect in favor of TFO > (although it's definitely on the table). Preconnect has shown substantial > improvements in page load time. Indeed, it's one of our hugest improvements > ever. But I'm super sensitive to harming servers, and would love to get > details from any servers that are encountering issues. Please contact me if > you have details to share here. No problem. Till now that was only speculation by me but as you can guess it's quite hard to get anything relevant in this situation. Also, users who experience this tend to enable logging for the first time while debugging the issue, so you cannot even compare the IP address with the last that was logged to get info about the UA. > And yes, the concern about the reliability of TFO is totally valid. And > that's another reason I'm hesitant to switch preconnect over to TFO because > preconnect Just Works from a client's perspective (yes, it may cost the > server). I understand. I still find that TFO has some uses on the local network, to save round trips and packets, in fact to make it as cheap as a keep-alive connection, but with less permanent states. I intend to experiment with it between haproxy and some static servers for example. It can be nice between clients and proxies probably. I'm having some ideas that could be interesting to investigate with preconnect. Indeed, instead of keeping a connection in idle for a long time, maybe sending an "OPTIONS * HTTP/1.1" request would be useful : 1) it would allow the server to know the UA 2) it would make the server switch to the keep-alive timeout instead of the request timeout, meaning that the connections would probably be maintained less time (at least the server would regain the control over the connection time). 3) a loaded server could still disable keep-alive or block these requests and save vast amounts of resources 4) if combined with TFO, you'd get the information in advance about TFO support along the path :-) If "OPTIONS * HTTP/1.1" doesn't work often enough, then maybe sending a "GET /favicon.ico" would be more appropriate (and the response could be cached BTW, saving one round trip later). Just a few ideas :-) Willy From phk@phk.freebsd.dk Fri Aug 2 13:56:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8111E80D2 for ; Fri, 2 Aug 2013 13:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeIL1Nslz23e for ; Fri, 2 Aug 2013 13:56:04 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by ietfa.amsl.com (Postfix) with ESMTP id 900A821E8086 for ; Fri, 2 Aug 2013 13:56:04 -0700 (PDT) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 805693EB5D; Fri, 2 Aug 2013 20:56:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r72Ku1ru011942; Fri, 2 Aug 2013 20:56:01 GMT (envelope-from phk@phk.freebsd.dk) To: "Scharf, Michael (Michael)" In-reply-to: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: "Poul-Henning Kamp" References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 02 Aug 2013 20:56:01 +0000 Message-ID: <11941.1375476961@critter.freebsd.dk> X-Mailman-Approved-At: Sat, 03 Aug 2013 11:52:43 -0700 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 20:56:10 -0000 In message <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-l ucent.com>, "Scharf, Michael (Michael)" writes: >As mentioned today on the mic, the TCPM working group has a working group >item that allows data to be carried in the SYN and SYN-ACK packets and that >is consumed by the receiving end during the initial connection handshake, Uhm, didn't we try that once with TTCP only to find out that it opened a major DoS hole ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nico@cryptonector.com Fri Aug 2 14:16:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7314721E8094 for ; Fri, 2 Aug 2013 14:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPUQLx1PLGsO for ; Fri, 2 Aug 2013 14:16:01 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACC411E80D7 for ; Fri, 2 Aug 2013 14:16:00 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 31EF477807B for ; Fri, 2 Aug 2013 14:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Z8K+vx3Tr4VUi3uTHvCh KXthWgU=; b=wjxCegz4RnZKo/7LZAxxUiufO9MgK1h7L0WyOv50sNKFSUELsZXE a0LN0HKK7eKAiPsHYZlAX9gXc992XKOO3WBc0//5fc4QI1NL1nCDxDaHf31Q7L89 x/obXGAcwgAAJ5D/pbo2GkuMfzIHmxQEP89afGQNatdrg7cv5ZpAk1k= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id C3CD577807A for ; Fri, 2 Aug 2013 14:15:59 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x55so925120wes.18 for ; Fri, 02 Aug 2013 14:15:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cFKLtrxD4h2mdqOc1eJ6FMTgPxsFgYtQVy3M5WBl3uk=; b=Z/LbHo3HU1mHHRAfWJ9GaitfGrDXhDTy/+g8eaXcb1t5Dxslry2fLPhaDjdN5eJUTY Y52cw3v7YpYhJqHFCk6NC35ZJNft4v2lPVAK8xA8d3sQcMgi8fq3z/YSUcay9W+R+COx 8UOnQaSYdnzLc/CWvoYkZX/grjAZmdWOOhdsQXCLOSNaO9cpfFLsyXWmFJWHgMT5tTR5 g4ur5bDw1RpV+z1zuNsZwukttrFX1S65vXa3htEFhLoOJYsZPQ6pZdyFMRP4r1HV5lcH fxKylZPcsEVqOfo7Hc5BxRUKuZ/TbUTKTmo4x9g0b0/lICcrGuaL7bjuj6QUVjabn//u mUGw== MIME-Version: 1.0 X-Received: by 10.180.79.161 with SMTP id k1mr106055wix.36.1375478158357; Fri, 02 Aug 2013 14:15:58 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Fri, 2 Aug 2013 14:15:58 -0700 (PDT) In-Reply-To: <11941.1375476961@critter.freebsd.dk> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> <11941.1375476961@critter.freebsd.dk> Date: Fri, 2 Aug 2013 16:15:58 -0500 Message-ID: From: Nico Williams To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 03 Aug 2013 11:52:43 -0700 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 21:16:05 -0000 On Fri, Aug 2, 2013 at 3:56 PM, Poul-Henning Kamp wrote: > In message <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-l > ucent.com>, "Scharf, Michael (Michael)" writes: > >>As mentioned today on the mic, the TCPM working group has a working group >>item that allows data to be carried in the SYN and SYN-ACK packets and that >>is consumed by the receiving end during the initial connection handshake, > > Uhm, didn't we try that once with TTCP only to find out that it > opened a major DoS hole ? This one is different. You must have done one normal exchange and exchange "key material" (cached on both ends, free to fall off the cache at any time) to be used for fast opens. Nico -- From bizzbyster@gmail.com Fri Aug 2 16:19:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC911E8137 for ; Fri, 2 Aug 2013 16:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrl8tEXfBPH4 for ; Fri, 2 Aug 2013 16:19:44 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5791311E8144 for ; Fri, 2 Aug 2013 16:19:44 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oy10so1346736veb.20 for ; Fri, 02 Aug 2013 16:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JBAXuG/q7gwrMsCTaVt5DkBJ4lK0k+SCNBXN4jfh7oE=; b=AQmq59TggtFmQp98katchPNlp43xEBft9cszGe403b+8Y705mP2Z6l6EGDMRYqP2nn RhhcRejWKMplVooTuUFkDhKbsu8lzpI4DIGLMLIw6Ue2G51lNQHwSxm3cyNMom4IAF4G 7twLdW61gNfhXw1a76KVAW8nJNbPU8xGOVaTeSpAQx8azH4aY1z/dg7ARnK3STnZv7m7 L4V+bfsHE1ohtmA+DrDJd3OZQFDDX8HxHvCOk+rQvVUNftn4JiV10WyfT5On0Ie5OTHK jYKxa62UjGF5uunseFzT+qg6NZlX3ec5Bl/2yLyUpPHOg8+EmOXbiQUUvKHdEMRIiOiT EAiQ== MIME-Version: 1.0 X-Received: by 10.58.249.236 with SMTP id yx12mr2777505vec.25.1375485583711; Fri, 02 Aug 2013 16:19:43 -0700 (PDT) Received: by 10.58.233.115 with HTTP; Fri, 2 Aug 2013 16:19:43 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> <11941.1375476961@critter.freebsd.dk> Date: Fri, 2 Aug 2013 19:19:43 -0400 Message-ID: From: Peter Lepeska To: Nico Williams Content-Type: multipart/alternative; boundary=047d7bacc0969c635c04e2ff3148 X-Mailman-Approved-At: Sat, 03 Aug 2013 11:52:43 -0700 Cc: Poul-Henning Kamp , "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Aug 2013 23:19:45 -0000 --047d7bacc0969c635c04e2ff3148 Content-Type: text/plain; charset=ISO-8859-1 "it's unclear how beneficial it would > be for us since we already have such gains for browser preconnect (our > browser feature that learns from past web browsing to speculatively > establish connections, typically just TCP connections but perhaps doing a > TLS or other handshakes too as needed)" It would benefit any time you encounter a host that preconnect has not learned about yet. Surely this provides a benefit. It also has lower cost since it will result in fewer (zero) connection mistakes since it's not doing anything speculatively. Don't get me wrong I'm a big fan of the benefits of speculative prefetching in general, but only in the case where the underlying protocol can't solve the problem without mistakes. TCP Fast Open seems great as long as it doesn't introduce any other problems (such as increased DoS vulnerability). Peter Peter On Fri, Aug 2, 2013 at 5:15 PM, Nico Williams wrote: > On Fri, Aug 2, 2013 at 3:56 PM, Poul-Henning Kamp > wrote: > > In message > <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-l > > ucent.com>, "Scharf, Michael (Michael)" writes: > > > >>As mentioned today on the mic, the TCPM working group has a working group > >>item that allows data to be carried in the SYN and SYN-ACK packets and > that > >>is consumed by the receiving end during the initial connection handshake, > > > > Uhm, didn't we try that once with TTCP only to find out that it > > opened a major DoS hole ? > > This one is different. You must have done one normal exchange and > exchange "key material" (cached on both ends, free to fall off the > cache at any time) to be used for fast opens. > > Nico > -- > > --047d7bacc0969c635c04e2ff3148 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"it's unclear how beneficial it would<= br style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"= >> be for us since we already have such gains for browser preconnect= (our
> browser feature that learns from past web browsing to speculativel= y
> establish connections, typically just TCP connections but perhaps = doing a
> TLS or other handshakes too as needed)"

It would benefit any time you encounter a host that preconnec= t has not learned about yet. Surely this provides a benefit. It also has lo= wer cost since it will result in fewer (zero) connection mistakes since it&= #39;s not doing anything speculatively. Don't get me wrong I'm a bi= g fan of the benefits of speculative prefetching in general, but only in th= e case where the underlying protocol can't solve the problem without mi= stakes.

TCP Fast Open seems gre= at as long as it doesn't introduce any other problems (such as increase= d DoS vulnerability).

Peter

Peter



On Fri, Aug 2, 2013 at 5:15 PM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Fri, Aug 2, 2013 at 3:5= 6 PM, Poul-Henning Kamp <phk@phk.f= reebsd.dk> wrote:
> In message <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.z= eu.alcatel-l
> ucent.com>, &quo= t;Scharf, Michael (Michael)" writes:
>
>>As mentioned today on the mic, the TCPM working group has a working= group
>>item that allows data to be carried in the SYN and SYN-ACK packets = and that
>>is consumed by the receiving end during the initial connection hand= shake,
>
> Uhm, didn't we try that once with TTCP only to find out that it > opened a major DoS hole ?

This one is different. =A0You must have done one normal exchange and<= br> exchange "key material" (cached on both ends, free to fall off th= e
cache at any time) to be used for fast opens.

Nico
--


--047d7bacc0969c635c04e2ff3148-- From adrien@qbik.com Sat Aug 3 17:00:50 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C5C21F9E76 for ; Sat, 3 Aug 2013 17:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0UqKjq5HNkd for ; Sat, 3 Aug 2013 17:00:45 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA721E8064 for ; Sat, 3 Aug 2013 17:00:44 -0700 (PDT) Received: From SCREECH.qbik.local (unverified [192.168.0.4]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4601)) with SMTP id <0019812491@smtp.qbik.com>; Sun, 04 Aug 2013 12:00:41 +1200 Received: From [192.168.0.23] (unverified [192.168.0.23]) by SMTP Server [192.168.0.4] (WinGate SMTP Receiver v8.0.0 (Build 4601)) with SMTP id <0000261086@SCREECH.qbik.local>; Sun, 04 Aug 2013 12:00:40 +1200 From: "Adrien de Croy" To: "Willy Tarreau" , "William Chan (?????????)" Date: Sun, 04 Aug 2013 00:00:40 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <20130802141529.GA30308@1wt.eu> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18025.0 X-Mailman-Approved-At: Sun, 04 Aug 2013 08:42:48 -0700 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 00:00:50 -0000 we get tech support queries about this as well... "what are all these connections without a URL showing in activity". Nice little tech support ticket generator feature. We figured it was pre-emtive connecting, since eventually a request may=20 be made on the connection. ------ Original Message ------ From: "Willy Tarreau" To: "William Chan (?????????)" Cc: "Scharf, Michael (Michael)" ;=20 "ietf-http-wg@w3.org" ; "tcpm@ietf.org"=20 Sent: 3/08/2013 2:15:29 a.m. Subject: Re: Feedback on TCP Fast Open? >Hi William, > >On Fri, Aug 02, 2013 at 06:51:31AM -0700, William Chan (?????????)=20 >wrote: >> The short of it is, for vanilla HTTP, it's unclear how beneficial it= =20 >>would >> be for us since we already have such gains for browser preconnect=20 >>(our >> browser feature that learns from past web browsing to speculatively >> establish connections, typically just TCP connections but perhaps=20 >>doing a >> TLS or other handshakes too as needed). > >That's pretty interesting. Is this already enabled by default ? I'm=20 >asking >because I've got several users of haproxy report me that their web site= =20 >was >regularly "attacked" by many connections in which no request is sent,=20 >and >that because of this they had to increase the number of concurrent=20 >connections >otherwise they can't stand the load. I asked if they thought it could=20 >be >something like a bug in some JS application or something like this as I= =20 >was >no aware of the preconnect feature. It's been a bit hard to analyse,=20 >since >they see no request, they can't get any information on the user agent=20 >for >example. The thing is that it does not look like a regular attack since= =20 >the >load is more or less constant, and not very high. So till now it was=20 >always >possible to work around this by increasing the connection limits 2-10=20 >times. > >But now I'm thinking that *if it was a preconnect behaviour*, there=20 >could >possibly be some harm there. I have no idea how many connections a=20 >browser >can send to recently visited sites, but for sites which use a short=20 >keep-alive >timeout to limit the concurrency, having a significant increase on the=20 >number >of concurrent connections can be a problem. > >Note that I'm talking using a conditional form, as I can't provide=20 >evidence >for this to be related to a preconnect feature, but your description=20 >really >matches what I observed, and I am really wondering about the risks and >possibile impacts based on something that could appear related. If the >increase in connection count may be significant for small sites, then=20 >maybe >TFO could be a decent alternative (though it will clearly not pass=20 >through >every firewall). > >Best regards, >Willy > > From rs@netapp.com Mon Aug 5 02:34:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A2121F9DBB for ; Mon, 5 Aug 2013 02:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.568 X-Spam-Level: X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[AWL=3.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeSdopXHfeAR for ; Mon, 5 Aug 2013 02:33:53 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id BD40021F9E22 for ; Mon, 5 Aug 2013 02:32:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,817,1367996400"; d="scan'208";a="78539775" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 05 Aug 2013 02:32:37 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.105]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Mon, 5 Aug 2013 02:32:37 -0700 From: "Scheffenegger, Richard" To: Joe Touch Thread-Topic: [tcpm] draft-ietf-tcpm-1323bis-14.txt Thread-Index: AQHOhlJ0mDsCw3frk0+Y7NXoRQhe4Jl8AbGAgAX5QeCAAKpqAIADx6jQ Date: Mon, 5 Aug 2013 09:32:36 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-PRD.hq.netapp.com> References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> <51FBDFDE.8030900@isi.edu> In-Reply-To: <51FBDFDE.8030900@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 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 09:34:13 -0000 Hi Joe, Thank you for your input! I reworded the paragraph slightly. With my background in data storage, the = one thing to avoid is silent data corruption (storage companies are general= ly very paranoid about that), thus the use of "data corruption" twice in th= e text below. That wording may nudge market forces to weed out the "best ef= fort" PAWS implementations over time. That would agreeably be an improvemen= t above the current state. Implementations are strongly encouraged to follow the above rules = for=20 handling a missing Timestamps option, and the order of precedence=20 mentioned in when deciding on the acceptanc= e of a=20 segment. A TCP receiver not dropping segments without an expected=20 Timestamps option may expirience *undetectable* wrapped-sequence effe= cts,=20 such as data (payload) corruption or session stalls. In order to main= tain=20 the integrity of the payload data, in particular on high speed networ= ks,=20 it is paramount to follow the described processing rules. =20 However, it has been mentioned that under some circumstances, the = above=20 guidelines are too strict, and some paths sporadically suppress the=20 Timestamps option, while maintaining payload integrity. A path behavi= ng in=20 this manner should be deemed inacceptable, but it has been noted that= some=20 implementations relax the acceptance rules as a workaround, and allow= TCP=20 to run across such paths. Again, if a receiver chooses to accept a se= gment=20 without an expected Timestamps option, it must be clear that undetect= able=20 data corruption may occur.=20 Richard Scheffenegger > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Freitag, 02. August 2013 18:36 > To: Scheffenegger, Richard > Cc: Yuchung Cheng; Pasi Sarolahti; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >=20 >=20 >=20 > On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: > ... > > As there have been multiple comments to describe the effects of this > > SHOULD, the following paragraph was added right after. This is new > > text, and the first throw. Text donations are highly appreciated if > > this text does not capture the purpose to the required extent: > > > > > > Implementations are strongly encouraged to follow the above rules > for > > handling a missing Timestamps option, and the order of precedence > > mentioned in Section 4.3 when deciding on the acceptance of a > > segment. This is to maintain the integrity of the payload data at > > the receiver in particular on high speed networks. However, it has > > been mentioned that under some circumstances, the above guidelines > > are too strict, and some paths sporadically suppress the Timestamps > > option, while maintaining payload integrity. A path behaving in > this > > manner should be deemed inacceptable, but it has been noted that > > relaxing the acceptance rules can serve as a workaround, and allows > > TCP to run across such paths. >=20 > This misses the key issue, and it should not be glossed-over. >=20 > A TCP that SHOULD drop segment missing an expected TSOpt (as when TS is > negotiated during the SYN) MAY experience ***undetectable*** wrapped- > sequence effects. >=20 > A TCP that MUST drop such segments WILL NOT experience such effects. >=20 > So relaxing this constraint turns PAWS protection from a guarantee to a > maybe - and it does so in ways that the source cannot determine. The > source presumably asked for PAWS, and the receiver agreed to it, but that > guarantee is being turned into a maybe. >=20 > The big problem with allowing this SHOULD is it thus turns all TS request= s > into "no PAWS provided". >=20 > So you've just killed PAWS. >=20 > Another victory for "rough consensus". >=20 > Joe From michael.scharf@alcatel-lucent.com Mon Aug 5 04:51:18 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF2721F9C78 for ; Mon, 5 Aug 2013 04:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, GB_I_INVITATION=-2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBCT1VJg3pGY for ; Mon, 5 Aug 2013 04:51:09 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BB2AA21F9AD2 for ; Mon, 5 Aug 2013 04:51:06 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r75Bp3RB019486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2013 06:51:05 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r75Bp0AY007155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 13:51:00 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 5 Aug 2013 13:51:00 +0200 From: "Scharf, Michael (Michael)" To: =?gb2312?B?V2lsbGlhbSBDaGFuICizwtbHsv0p?= Thread-Topic: Feedback on TCP Fast Open? Thread-Index: Ac6PaI4pnwTAopi7RjGsw4hp5IioMgADhLSAAJaUk2A= Date: Mon, 5 Aug 2013 11:50:59 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07DE77@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 11:51:18 -0000 SGkgV2lsbCAoYW5kIHRoZSBvdGhlcnMgaW4gdGhpcyB0aHJlYWQpLA0KDQpUaGFua3MgYSBsb3Qg Zm9yIHRoaXMgZXhjZWxsZW50IGZlZWRiYWNrIGFuZCB0aGUgaW5zaWdodHMhIFRoaXMgaXMgdmVy eSBtdWNoIGFwcHJlY2lhdGVkLg0KDQpAQXV0aG9yczogQWN0dWFsbHksIEkgd29uZGVyIGlmIHRo ZSBzcGVjaWZpYyBhZHZhbnRhZ2VzIG9mIFRGTyBmb3IgSFRUUFMgY291bGQgYmUgYmV0dGVyIGRl c2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQsIGkuZS4sIGluIFNlY3Rpb24gNi4zPyBGb3IgaW5zdGFu Y2UsIGJ5IHNlcGFyYXRlIGFwcGxpY2FiaWxpdHkgc2VjdGlvbnMgZm9yIEhUVFAgYW5kIEhUVFBT PyBJZiBpZGVtcG90ZW5jeSBpcyBub3QgYW4gaXNzdWUgZm9yIEhUVFBTLCBpdCB3b3VsZCBiZSB3 b3J0aHdpbGUgdG8gZXhwbGljaXRseSBzdHJlc3MgdGhhdC4NCg0KSnVzdCBhcyBhIHRob3VnaHQu Li4NCg0KTWljaGFlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog d2lsbGNoYW5AZ29vZ2xlLmNvbSBbbWFpbHRvOndpbGxjaGFuQGdvb2dsZS5jb21dIE9uIA0KPiBC ZWhhbGYgT2YgV2lsbGlhbSBDaGFuICg/Pz8pDQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDAyLCAy MDEzIDM6NTIgUE0NCj4gVG86IFNjaGFyZiwgTWljaGFlbCAoTWljaGFlbCkNCj4gQ2M6IGlldGYt aHR0cC13Z0B3My5vcmc7IHRjcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEZlZWRiYWNrIG9u IFRDUCBGYXN0IE9wZW4/DQo+IA0KPiBUaGFua3MgZm9yIHRoZSBpbnZpdGF0aW9uIGZvciBmZWVk YmFjay4NCj4gDQo+IEkndmUgYmVlbiB0aGUgcHJpbWFyeSBjb250YWN0IG9uIHRoZSBDaHJvbWl1 bSAvIEdvb2dsZSBDaHJvbWUgDQo+IG5ldHdvcmsgc3RhY2sgdGVhbSBmb3IgWXVjaHVuZyBhbmQg dGhlIG90aGVyIFRDUCBGYXN0IE9wZW4gDQo+IGF1dGhvcnMgYXQgR29vZ2xlLCBzbyB3aGlsZSBJ IG9ubHkgbHVyayBpbiB0Y3BtLCBJJ3ZlIGJlZW4gDQo+IHJlYXNvbmFibHkgaW52b2x2ZWQgaW4g dGhpcyBwYXJ0aWN1bGFyIGZlYXR1cmUuIEkndmUgdGhvdWdodCANCj4gYSBsb3QgYWJvdXQgaG93 IHdlIHdvdWxkIHVzZSB0aGlzIGluIENocm9taXVtIGlmIGF2YWlsYWJsZS4gDQo+IEZvciBzb21l IGRldGFpbGVkIHRob3VnaHRzIGludGVuZGVkIGZvciBhIGJyb3dzZXIgaW1wbGVtZW50b3IgDQo+ IGF1ZGllbmNlLCB5b3UgY2FuIHJlYWQgdGhvc2UgZGV0YWlscyBhdCBteSBibG9nIA0KPiAoaHR0 cHM6Ly9pbnNvdWNpYW50Lm9yZy90ZWNoL3NvbWUtcXVpY2stdGhvdWdodHMtb24tdGNwLWZhc3Qt bw0KPiBwZW4tYW5kLWNocm9taXVtLykuDQo+IA0KPiBUaGUgc2hvcnQgb2YgaXQgaXMsIGZvciB2 YW5pbGxhIEhUVFAsIGl0J3MgdW5jbGVhciBob3cgDQo+IGJlbmVmaWNpYWwgaXQgd291bGQgYmUg Zm9yIHVzIHNpbmNlIHdlIGFscmVhZHkgaGF2ZSBzdWNoIA0KPiBnYWlucyBmb3IgYnJvd3NlciBw cmVjb25uZWN0IChvdXIgYnJvd3NlciBmZWF0dXJlIHRoYXQgbGVhcm5zIA0KPiBmcm9tIHBhc3Qg d2ViIGJyb3dzaW5nIHRvIHNwZWN1bGF0aXZlbHkgZXN0YWJsaXNoIA0KPiBjb25uZWN0aW9ucywg dHlwaWNhbGx5IGp1c3QgVENQIGNvbm5lY3Rpb25zIGJ1dCBwZXJoYXBzIGRvaW5nIA0KPiBhIFRM UyBvciBvdGhlciBoYW5kc2hha2VzIHRvbyBhcyBuZWVkZWQpLiBUaGVyZSdzIGEgDQo+IGZ1bmRh bWVudGFsIHRlbnNpb24gYmV0d2VlbiBvdXIgcHJlY29ubmVjdCBmZWF0dXJlIGFuZCBUQ1AgDQo+ IEZhc3QgT3BlbiBmb3IgdmFuaWxsYSBIVFRQLiBGdXJ0aGVyIGV4cGVyaW1lbnRhdGlvbiBpcyAN Cj4gbmVjZXNzYXJ5IGFuZCB3ZSd2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcy4gSSdtIGhvcGVmdWwg d2UgY2FuIA0KPiBmaW5kIGEgd2F5IHRvIGxldmVyYWdlIHRoaXMgZm9yIG91ciBnYWluLCBidXQg aXQgcmVxdWlyZXMgDQo+IG1vcmUgaW52ZXN0aWdhdGlvbi4NCj4gDQo+IEZvciBUTFMgb3ZlciBU Q1AsIHRoZXJlIGlzIGEgbXVjaCBtb3JlIG9idmlvdXMgd2luIHNpbmNlIHdlIA0KPiBjYW4gc3F1 ZWV6ZSB0aGUgVExTIENMSUVOVF9IRUxMTyBpbnRvIHRoZSBUQ1AgU1lOLCBhbmQgdGhlcmUgDQo+ IGlzIG5vIGNvbmNlcm4gYWJvdXQgdmlvbGF0aW5nIGlkZW1wb3RlbmN5LiBUaGlzIGNvbWJpbmVz IHdpdGggDQo+IG91ciBwcmVjb25uZWN0IGZlYXR1cmUgdmVyeSBuaWNlbHksIHNvIEkgYW0gcmF0 aGVyIGV4Y2l0ZWQgDQo+IGFib3V0IHRoZSBwb3RlbnRpYWwgZm9yIHRoaXMgdXNlIGNhc2UuIFdo aWxlIEhUVFBTIGFkb3B0aW9uIA0KPiBpcyBzdGlsbCBsb3csIEknbSBob3BlZnVsIHRoYXQgaXQg d2lsbCBpbmNyZWFzZSBvdmVyIHRpbWUgDQo+IChlc3BlY2lhbGx5IGdpdmVuIHRoZSBjb250ZXh0 IG9mIHJlY2VudCByZXZlbGF0aW9ucykuIFNvIEkgDQo+IHRoaW5rIHRoZSBpbXBvcnRhbmNlIG9m IHRoZSBIVFRQUyB1c2UgY2FzZSB3aWxsIGdyb3csIGFuZCANCj4gdGh1cyB0aGUgcG90ZW50aWFs IGltcG9ydGFuY2Ugb2YgVENQIEZhc3QgT3BlbiBpbiBkZWNyZWFzaW5nIA0KPiB1c2VyIHBlcmNl aXZlZCBsYXRlbmN5Lg0KPiANCj4gQ2hlZXJzLA0KPiBXaWxsDQo+IA0KPiANCj4gT24gRnJpLCBB dWcgMiwgMjAxMyBhdCAzOjEwIEFNLCBTY2hhcmYsIE1pY2hhZWwgKE1pY2hhZWwpIA0KPiA8bWlj aGFlbC5zY2hhcmZAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCj4gDQo+IA0KPiAJSGkgYWxs LA0KPiAJDQo+IAlBcyBtZW50aW9uZWQgdG9kYXkgb24gdGhlIG1pYywgdGhlIFRDUE0gd29ya2lu ZyBncm91cCANCj4gaGFzIGEgd29ya2luZyBncm91cCBpdGVtIHRoYXQgYWxsb3dzIGRhdGEgdG8g YmUgY2FycmllZCBpbiANCj4gdGhlIFNZTiBhbmQgU1lOLUFDSyBwYWNrZXRzIGFuZCB0aGF0IGlz IGNvbnN1bWVkIGJ5IHRoZSANCj4gcmVjZWl2aW5nIGVuZCBkdXJpbmcgdGhlIGluaXRpYWwgY29u bmVjdGlvbiBoYW5kc2hha2UsIHdoaWNoIA0KPiBpcyBzYXZlcyBUQ1AgaGFuZHNoYWtlcy4gVGhl IGRvY3VtZW50IHdhcyBkaXNjdXNzZWQgYWxlYWR5IA0KPiBleHRlbnNpdmVseSBpbiBUQ1BNIGFu ZCB3aWxsIGJlIHVwZGF0ZWQuIFRDUE0ncyB1bmRlcnN0YW5kaW5nIA0KPiBpcyB0aGF0IGl0IGlz IG5vdCBmYXIgYXdheSBmcm9tIFdHTEMuDQo+IAkNCj4gCVRoZSBsaW5rIGlzOiANCj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWZhc3RvcGVuLTA0DQo+IAkNCj4g CUluIHRoZSBzcGlyaXQgb2YgdG9kYXkncyBzZXNzaW9uLCBmZWVkYmFjayBmcm9tIHRoZSANCj4g aHR0cGJpcyBjb21tdW5pdHkgd291bGQgYmUgdmVyeSBhcHByZWNpYXRlZC4gUGxlYXNlIG5vdGUg dGhhdCANCj4gdGhpcyBtZWNoYW5pc20gc2xpZ2h0bHkgY2hhbmdlcyB0aGUgc3RhbmRhcmQgVENQ IHNlbWFudGljcywgDQo+IGFzIGV4cGxhaW5lZCBpbiB0aGUgYWJzdHJhY3Q6DQo+IAkNCj4gCSAg IEhvd2V2ZXIgVEZPIGRldmlhdGVzIGZyb20gdGhlIHN0YW5kYXJkIFRDUCBzZW1hbnRpY3MgDQo+ IGluIHRoYXQgdGhlIGRhdGEgaW4gdGhlDQo+IAkgICBTWU4gY291bGQgYmUgcmVwbGF5ZWQgdG8g YW4gYXBwbGljYXRpb24gaW4gc29tZSByYXJlIA0KPiBjaXJjdW1zdGFuY2VzLg0KPiAJICAgQXBw bGljYXRpb25zIHNob3VsZCBub3QgdXNlIFRGTyB1bmxlc3MgdGhleSBjYW4gDQo+IHRvbGVyYXRl IHRoaXMgaXNzdWUsDQo+IAkgICB3aGljaCBpcyBkZXRhaWxlZCBpbiB0aGUgQXBwbGljYWJpbGl0 eSBzZWN0aW9uLg0KPiAJDQo+IAlGdXJ0aGVyIGluZm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBpbiBT ZWN0aW9uIDYgb2YgdGhlIGRvY3VtZW50Lg0KPiAJDQo+IAlDb21tZW50cyBvciByZXZpZXdzIHdv dWxkIGJlIGhpZ2hseSB3ZWxjb21lLiBUaGUgDQo+IGRpc2N1c3Npb24gc2hvdWxkIHRha2UgcGxh Y2Ugb24gdGhlIFRDUE0gbWFpbGluZyBsaXN0Lg0KPiAJDQo+IAlUaGFua3MhDQo+IAkNCj4gCU1p Y2hhZWwgKFRDUE0gY28tY2hhaXIpDQo+IAkNCj4gCQ0KPiANCj4gDQo+IA== From dab@weston.borman.com Mon Aug 5 09:01:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F95721F8C20 for ; Mon, 5 Aug 2013 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieKESNoiG7F1 for ; Mon, 5 Aug 2013 09:01:01 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 087CD21F9ED1 for ; Mon, 5 Aug 2013 09:00:20 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r75G0C7F018655; Mon, 5 Aug 2013 11:00:13 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51F7EEDB.7050406@isi.edu> Date: Mon, 5 Aug 2013 11:00:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:01:09 -0000 On Jul 30, 2013, at 11:50 AM, Joe Touch wrote: >=20 >=20 > On 7/30/2013 1:16 AM, Fernando Gont wrote: >> On 07/30/2013 04:55 AM, Joe Touch wrote: >>>>=20 >>>> Part of TCP is support for simultaneous opens. If you don't support >>>> them, ether that's not TCP, or that's a buggy implementation. >>>=20 >>> Again simultaneous < reflexive. >>=20 >> There is no difference in the TCP code that is required for >> mirrored-endpoint-connections than the code that is required for >> simultaneous-{open, close} to work. >=20 > First, there is code in TCP to deal with similar special cases (e.g., = not negotiating the window size when on the local subnet). So there's = already similar special-case code deployed. That's an example about *implementation* details, not something that is = part of the TCP protocol. There're lots of optimizations in = implementations that can be characterized as special-case code, but = that's an implementation detail, not a protocol special case, e.g. TCP = header prediction. >=20 > However, as I noted, the simultaneous open/close is only a subset of = what needs to be vetted to ensure reflexive connections work. There is no reason to treat a tcp connection connecting to itself any = different than a TCP connection connecting to another host. Every = situation that can happen on a TCP self-connection can be constructed on = a TCP connection between hosts. If you can point out anything in the = protocol that breaks in a TCP self-connection, then that is something = that needs to be fixed in the protocol. A bug is a bug, and if it shows = up in the TCP self-connection case, then it is just waiting to show up = in then non-self connected case. =46rom a protocol standpoint, self-connected TCP sessions are not = disallowed and work today, it is implementations that have bugs that = keep them from working, and those bugs can show up in the = non-self-connected case. To argue that we have to do a bunch of work to = vet them to support them assumes that they are currently not allowed, = which is false. There is nothing in the TCP protocol which prohibits = them. Really, this is a non-issue; If you think otherwise, then write up your = own draft to change the TCP protocol to explicitly disallow = self-connected TCP sessions. -David >=20 >> In any case, my take is that the high-order-bit of this I-D is not = the >> mirrered-endpoint connections, but rather all the other stuff: the >> update that is needed for simultaneous opens, simultaneous closes, = and >> simultaneous probes to work as expected -- and it looks like everyone >> (both of us, and other folks that have viced their opinion, plus the >> implementations out there) agrees that that must be addressed. >=20 > I agree with that. >=20 >> The mirrored-endpoints corner case is something on which I have a >> position, but, as noted, is a secondary issue (at the end of the day, = I >> could myself live with not supporting them). >=20 > I agree this is a separate issue. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon Aug 5 10:36:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5421F9DF1 for ; Mon, 5 Aug 2013 10:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.715 X-Spam-Level: X-Spam-Status: No, score=-103.715 tagged_above=-999 required=5 tests=[AWL=-1.716, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyUZ7IPmhLHF for ; Mon, 5 Aug 2013 10:35:57 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA6221F9C4E for ; Mon, 5 Aug 2013 10:35:56 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r75HZPAb001692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 10:35:25 -0700 (PDT) Message-ID: <51FFE25C.7000706@isi.edu> Date: Mon, 05 Aug 2013 10:35:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> In-Reply-To: <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.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 Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:36:02 -0000 On 8/5/2013 9:00 AM, David Borman wrote: > > On Jul 30, 2013, at 11:50 AM, Joe Touch wrote: > >> >> >> On 7/30/2013 1:16 AM, Fernando Gont wrote: >>> On 07/30/2013 04:55 AM, Joe Touch wrote: >>>>> >>>>> Part of TCP is support for simultaneous opens. If you don't support >>>>> them, ether that's not TCP, or that's a buggy implementation. >>>> >>>> Again simultaneous < reflexive. >>> >>> There is no difference in the TCP code that is required for >>> mirrored-endpoint-connections than the code that is required for >>> simultaneous-{open, close} to work. >> >> First, there is code in TCP to deal with similar special cases >> (e.g., not negotiating the window size when on the local subnet). >> So there's already similar special-case code deployed. > > That's an example about *implementation* details, not something that > is part of the TCP protocol. There're lots of optimizations in > implementations that can be characterized as special-case code, but > that's an implementation detail, not a protocol special case, e.g. TCP > header prediction. "Implementation details" shouldn't affect either what we see on the wire or state at the endpoints, but short-circuiting TCP's windowing on the local LAN does *exactly* that. Are you arguing that this short-cut is not also a protocol violation? >> However, as I noted, the simultaneous open/close is only a subset >> ofwhat needs to be vetted to ensure reflexive connections work. > > There is no reason to treat a tcp connection connecting to itself > any different than a TCP connection connecting to another host. There's also no reason to treat a TCP connection connecting to another host on the same subnet as different from a TCP connection connecting elsewhere - BUT WE DO. Joe From dab@weston.borman.com Mon Aug 5 11:23:01 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CD821F918C for ; Mon, 5 Aug 2013 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phOmLGkkXQ6Q for ; Mon, 5 Aug 2013 11:22:56 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 42D4221F8947 for ; Mon, 5 Aug 2013 11:22:55 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r75IMp7F018863; Mon, 5 Aug 2013 13:22:51 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51FFE25C.7000706@isi.edu> Date: Mon, 5 Aug 2013 13:22:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:23:01 -0000 On Aug 5, 2013, at 12:35 PM, Joe Touch wrote: >=20 >=20 > On 8/5/2013 9:00 AM, David Borman wrote: >>=20 >> On Jul 30, 2013, at 11:50 AM, Joe Touch wrote: >>=20 >>>=20 >>>=20 >>> On 7/30/2013 1:16 AM, Fernando Gont wrote: >>>> On 07/30/2013 04:55 AM, Joe Touch wrote: >>>>>>=20 >>>>>> Part of TCP is support for simultaneous opens. If you don't = support >>>>>> them, ether that's not TCP, or that's a buggy implementation. >>>>>=20 >>>>> Again simultaneous < reflexive. >>>>=20 >>>> There is no difference in the TCP code that is required for >>>> mirrored-endpoint-connections than the code that is required for >>>> simultaneous-{open, close} to work. >>>=20 >>> First, there is code in TCP to deal with similar special cases >>> (e.g., not negotiating the window size when on the local subnet). >>> So there's already similar special-case code deployed. >>=20 >> That's an example about *implementation* details, not something that >> is part of the TCP protocol. There're lots of optimizations in >> implementations that can be characterized as special-case code, but >> that's an implementation detail, not a protocol special case, e.g. = TCP >> header prediction. >=20 > "Implementation details" shouldn't affect either what we see on the = wire > or state at the endpoints, but short-circuiting TCP's windowing on the > local LAN does *exactly* that. Are you arguing that this short-cut is > not also a protocol violation? Huh? I assumed you are talking about the MSS, if not, please be more = specific. If the negotiated MSS is being ignored, then that's a = protocol violation. If a larger MSS is being negotiated because it = knows it's on the local subnet, then that is not a protocol violation. But that's beside the point. My point is that special code in a TCP = implementation doesn't matter, what matters is whether or not there is = special case processing in the TCP protocol, and in the TCP protocol = there isn't any special case processing for, or prohibition against, a = self-connected TCP connection. >=20 >>> However, as I noted, the simultaneous open/close is only a subset >>> ofwhat needs to be vetted to ensure reflexive connections work. >>=20 >> There is no reason to treat a tcp connection connecting to itself >> any different than a TCP connection connecting to another host. >=20 > There's also no reason to treat a TCP connection connecting to another = host on the same subnet as different from a TCP connection connecting = elsewhere - BUT WE DO. You are confusing implementation optimizations with the TCP protocol = specification. Stop doing that, it just muddies the water. Knowledge = that a TCP connection is on the same subnet allows for optimizations to = improve performance, and there is nothing wrong with that, e.g., = negotiating a larger MSS for "local" traffic, and a smaller MSS for = "remote" traffic. At the end of the day, a self-connected TCP connection is perfectly = valid and not prohibited by the TCP specification, whether or not they = are useful to any application is a moot point. -David =20 >=20 > Joe From touch@isi.edu Mon Aug 5 11:34:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1B21F9D69 for ; Mon, 5 Aug 2013 11:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.639 X-Spam-Level: X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGzaXxmOOHqk for ; Mon, 5 Aug 2013 11:34:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B79F721F9D5C for ; Mon, 5 Aug 2013 11:34:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r75IY3O8012485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 11:34:03 -0700 (PDT) Message-ID: <51FFF01A.5040605@isi.edu> Date: Mon, 05 Aug 2013 11:34:02 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: David Borman References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> In-Reply-To: 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 Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:34:26 -0000 On 8/5/2013 11:22 AM, David Borman wrote: > > On Aug 5, 2013, at 12:35 PM, Joe Touch wrote: > >> >> >> On 8/5/2013 9:00 AM, David Borman wrote: >>> >>> On Jul 30, 2013, at 11:50 AM, Joe Touch wrote: >>> >>>> >>>> >>>> On 7/30/2013 1:16 AM, Fernando Gont wrote: >>>>> On 07/30/2013 04:55 AM, Joe Touch wrote: >>>>>>> >>>>>>> Part of TCP is support for simultaneous opens. If you don't support >>>>>>> them, ether that's not TCP, or that's a buggy implementation. >>>>>> >>>>>> Again simultaneous < reflexive. >>>>> >>>>> There is no difference in the TCP code that is required for >>>>> mirrored-endpoint-connections than the code that is required for >>>>> simultaneous-{open, close} to work. >>>> >>>> First, there is code in TCP to deal with similar special cases >>>> (e.g., not negotiating the window size when on the local subnet). >>>> So there's already similar special-case code deployed. >>> >>> That's an example about *implementation* details, not something that >>> is part of the TCP protocol. There're lots of optimizations in >>> implementations that can be characterized as special-case code, but >>> that's an implementation detail, not a protocol special case, e.g. TCP >>> header prediction. >> >> "Implementation details" shouldn't affect either what we see on the wire >> or state at the endpoints, but short-circuiting TCP's windowing on the >> local LAN does *exactly* that. Are you arguing that this short-cut is >> not also a protocol violation? > > Huh? I assumed you are talking about the MSS, if not, please be more specific. CWND discovery on the local subnet. > If the negotiated MSS is being ignored, then that's a protocol > violation. If a larger MSS is being negotiated because it knows it's > on the local subnet, then that is not a protocol violation. But neither MSS nor CWND is being "negotiated". The negotiation protocol - both on the wire and at the endpoints - is being circumvented. Joe From touch@isi.edu Mon Aug 5 11:40:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B0A21F9D22 for ; Mon, 5 Aug 2013 11:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSC2aQIKsCgu for ; Mon, 5 Aug 2013 11:40:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3CF21F9CB3 for ; Mon, 5 Aug 2013 11:40:31 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r75Ie1q2013791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 11:40:01 -0700 (PDT) Message-ID: <51FFF180.9070609@isi.edu> Date: Mon, 05 Aug 2013 11:40:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> <51FBDFDE.8030900@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-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 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:40:37 -0000 Hi, Richard, This is good. I do think that the lead is buried - the last sentence is the most important, and needs to be highlighted somehow - either repeating it earlier, setting it as a stand-alone sentence for emphasis, etc. Joe On 8/5/2013 2:32 AM, Scheffenegger, Richard wrote: > Hi Joe, > > Thank you for your input! > > I reworded the paragraph slightly. With my background in data storage, the one thing to avoid is silent data corruption (storage companies are generally very paranoid about that), thus the use of "data corruption" twice in the text below. That wording may nudge market forces to weed out the "best effort" PAWS implementations over time. That would agreeably be an improvement above the current state. > > > Implementations are strongly encouraged to follow the above rules for > handling a missing Timestamps option, and the order of precedence > mentioned in when deciding on the acceptance of a > segment. A TCP receiver not dropping segments without an expected > Timestamps option may expirience *undetectable* wrapped-sequence effects, > such as data (payload) corruption or session stalls. In order to maintain > the integrity of the payload data, in particular on high speed networks, > it is paramount to follow the described processing rules. > > > However, it has been mentioned that under some circumstances, the above > guidelines are too strict, and some paths sporadically suppress the > Timestamps option, while maintaining payload integrity. A path behaving in > this manner should be deemed inacceptable, but it has been noted that some > implementations relax the acceptance rules as a workaround, and allow TCP > to run across such paths. Again, if a receiver chooses to accept a segment > without an expected Timestamps option, it must be clear that undetectable > data corruption may occur. > > > Richard Scheffenegger > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Freitag, 02. August 2013 18:36 >> To: Scheffenegger, Richard >> Cc: Yuchung Cheng; Pasi Sarolahti; tcpm (tcpm@ietf.org) >> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >> >> >> >> On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: >> ... >>> As there have been multiple comments to describe the effects of this >>> SHOULD, the following paragraph was added right after. This is new >>> text, and the first throw. Text donations are highly appreciated if >>> this text does not capture the purpose to the required extent: >>> >>> >>> Implementations are strongly encouraged to follow the above rules >> for >>> handling a missing Timestamps option, and the order of precedence >>> mentioned in Section 4.3 when deciding on the acceptance of a >>> segment. This is to maintain the integrity of the payload data at >>> the receiver in particular on high speed networks. However, it has >>> been mentioned that under some circumstances, the above guidelines >>> are too strict, and some paths sporadically suppress the Timestamps >>> option, while maintaining payload integrity. A path behaving in >> this >>> manner should be deemed inacceptable, but it has been noted that >>> relaxing the acceptance rules can serve as a workaround, and allows >>> TCP to run across such paths. >> >> This misses the key issue, and it should not be glossed-over. >> >> A TCP that SHOULD drop segment missing an expected TSOpt (as when TS is >> negotiated during the SYN) MAY experience ***undetectable*** wrapped- >> sequence effects. >> >> A TCP that MUST drop such segments WILL NOT experience such effects. >> >> So relaxing this constraint turns PAWS protection from a guarantee to a >> maybe - and it does so in ways that the source cannot determine. The >> source presumably asked for PAWS, and the receiver agreed to it, but that >> guarantee is being turned into a maybe. >> >> The big problem with allowing this SHOULD is it thus turns all TS requests >> into "no PAWS provided". >> >> So you've just killed PAWS. >> >> Another victory for "rough consensus". >> >> Joe From dab@weston.borman.com Mon Aug 5 11:59:01 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6434121F9E3A for ; Mon, 5 Aug 2013 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz9YvX-y6ahN for ; Mon, 5 Aug 2013 11:58:45 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA821F9E13 for ; Mon, 5 Aug 2013 11:58:44 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r75Iwf7F018941; Mon, 5 Aug 2013 13:58:42 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51FFF01A.5040605@isi.edu> Date: Mon, 5 Aug 2013 13:58:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFF01A.5040605@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:59:01 -0000 On Aug 5, 2013, at 1:34 PM, Joe Touch wrote: >=20 >=20 > On 8/5/2013 11:22 AM, David Borman wrote: >>=20 >> On Aug 5, 2013, at 12:35 PM, Joe Touch wrote: >>=20 >>>=20 >>>=20 >>> On 8/5/2013 9:00 AM, David Borman wrote: >>>>=20 >>>> On Jul 30, 2013, at 11:50 AM, Joe Touch wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> On 7/30/2013 1:16 AM, Fernando Gont wrote: >>>>>> On 07/30/2013 04:55 AM, Joe Touch wrote: >>>>>>>>=20 >>>>>>>> Part of TCP is support for simultaneous opens. If you don't = support >>>>>>>> them, ether that's not TCP, or that's a buggy implementation. >>>>>>>=20 >>>>>>> Again simultaneous < reflexive. >>>>>>=20 >>>>>> There is no difference in the TCP code that is required for >>>>>> mirrored-endpoint-connections than the code that is required for >>>>>> simultaneous-{open, close} to work. >>>>>=20 >>>>> First, there is code in TCP to deal with similar special cases >>>>> (e.g., not negotiating the window size when on the local subnet). >>>>> So there's already similar special-case code deployed. >>>>=20 >>>> That's an example about *implementation* details, not something = that >>>> is part of the TCP protocol. There're lots of optimizations in >>>> implementations that can be characterized as special-case code, but >>>> that's an implementation detail, not a protocol special case, e.g. = TCP >>>> header prediction. >>>=20 >>> "Implementation details" shouldn't affect either what we see on the = wire >>> or state at the endpoints, but short-circuiting TCP's windowing on = the >>> local LAN does *exactly* that. Are you arguing that this short-cut = is >>> not also a protocol violation? >>=20 >> Huh? I assumed you are talking about the MSS, if not, please be more = specific. >=20 > CWND discovery on the local subnet. >=20 >> If the negotiated MSS is being ignored, then that's a protocol >> violation. If a larger MSS is being negotiated because it knows it's >> on the local subnet, then that is not a protocol violation. >=20 > But neither MSS nor CWND is being "negotiated". The negotiation = protocol - both on the wire and at the endpoints - is being = circumvented. If the implementation is ignoring these things, then that's a protocol = violation. There is always an MSS value; if MSS isn't received, then 536 = must be used, as per RFC-1122. RFC-1122 also requires that congestion = avoidance be used. But this is a rat-hole that has nothing to do self-connected TCP = connections. -David >=20 > Joe From dab@weston.borman.com Mon Aug 5 12:22:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67C421F9D80 for ; Mon, 5 Aug 2013 12:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8IMX4onQ4m9 for ; Mon, 5 Aug 2013 12:22:43 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 672F621F9D6F for ; Mon, 5 Aug 2013 12:22:43 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r75JMd7F018982; Mon, 5 Aug 2013 14:22:40 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <51F71470.908@isi.edu> Date: Mon, 5 Aug 2013 14:22:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:22:47 -0000 On Jul 29, 2013, at 8:18 PM, Joe Touch wrote: >=20 >=20 > On 7/29/2013 5:58 PM, Fernando Gont wrote: >> On 07/30/2013 01:55 AM, Joe Touch wrote: >>> On 7/29/2013 4:47 PM, Fernando Gont wrote: >>>> at the end of the day, reflected endpoints are just a >>>> specific case of "simultaneous open". >>>=20 >>> They're more than that. >>>=20 >>> They're simultaneous everything, with the same ISN. >>=20 >> Does it really matter that the ISNs are the same? (packets are not >> actaully traveling over a network) >=20 > It doesn't to me, but again this is a corner case that some systems = don't expect. The sequence space, and hence the ISN, is independent in each direction. = TCP is explicitly designed so that either direction can start at any = value. Any implementation that has problems with them starting at the = same place is broken. >>> FWIW, an app needs special code to deal with the self-reflected case >>> anyway - it needs to know that only one incarnation should close the >>> connection, vs. giving each incarnation a unique socket pair. >>=20 >> Well, if the connection is closed, you get a simultaneous close. >=20 > So from an app-writer's viewpoint, why would all connections be = simultaneous open and simultaneous close? What if that's a case that = either the protocol or the app doesn't want - maybe it wants to try to = de-sync by executing a timer and retrying. >=20 > It won't work on a reflexive socket. It will work everywhere else. If an app decides to create and use a TCP connection connected to = itself, then of course it'll need special code to deal with it. It has = to have special code to create it in the first place. >=20 >> [Yes, if anything, I would only expect applications that "really know >> what they're doing" to use this "mirrored-endpoints connections"... >> However, when ti comes to kernel code, it takes more work to not = support >> them , than to do it (assuming that you support simultaneous opens, >> simultaneous closes, etc.)] >=20 > I disagree; the work to not do it is very simple (it's just a test). = The work to ensure it always works could be a lot more. >=20 > The key question isn't whether this is a 'fun case' that the protocol = ought to handle; it's whether we should bother to ensure it is always = supported. IMO, the special case is a lot simpler than testing every = possible alternative. No, there is nothing in the TCP protocol that explicitly disallows them. = The TCP protocol works fine, it's just implementations with bugs that = have problems with them. >=20 >>> I recall that there have also been extensions that don't handle the >>> simultaneous case - that basically just punt, and say "try again" = when >>> it happens. When these are two different sockets, that's a = reasonable >>> approach; when it's a single reflexive socket, it would continually = fail. >>=20 >> Me, I'd argue that if e.g. simultaneous-opens are part of TCP, your >> extension should work with them rather than rely on "let's retry and >> hope that the SYNs don't cross on the network". >=20 > "handling simultaneous opens" can be done two ways: > - support them > - don't support them, and retry to de-sync >=20 > The latter will never work with reflexive connections, but it's just = as valid an approach. Absolutely not. There is no way to "de-sync." The crossing SYN case = happens when both sides are doing an active connect; both sides will be = in SYN-SENT state, from there you either transition to SYN-RCVD state if = you get a SYN, or to ESTABLISHED if you get a SYN/ACK. The only way to = do your "de-sync" is to close the connection, and then have one side = switch to being a passive connect, which is then no longer both sides = doing an active connect. -David >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fgont@si6networks.com Mon Aug 5 12:31:23 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0321F9D02 for ; Mon, 5 Aug 2013 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SU7CSjOAzrD for ; Mon, 5 Aug 2013 12:31:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4621F9D2B for ; Mon, 5 Aug 2013 12:31:19 -0700 (PDT) Received: from [186.134.9.207] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V6QUl-0000QW-LW; Mon, 05 Aug 2013 21:31:08 +0200 Message-ID: <51FFFD75.9040104@si6networks.com> Date: Mon, 05 Aug 2013 16:31:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> In-Reply-To: <51FFE25C.7000706@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:31:23 -0000 On 08/05/2013 02:35 PM, Joe Touch wrote: >> There is no reason to treat a tcp connection connecting to itself >> any different than a TCP connection connecting to another host. > > There's also no reason to treat a TCP connection connecting to another > host on the same subnet as different from a TCP connection connecting > elsewhere - BUT WE DO. Let's try to stay on focus. The document that Dave and me co-authored describes a concrete bug in the TCP sequence number validation rules. 1) Do you disagree with the problem and/or with the proposed mitigation? 2) Is there anything in the standard that says that mirrored connections should not be supported? Any reason for which these connections should be a special case? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Mon Aug 5 13:20:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9E021F98AD for ; Mon, 5 Aug 2013 13:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAHmW8JB6lb8 for ; Mon, 5 Aug 2013 13:20:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB2721F9808 for ; Mon, 5 Aug 2013 13:20:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r75KJxRU006097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 13:20:00 -0700 (PDT) Message-ID: <520008EF.3050000@isi.edu> Date: Mon, 05 Aug 2013 13:19:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> In-Reply-To: <51FFFD75.9040104@si6networks.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 Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:20:26 -0000 On 8/5/2013 12:31 PM, Fernando Gont wrote: > On 08/05/2013 02:35 PM, Joe Touch wrote: > >>> There is no reason to treat a tcp connection connecting to itself >>> any different than a TCP connection connecting to another host. >> >> There's also no reason to treat a TCP connection connecting to another >> host on the same subnet as different from a TCP connection connecting >> elsewhere - BUT WE DO. > > Let's try to stay on focus. The document that Dave and me co-authored > describes a concrete bug in the TCP sequence number validation rules. > > 1) Do you disagree with the problem Only if the problem can be shown as an example that does not require self-connects. Otherwise, it's specific to that corner case, and if self-connect works it ought not require such special treatment. > and/or with the proposed mitigation? It's hard to tell; it would be useful to have a subsection highlight exactly what is different and why. > 2) Is there anything in the standard that says that mirrored connections > should not be supported? Any reason for which these connections should > be a special case? If, as David claims, this is already the case, then there is no need for any of the text in Section 4.2. IMO, the following text in RFC 793 is what prohibits them: Each connection is uniquely specified by a pair of sockets identifying its two sides. There are no such "two sides", nor any "pair" in a mirrored connection. The ability to connect to do loopbacks is already established by the 127.0.0.0/8 subnet and the numerous ports available on each of those addresses. Joe From fgont@si6networks.com Mon Aug 5 13:44:29 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5056521F9DAD for ; Mon, 5 Aug 2013 13:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h5VLoyxJuyP for ; Mon, 5 Aug 2013 13:44:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id A60E521F9DCA for ; Mon, 5 Aug 2013 13:44:28 -0700 (PDT) Received: from [186.134.9.207] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V6RdZ-00024D-1w; Mon, 05 Aug 2013 22:44:17 +0200 Message-ID: <52000E99.207@si6networks.com> Date: Mon, 05 Aug 2013 17:44:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> <520008EF.3050000@isi.edu> In-Reply-To: <520008EF.3050000@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:44:29 -0000 On 08/05/2013 05:19 PM, Joe Touch wrote: >> >> Let's try to stay on focus. The document that Dave and me co-authored >> describes a concrete bug in the TCP sequence number validation rules. >> >> 1) Do you disagree with the problem > > Only if the problem can be shown as an example that does not require > self-connects. Of course. I mentioned a few times that the bug affects simultaneous opens, simultaneous closes, and simultaneous windows probes. The self-connect is just a specific case of the simultaneous open -- i.e., a scenario that deterministically leads to simultaneous opens -- just that. >> and/or with the proposed mitigation? > > It's hard to tell; it would be useful to have a subsection highlight > exactly what is different and why. That's why we wrote the I-D. What's the part that is not clear, and why? >> 2) Is there anything in the standard that says that mirrored connections >> should not be supported? Any reason for which these connections should >> be a special case? > > If, as David claims, this is already the case, then there is no need for > any of the text in Section 4.2. It is needed because some implementations have such bug. -- It shouldn't be a special case... but some implementations (unfortunately) treat it as such. > IMO, the following text in RFC 793 is what prohibits them: > > Each connection is uniquely specified by a pair of sockets > identifying its two sides. Where does RFC793 says that the two endpoints must be different? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From touch@isi.edu Mon Aug 5 15:06:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C39E21F9ED1 for ; Mon, 5 Aug 2013 15:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phct2gtDjJDD for ; Mon, 5 Aug 2013 15:06:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5263E21F9946 for ; Mon, 5 Aug 2013 15:06:19 -0700 (PDT) Received: from [68.181.9.7] (wireless-plus-009-007.usc.edu [68.181.9.7]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r75M5IKU028420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 15:05:28 -0700 (PDT) Message-ID: <5200218F.7030405@isi.edu> Date: Mon, 05 Aug 2013 15:05:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fernando Gont References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> <520008EF.3050000@isi.edu> <52000E99.207@si6networks.com> In-Reply-To: <52000E99.207@si6networks.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 Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:06:28 -0000 On 8/5/2013 1:44 PM, Fernando Gont wrote: > On 08/05/2013 05:19 PM, Joe Touch wrote: >>> >>> Let's try to stay on focus. The document that Dave and me co-authored >>> describes a concrete bug in the TCP sequence number validation rules. >>> >>> 1) Do you disagree with the problem >> >> Only if the problem can be shown as an example that does not require >> self-connects. > > Of course. I mentioned a few times that the bug affects simultaneous > opens, simultaneous closes, and simultaneous windows probes. > > The self-connect is just a specific case of the simultaneous open -- > i.e., a scenario that deterministically leads to simultaneous opens -- > just that. That's a better motivation for discussing the self-connect case, but then that seems at best an aside to the issue. >>> and/or with the proposed mitigation? >> >> It's hard to tell; it would be useful to have a subsection highlight >> exactly what is different and why. > > That's why we wrote the I-D. What's the part that is not clear, and why? The ID talks about the total of what's different, but it seems like you've changed a few equations of the edge conditions. I see them, but had to flip pages to see what they were, and I didn't see each line changed explained in a simple sentence. >>> 2) Is there anything in the standard that says that mirrored connections >>> should not be supported? Any reason for which these connections should >>> be a special case? >> >> If, as David claims, this is already the case, then there is no need for >> any of the text in Section 4.2. > > It is needed because some implementations have such bug. -- It shouldn't > be a special case... but some implementations (unfortunately) treat it > as such. It is not related to the issue here, as you note above, except as one way that always causes the issue. As a result, calling it out as a specific expectation is neither needed nor appropriate. >> IMO, the following text in RFC 793 is what prohibits them: >> >> Each connection is uniquely specified by a pair of sockets >> identifying its two sides. > > Where does RFC793 says that the two endpoints must be different? Two sides. Where are the two sides of a self-connect? There's only one connect call, and only one socket. It's not a pair of anything. Joe From fgont@si6networks.com Mon Aug 5 15:59:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0321F9F3D for ; Mon, 5 Aug 2013 15:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLLWTPzgtqBm for ; Mon, 5 Aug 2013 15:58:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0FA21F9EFB for ; Mon, 5 Aug 2013 15:58:58 -0700 (PDT) Received: from [186.134.9.207] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1V6Tjk-0006Nv-Bb; Tue, 06 Aug 2013 00:58:48 +0200 Message-ID: <52002E1E.2090303@si6networks.com> Date: Mon, 05 Aug 2013 19:58:38 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> <520008EF.3050000@isi.edu> <52000E99.207@si6networks.com> <5200218F.7030405@isi.edu> In-Reply-To: <5200218F.7030405@isi.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:59:00 -0000 On 08/05/2013 07:05 PM, Joe Touch wrote: >>>> and/or with the proposed mitigation? >>> >>> It's hard to tell; it would be useful to have a subsection highlight >>> exactly what is different and why. >> >> That's why we wrote the I-D. What's the part that is not clear, and why? > > The ID talks about the total of what's different, but it seems like > you've changed a few equations of the edge conditions. Simple allow for one byte to the left of the window, to handle all the problematic cases. That will cause the control data to be acted upon. > I see them, but > had to flip pages to see what they were, and I didn't see each line > changed explained in a simple sentence. I thought the equation was self-explaining, and none had argued otherwise. Me, I have no problem to add a note about that if people think that would help. > >>>> 2) Is there anything in the standard that says that mirrored >>>> connections >>>> should not be supported? Any reason for which these connections should >>>> be a special case? >>> >>> If, as David claims, this is already the case, then there is no need for >>> any of the text in Section 4.2. >> >> It is needed because some implementations have such bug. -- It shouldn't >> be a special case... but some implementations (unfortunately) treat it >> as such. > > It is not related to the issue here, as you note above, except as one > way that always causes the issue. As a result, calling it out as a > specific expectation is neither needed nor appropriate. It *is* related. Some implementations banned self connects because they thought of them as a vulnerability. But the vulnerability really had to do with improper handling of simultaneous opens, rather than self-connects. This I-D fixes the simultaneous-* problem, and notes "hey, you shouldn't have banned self-connects... the problem was elsewhere". > >>> IMO, the following text in RFC 793 is what prohibits them: >>> >>> Each connection is uniquely specified by a pair of sockets >>> identifying its two sides. >> >> Where does RFC793 says that the two endpoints must be different? > > Two sides. > > Where are the two sides of a self-connect? There's only one connect > call, and only one socket. It's not a pair of anything. I don't follow. When you implement or specify a protocol you care about local interface calls, and packets you receive. You don't care about remote interface calls, but only abut the resulting packets. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dab@weston.borman.com Mon Aug 5 16:33:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A29121F93B9 for ; Mon, 5 Aug 2013 16:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz6mDRWlhXCv for ; Mon, 5 Aug 2013 16:33:20 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id B261D21F9F3D for ; Mon, 5 Aug 2013 16:33:18 -0700 (PDT) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r75NWt7F019430; Mon, 5 Aug 2013 18:33:01 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Borman In-Reply-To: <5200218F.7030405@isi.edu> Date: Mon, 5 Aug 2013 18:32:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4461CF1C-3631-4845-A2E5-91BBEC3326B0@weston.borman.com> References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> <520008EF.3050000@isi.edu> <52000E99.207@si6networks.com> <5200218F.7030405@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 23:33:24 -0000 On Aug 5, 2013, at 5:05 PM, Joe Touch wrote: >=20 >=20 > On 8/5/2013 1:44 PM, Fernando Gont wrote: >> On 08/05/2013 05:19 PM, Joe Touch wrote: ... >>> IMO, the following text in RFC 793 is what prohibits them: >>>=20 >>> Each connection is uniquely specified by a pair of sockets >>> identifying its two sides. >>=20 >> Where does RFC793 says that the two endpoints must be different? >=20 > Two sides. >=20 > Where are the two sides of a self-connect? There's only one connect = call, and only one socket. It's not a pair of anything. Be careful with terminology. You are confusing the BSD socket interface = with the "socket" as defined in RFC 793, and they are *not* the same = thing. In RFC 793, a "socket" only refers to the addressing on one side = of a connection, i.e. a single IP address and a single port, an no state = information. =46rom RFC 793: To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections. When RFC 793 talks about a "pair of sockets", it's saying a connection = is identified by the combination of a local IP-address/TCP-port and a = foreign IP-address/TCP-port, and hence multiple *connections* can have = the same "local socket" by having different "foreign sockets". And the sentence you quoted comes from: The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides. Again, the RFC 793 "socket" is just a single IP address and TCP port, it = is not a BSD socket, and the "pair of sockets" just means you have both = local and remote IP addresses and TCP ports. For a self-connected BSD socket, the bind() specifies the RFC 793 "local = socket", and the connect() specifies the RFC 793 "foreign socket", thus = you have an RFC 793 "pair of sockets", and a unique connection held = within a single BSD socket. -David >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Tue Aug 6 01:26:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C67621F9D07; Tue, 6 Aug 2013 01:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qdNTHTD8d4E; Tue, 6 Aug 2013 01:25:59 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0721F8AA1; Tue, 6 Aug 2013 01:25:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r768Pr0e023369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2013 03:25:54 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r768Pqmq023644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 10:25:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 6 Aug 2013 10:25:52 +0200 From: "Scharf, Michael (Michael)" To: Roberto Peon , HTTP Working Group , "tsvwg@ietf.org" Thread-Topic: The List (of application-layer desired features) Thread-Index: AQHOkn1KzYd49rHxbUOlPV1nhDLm1JmHs8IAgAAjuFA= Date: Tue, 6 Aug 2013 08:25:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D07EE42@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] The List (of application-layer desired features) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 08:26:05 -0000 Well, part of this is also related to TCPM, but for simplicity I am fine wi= th keeping the discussion on the TSVWG list right now. The community is mos= tly the same anyway... Michael > -----Original Message----- > From: Roberto Peon [mailto:grmocg@gmail.com]=20 > Sent: Tuesday, August 06, 2013 10:16 AM > To: HTTP Working Group; tsvwg@ietf.org > Subject: Re: The List (of application-layer desired features) >=20 > Actually sending to the right list for TSVWG... >=20 > -=3DR >=20 >=20 > On Tue, Aug 6, 2013 at 1:14 AM, Roberto Peon wrote: >=20 >=20 > For those of you who missed it, at the HTTPBis/TSVG=20 > joint session, a question about what applications want from=20 > the transport (I really want to put quotes around that) came up. >=20 > Here is a rendition of what was on the note that I=20 > jotted down in response to this question, and which I passed=20 > to people at the mic. >=20 > (Apps-folks want the following) Deployed in 1996: > ----------------------------------------- > - Prioritization > - Partial Reliability > - "Shared" congestion between multiple streams > - Security > - No HOL blocking on stream X when loss on stream Y > - Cheap/Fast channel/connection setup > - Wide, "safe" deployment > - Competes with TCP/HTTP/1.1 (performance-wise) > - Multipath/roaming robustness, i.e. the "driveway" problem >=20 >=20 > I'll reiterate that by far the most important feature=20 > is "is deployed". > Nothing else matters until that is true, at least at=20 > the application-layer. > =09 > -=3DR > =09 >=20 >=20 >=20 >=20 > = From rs@netapp.com Tue Aug 6 06:40:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962D221F9D0A for ; Tue, 6 Aug 2013 06:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.801 X-Spam-Level: X-Spam-Status: No, score=-7.801 tagged_above=-999 required=5 tests=[AWL=2.798, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzVODJpLgpoA for ; Tue, 6 Aug 2013 06:40:16 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7C321F9D02 for ; Tue, 6 Aug 2013 06:40:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,826,1367996400"; d="scan'208";a="79029782" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 06 Aug 2013 06:40:13 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.105]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 6 Aug 2013 06:40:13 -0700 From: "Scheffenegger, Richard" To: Joe Touch , Kevin Mason , Pasi Sarolahti , "draft-ietf-tcpm-1323bis.authors@ietf.org" Thread-Topic: [tcpm] draft-ietf-tcpm-1323bis-14.txt Thread-Index: AQHOhlJ0mDsCw3frk0+Y7NXoRQhe4Jl8AbGAgAX5QeCAAKpqAIADx6jQgAESEQCAAMX8UA== Date: Tue, 6 Aug 2013 13:40:12 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25C6A705@SACEXCMBX06-PRD.hq.netapp.com> References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> <51FBDFDE.8030900@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-PRD.hq.netapp.com> <51FFF180.9070609@isi.edu> In-Reply-To: <51FFF180.9070609@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 13:40:20 -0000 Hi Joe, Kevin, Pasi, I have shuffled the sentences slightly, to reflect the suggested emphasis a= nd make the point early and easier to spot. The typo is also fixed. Unless anyone objects, I'll submit -15 in the next few hours with these cha= nged paragraphs. Implementations are strongly encouraged to follow the above=20 rules for handling a missing Timestamps option, and the order of=20 precedence mentioned in Section 4.3 when deciding on the=20 acceptance of a segment. =20 If a receiver chooses to accept a segment without an expected=20 Timestamps option, it must be clear that undetectable data=20 corruption may occur.=20 =20 Such a TCP receiver may experience undetectable wrapped- sequence effects, such as data (payload) corruption or session=20 stalls. In order to maintain the integrity of the payload data,=20 in particular on high speed networks, it is paramount to follow=20 the described processing rules. =20 However, it has been mentioned that under some circumstances,=20 the above guidelines are too strict, and some paths sporadically=20 suppress the Timestamps option, while maintaining payload=20 integrity. A path behaving in this manner should be deemed=20 unacceptable, but it has been noted that some implementations=20 relax the acceptance rules as a workaround, and allow TCP to run=20 across such paths. =20 =20 Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Montag, 05. August 2013 20:40 > To: Scheffenegger, Richard > Cc: tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >=20 > Hi, Richard, >=20 > This is good. I do think that the lead is buried - the last sentence is > the most important, and needs to be highlighted somehow - either repeatin= g > it earlier, setting it as a stand-alone sentence for emphasis, etc. >=20 > Joe >=20 > On 8/5/2013 2:32 AM, Scheffenegger, Richard wrote: > > Hi Joe, > > > > Thank you for your input! > > > > I reworded the paragraph slightly. With my background in data storage, > the one thing to avoid is silent data corruption (storage companies are > generally very paranoid about that), thus the use of "data corruption" > twice in the text below. That wording may nudge market forces to weed out > the "best effort" PAWS implementations over time. That would agreeably be > an improvement above the current state. > > > > > > Implementations are strongly encouraged to follow the above > rules for > > handling a missing Timestamps option, and the order of precedenc= e > > mentioned in when deciding on the > acceptance of a > > segment. A TCP receiver not dropping segments without an expecte= d > > Timestamps option may expirience *undetectable* wrapped-sequence > effects, > > such as data (payload) corruption or session stalls. In order to > maintain > > the integrity of the payload data, in particular on high speed > networks, > > it is paramount to follow the described processing rules. > > > > > > However, it has been mentioned that under some circumstances, > the above > > guidelines are too strict, and some paths sporadically suppress > the > > Timestamps option, while maintaining payload integrity. A path > behaving in > > this manner should be deemed inacceptable, but it has been noted > that some > > implementations relax the acceptance rules as a workaround, and > allow TCP > > to run across such paths. Again, if a receiver chooses to accept > a segment > > without an expected Timestamps option, it must be clear that > undetectable > > data corruption may occur. > > > > > > Richard Scheffenegger > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Freitag, 02. August 2013 18:36 > >> To: Scheffenegger, Richard > >> Cc: Yuchung Cheng; Pasi Sarolahti; tcpm (tcpm@ietf.org) > >> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt > >> > >> > >> > >> On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: > >> ... > >>> As there have been multiple comments to describe the effects of this > >>> SHOULD, the following paragraph was added right after. This is new > >>> text, and the first throw. Text donations are highly appreciated if > >>> this text does not capture the purpose to the required extent: > >>> > >>> > >>> Implementations are strongly encouraged to follow the above > >>> rules > >> for > >>> handling a missing Timestamps option, and the order of precedenc= e > >>> mentioned in Section 4.3 when deciding on the acceptance of a > >>> segment. This is to maintain the integrity of the payload data > at > >>> the receiver in particular on high speed networks. However, it > has > >>> been mentioned that under some circumstances, the above > guidelines > >>> are too strict, and some paths sporadically suppress the > Timestamps > >>> option, while maintaining payload integrity. A path behaving > >>> in > >> this > >>> manner should be deemed inacceptable, but it has been noted that > >>> relaxing the acceptance rules can serve as a workaround, and > allows > >>> TCP to run across such paths. > >> > >> This misses the key issue, and it should not be glossed-over. > >> > >> A TCP that SHOULD drop segment missing an expected TSOpt (as when TS > >> is negotiated during the SYN) MAY experience ***undetectable*** > >> wrapped- sequence effects. > >> > >> A TCP that MUST drop such segments WILL NOT experience such effects. > >> > >> So relaxing this constraint turns PAWS protection from a guarantee to > >> a maybe - and it does so in ways that the source cannot determine. > >> The source presumably asked for PAWS, and the receiver agreed to it, > >> but that guarantee is being turned into a maybe. > >> > >> The big problem with allowing this SHOULD is it thus turns all TS > >> requests into "no PAWS provided". > >> > >> So you've just killed PAWS. > >> > >> Another victory for "rough consensus". > >> > >> Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Tue Aug 6 09:18:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52BD21F9F59 for ; Tue, 6 Aug 2013 09:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P+JS7JFPKDP for ; Tue, 6 Aug 2013 09:18:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3E21F9F70 for ; Tue, 6 Aug 2013 09:18:30 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r76GHbaF018098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Aug 2013 09:17:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <52002E1E.2090303@si6networks.com> Date: Tue, 6 Aug 2013 09:17:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> <520008EF.3050000@isi.edu> <52000E99.207@si6networks.com> <5200218F.7030405@isi.edu> <52002E1E.2090303@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1508) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 16:18:36 -0000 On Aug 5, 2013, at 3:58 PM, Fernando Gont wrote: > On 08/05/2013 07:05 PM, Joe Touch wrote: >>>>> and/or with the proposed mitigation? >>>>=20 >>>> It's hard to tell; it would be useful to have a subsection = highlight >>>> exactly what is different and why. >>>=20 >>> That's why we wrote the I-D. What's the part that is not clear, and = why? >>=20 >> The ID talks about the total of what's different, but it seems like >> you've changed a few equations of the edge conditions.=20 >=20 > Simple allow for one byte to the left of the window, to handle all the > problematic cases. That will cause the control data to be acted upon. >> I see them, but >> had to flip pages to see what they were, and I didn't see each line >> changed explained in a simple sentence. >=20 > I thought the equation was self-explaining, and none had argued > otherwise. Me, I have no problem to add a note about that if people > think that would help. You give a before and after as a long section, but IMO it would be = useful to highlight exactly what has changed without expecting readers = to do a "diff". >>>>> 2) Is there anything in the standard that says that mirrored >>>>> connections >>>>> should not be supported? Any reason for which these connections = should >>>>> be a special case? >>>>=20 >>>> If, as David claims, this is already the case, then there is no = need for >>>> any of the text in Section 4.2. >>>=20 >>> It is needed because some implementations have such bug. -- It = shouldn't >>> be a special case... but some implementations (unfortunately) treat = it >>> as such. >>=20 >> It is not related to the issue here, as you note above, except as one >> way that always causes the issue. As a result, calling it out as a >> specific expectation is neither needed nor appropriate. >=20 > It *is* related. Some implementations banned self connects because = they > thought of them as a vulnerability. But the vulnerability really had = to > do with improper handling of simultaneous opens, rather than = self-connects. >=20 > This I-D fixes the simultaneous-* problem, and notes "hey, you = shouldn't > have banned self-connects... the problem was elsewhere". You shouldn't have banned self-connects for this reason. There are other = good reasons to avoid self-connects, which I've discussed. >>>> IMO, the following text in RFC 793 is what prohibits them: >>>>=20 >>>> Each connection is uniquely specified by a pair of sockets >>>> identifying its two sides. >>>=20 >>> Where does RFC793 says that the two endpoints must be different? >>=20 >> Two sides. >>=20 >> Where are the two sides of a self-connect? There's only one connect >> call, and only one socket. It's not a pair of anything. >=20 > I don't follow. When you implement or specify a protocol you care = about > local interface calls, and packets you receive. You don't care about > remote interface calls, but only abut the resulting packets. You also care about a few other things that could interfere with = reflexive connections, e.g., how the state machines handle API calls or = events that send packets vs. those that receive them. The sentence I = cite, IMO, avoids that potential problem by referring to two sides.=20 Joe= From touch@isi.edu Tue Aug 6 09:27:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2597221F9702 for ; Tue, 6 Aug 2013 09:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYiNdk7ysBCk for ; Tue, 6 Aug 2013 09:27:52 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 011EF21E8053 for ; Tue, 6 Aug 2013 09:27:36 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r76GR1JJ020833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Aug 2013 09:27:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <4461CF1C-3631-4845-A2E5-91BBEC3326B0@weston.borman.com> Date: Tue, 6 Aug 2013 09:26:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EC10A6.7040300@gont.com.ar> <51ECBCE7.8080805@isi.edu> <51EEA5B6.6050402@isi.edu> <51F6F020.4090006@gont.com.ar> <51F6F705.5070502@isi.edu> <51F6FF2C.2060801@gont.com.ar> <51F70100.8050200@isi.edu> <51F70FA7.6080703@si6networks.com> <51F71470.908@isi.edu> <51F716B0.7020002@si6networks.com> <5FF7F1FA-769E-4B70-8B2D-207EDA71E9F5@isi.edu> <51F7764D.7010105@gont.com.ar> <51F7EEDB.7050406@isi.edu> <8E1C1973-823C-4E05-83BB-9A6047C55C0C@weston.borman.com> <51FFE25C.7000706@isi.edu> <51FFFD75.9040104@si6networks.com> <520008EF.3050000@isi.edu> <52000E99.207@si6networks.com> <5200218F.7030405@isi.edu> <4461CF1C-3631-4845-A2E5-91BBEC3326B0@weston.borman.com> To: David Borman X-Mailer: Apple Mail (2.1508) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Fernando Gont , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] TCP Loopback Connections with the Same Src/Dest Port X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 16:27:58 -0000 On Aug 5, 2013, at 4:32 PM, David Borman wrote: >=20 > On Aug 5, 2013, at 5:05 PM, Joe Touch wrote: >=20 >>=20 >>=20 >> On 8/5/2013 1:44 PM, Fernando Gont wrote: >>> On 08/05/2013 05:19 PM, Joe Touch wrote: > ... >>>> IMO, the following text in RFC 793 is what prohibits them: >>>>=20 >>>> Each connection is uniquely specified by a pair of sockets >>>> identifying its two sides. >>>=20 >>> Where does RFC793 says that the two endpoints must be different? >>=20 >> Two sides. >>=20 >> Where are the two sides of a self-connect? There's only one connect = call, and only one socket. It's not a pair of anything. >=20 > Be careful with terminology. You are confusing the BSD socket = interface with the "socket" as defined in RFC 793, and they are *not* = the same thing. I have been consistently referring to a socket as an IP address and a = port. Although the warning is useful to others on this list, it does not = apply to my posts in this thread. In a reflexive connection, one socket is used for both sides of a = connection. That's one side with one socket. And that's not what RFC 793 = says. Speaking of Unix: > For a self-connected BSD socket, the bind() specifies the RFC 793 = "local socket", and the connect() specifies the RFC 793 "foreign = socket", So you're using the same 793-socket for both sides. That's one socket on = a connection with one side (where, IMO, "side" is where things like = local connection state exist).=20 ---- FWIW, my primary concerns with this thread are: a) focusing on the hang issue as primarily for reflexive = connections it's equally important for non-reflexive b) promoting the use of reflexive connections there are a lot of good reasons to avoid them; the hack = to get around creating a /tmp file is a very bad use case (/tmp = can't hang, but self-connections can easily block and their storage = depends=20 heavily on the amount of Unix socket buffer) Joe From touch@isi.edu Tue Aug 6 09:36:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118DA21F9F62 for ; Tue, 6 Aug 2013 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd5lkm3zkeDb for ; Tue, 6 Aug 2013 09:36:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 455D021F89C3 for ; Tue, 6 Aug 2013 09:36:49 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-85-4.lsanca.dsl-w.verizon.net [71.105.85.4]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r76GZUIe023237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 6 Aug 2013 09:35:41 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25C6A705@SACEXCMBX06-PRD.hq.netapp.com> Date: Tue, 6 Aug 2013 09:35:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36FAC2F5-4D3F-4D49-ABA5-FB83F33344B9@isi.edu> References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> <51FBDFDE.8030900@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-PRD.hq.netapp.com> <51FFF180.9070609@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C6A705@SACEXCMBX06-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1508) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm \(tcpm@ietf.org\)" , "draft-ietf-tcpm-1323bis.authors@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 16:36:54 -0000 On Aug 6, 2013, at 6:40 AM, "Scheffenegger, Richard" = wrote: >=20 > Hi Joe, Kevin, Pasi, >=20 > I have shuffled the sentences slightly, to reflect the suggested = emphasis and make the point early and easier to spot. > The typo is also fixed. Thanks. I still prefer MUST with an explanation of how some endpoints = violate that, FWIW. I don't think that having a TCP that compromises = integrity "to allow TCP to run" makes ANY sense at all. Joe >=20 > Unless anyone objects, I'll submit -15 in the next few hours with = these changed paragraphs. >=20 >=20 >=20 > Implementations are strongly encouraged to follow the above=20 > rules for handling a missing Timestamps option, and the order of=20= > precedence mentioned in Section 4.3 when deciding on the=20 > acceptance of a segment. >=20 > If a receiver chooses to accept a segment without an expected=20 > Timestamps option, it must be clear that undetectable data=20 > corruption may occur.=20 >=20 > Such a TCP receiver may experience undetectable wrapped- > sequence effects, such as data (payload) corruption or session=20 > stalls. In order to maintain the integrity of the payload data,=20= > in particular on high speed networks, it is paramount to follow=20= > the described processing rules. >=20 > However, it has been mentioned that under some circumstances,=20 > the above guidelines are too strict, and some paths sporadically=20= > suppress the Timestamps option, while maintaining payload=20 > integrity. A path behaving in this manner should be deemed=20 > unacceptable, but it has been noted that some implementations=20 > relax the acceptance rules as a workaround, and allow TCP to run=20= > across such paths. =20 >=20 >=20 >=20 > Richard Scheffenegger >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of >> Joe Touch >> Sent: Montag, 05. August 2013 20:40 >> To: Scheffenegger, Richard >> Cc: tcpm (tcpm@ietf.org) >> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >>=20 >> Hi, Richard, >>=20 >> This is good. I do think that the lead is buried - the last sentence = is >> the most important, and needs to be highlighted somehow - either = repeating >> it earlier, setting it as a stand-alone sentence for emphasis, etc. >>=20 >> Joe >>=20 >> On 8/5/2013 2:32 AM, Scheffenegger, Richard wrote: >>> Hi Joe, >>>=20 >>> Thank you for your input! >>>=20 >>> I reworded the paragraph slightly. With my background in data = storage, >> the one thing to avoid is silent data corruption (storage companies = are >> generally very paranoid about that), thus the use of "data = corruption" >> twice in the text below. That wording may nudge market forces to weed = out >> the "best effort" PAWS implementations over time. That would = agreeably be >> an improvement above the current state. >>>=20 >>>=20 >>> Implementations are strongly encouraged to follow the above >> rules for >>> handling a missing Timestamps option, and the order of = precedence >>> mentioned in when deciding on the >> acceptance of a >>> segment. A TCP receiver not dropping segments without an = expected >>> Timestamps option may expirience *undetectable* = wrapped-sequence >> effects, >>> such as data (payload) corruption or session stalls. In order = to >> maintain >>> the integrity of the payload data, in particular on high speed >> networks, >>> it is paramount to follow the described processing rules. >>> >>>=20 >>> However, it has been mentioned that under some = circumstances, >> the above >>> guidelines are too strict, and some paths sporadically = suppress >> the >>> Timestamps option, while maintaining payload integrity. A path >> behaving in >>> this manner should be deemed inacceptable, but it has been = noted >> that some >>> implementations relax the acceptance rules as a workaround, = and >> allow TCP >>> to run across such paths. Again, if a receiver chooses to = accept >> a segment >>> without an expected Timestamps option, it must be clear that >> undetectable >>> data corruption may occur. >>> >>>=20 >>> Richard Scheffenegger >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Freitag, 02. August 2013 18:36 >>>> To: Scheffenegger, Richard >>>> Cc: Yuchung Cheng; Pasi Sarolahti; tcpm (tcpm@ietf.org) >>>> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >>>>=20 >>>>=20 >>>>=20 >>>> On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: >>>> ... >>>>> As there have been multiple comments to describe the effects of = this >>>>> SHOULD, the following paragraph was added right after. This is new >>>>> text, and the first throw. Text donations are highly appreciated = if >>>>> this text does not capture the purpose to the required extent: >>>>>=20 >>>>>=20 >>>>> Implementations are strongly encouraged to follow the above >>>>> rules >>>> for >>>>> handling a missing Timestamps option, and the order of = precedence >>>>> mentioned in Section 4.3 when deciding on the acceptance of a >>>>> segment. This is to maintain the integrity of the payload = data >> at >>>>> the receiver in particular on high speed networks. However, = it >> has >>>>> been mentioned that under some circumstances, the above >> guidelines >>>>> are too strict, and some paths sporadically suppress the >> Timestamps >>>>> option, while maintaining payload integrity. A path behaving >>>>> in >>>> this >>>>> manner should be deemed inacceptable, but it has been noted = that >>>>> relaxing the acceptance rules can serve as a workaround, and >> allows >>>>> TCP to run across such paths. >>>>=20 >>>> This misses the key issue, and it should not be glossed-over. >>>>=20 >>>> A TCP that SHOULD drop segment missing an expected TSOpt (as when = TS >>>> is negotiated during the SYN) MAY experience ***undetectable*** >>>> wrapped- sequence effects. >>>>=20 >>>> A TCP that MUST drop such segments WILL NOT experience such = effects. >>>>=20 >>>> So relaxing this constraint turns PAWS protection from a guarantee = to >>>> a maybe - and it does so in ways that the source cannot determine. >>>> The source presumably asked for PAWS, and the receiver agreed to = it, >>>> but that guarantee is being turned into a maybe. >>>>=20 >>>> The big problem with allowing this SHOULD is it thus turns all TS >>>> requests into "no PAWS provided". >>>>=20 >>>> So you've just killed PAWS. >>>>=20 >>>> Another victory for "rough consensus". >>>>=20 >>>> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From internet-drafts@ietf.org Tue Aug 6 10:04:09 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4D121F9FE9; Tue, 6 Aug 2013 10:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR1wJdOLqX7y; Tue, 6 Aug 2013 10:04:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A66E721F9D92; Tue, 6 Aug 2013 10:04:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.61 Message-ID: <20130806170408.2598.58710.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 10:04:08 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-15.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 17:04:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-15.txt Pages : 47 Date : 2013-08-06 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 TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document obsoletes RFC 1323 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-15 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 kem@finwait.net Tue Aug 6 15:51:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5953721F8C9D for ; Tue, 6 Aug 2013 15:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Twrj0g8UvM0d for ; Tue, 6 Aug 2013 15:51:16 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8411421F9D5F for ; Tue, 6 Aug 2013 15:51:15 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1990326qab.16 for ; Tue, 06 Aug 2013 15:51:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BWGIG/8yQLo/9ivojm3wKxsruiESjzkY6gXz42i5cnc=; b=m3BHY32xJYzEOXQmU9OHak/eo4X94Oe9JWyoJ7twYU4uZdHfTBlrZacel1PhxqBzN7 rLzkdDSwk/NT/vCeeE3nJmCSD6tSEDyvJ6NU0VhF2hNHQn4R0/JYSftctNWV08etlXEX uD0R8gFmU/aY+NU6zrTbFDEWbwdsHAvryJnhzDyy2yvlDX2UEX4MHhEklyRWbZpSyyhm Se9UgkHsJQHCkZx/d12eJABg4J+aJyRJ8LP3KH2gA1B5skxDw0qSQF6JaROGZ/03YR/+ Sza89bK6CkmrRCqYWDD81ZJoF7oGZrqToR6awEwg7WetvmxTw2yf0eb+tyD1TXNmfHv1 g7Sg== X-Gm-Message-State: ALoCoQnuh/sLNjSu313CE9OETpU/ZMBCezCf7lXnm+/5xLL87pF1jOvK8VI65yKCNtikNdWTB5sU X-Received: by 10.49.104.163 with SMTP id gf3mr424060qeb.73.1375829474720; Tue, 06 Aug 2013 15:51:14 -0700 (PDT) Received: from alf.masonke.com (pool-173-72-251-46.clppva.fios.verizon.net. [173.72.251.46]) by mx.google.com with ESMTPSA id nh4sm4971417qeb.6.2013.08.06.15.51.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 15:51:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Kevin Mason In-Reply-To: <36FAC2F5-4D3F-4D49-ABA5-FB83F33344B9@isi.edu> Date: Tue, 6 Aug 2013 18:51:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> <51FBDFDE.8030900@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-PRD.hq.netapp.com> <51FFF180.9070609@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C6A705@SACEXCMBX06-PRD.hq.netapp.com> <36FAC2F5-4D3F-4D49-ABA5-FB83F33344B9@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1508) Cc: "tcpm \(tcpm@ietf.org\)" , "draft-ietf-tcpm-1323bis.authors@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 22:51:21 -0000 Joe, I understand your point, but could there be legacy stack implementations = that prevent declaring MUST? Kevin On Aug 6, 2013, at 12:35 PM, Joe Touch wrote: >=20 > On Aug 6, 2013, at 6:40 AM, "Scheffenegger, Richard" = wrote: >=20 >>=20 >> Hi Joe, Kevin, Pasi, >>=20 >> I have shuffled the sentences slightly, to reflect the suggested = emphasis and make the point early and easier to spot. >> The typo is also fixed. >=20 > Thanks. I still prefer MUST with an explanation of how some endpoints = violate that, FWIW. I don't think that having a TCP that compromises = integrity "to allow TCP to run" makes ANY sense at all. >=20 > Joe >=20 >>=20 >> Unless anyone objects, I'll submit -15 in the next few hours with = these changed paragraphs. >>=20 >>=20 >>=20 >> Implementations are strongly encouraged to follow the above=20 >> rules for handling a missing Timestamps option, and the order of=20= >> precedence mentioned in Section 4.3 when deciding on the=20 >> acceptance of a segment. >>=20 >> If a receiver chooses to accept a segment without an expected=20 >> Timestamps option, it must be clear that undetectable data=20 >> corruption may occur.=20 >>=20 >> Such a TCP receiver may experience undetectable wrapped- >> sequence effects, such as data (payload) corruption or session=20 >> stalls. In order to maintain the integrity of the payload data,=20= >> in particular on high speed networks, it is paramount to follow=20= >> the described processing rules. >>=20 >> However, it has been mentioned that under some circumstances,=20 >> the above guidelines are too strict, and some paths sporadically=20= >> suppress the Timestamps option, while maintaining payload=20 >> integrity. A path behaving in this manner should be deemed=20 >> unacceptable, but it has been noted that some implementations=20 >> relax the acceptance rules as a workaround, and allow TCP to run=20= >> across such paths. =20 >>=20 >>=20 >>=20 >> Richard Scheffenegger >>=20 >>=20 >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of >>> Joe Touch >>> Sent: Montag, 05. August 2013 20:40 >>> To: Scheffenegger, Richard >>> Cc: tcpm (tcpm@ietf.org) >>> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >>>=20 >>> Hi, Richard, >>>=20 >>> This is good. I do think that the lead is buried - the last sentence = is >>> the most important, and needs to be highlighted somehow - either = repeating >>> it earlier, setting it as a stand-alone sentence for emphasis, etc. >>>=20 >>> Joe >>>=20 >>> On 8/5/2013 2:32 AM, Scheffenegger, Richard wrote: >>>> Hi Joe, >>>>=20 >>>> Thank you for your input! >>>>=20 >>>> I reworded the paragraph slightly. With my background in data = storage, >>> the one thing to avoid is silent data corruption (storage companies = are >>> generally very paranoid about that), thus the use of "data = corruption" >>> twice in the text below. That wording may nudge market forces to = weed out >>> the "best effort" PAWS implementations over time. That would = agreeably be >>> an improvement above the current state. >>>>=20 >>>>=20 >>>> Implementations are strongly encouraged to follow the above >>> rules for >>>> handling a missing Timestamps option, and the order of = precedence >>>> mentioned in when deciding on the >>> acceptance of a >>>> segment. A TCP receiver not dropping segments without an = expected >>>> Timestamps option may expirience *undetectable* = wrapped-sequence >>> effects, >>>> such as data (payload) corruption or session stalls. In order = to >>> maintain >>>> the integrity of the payload data, in particular on high speed >>> networks, >>>> it is paramount to follow the described processing rules. >>>> >>>>=20 >>>> However, it has been mentioned that under some = circumstances, >>> the above >>>> guidelines are too strict, and some paths sporadically = suppress >>> the >>>> Timestamps option, while maintaining payload integrity. A path >>> behaving in >>>> this manner should be deemed inacceptable, but it has been = noted >>> that some >>>> implementations relax the acceptance rules as a workaround, = and >>> allow TCP >>>> to run across such paths. Again, if a receiver chooses to = accept >>> a segment >>>> without an expected Timestamps option, it must be clear that >>> undetectable >>>> data corruption may occur. >>>> >>>>=20 >>>> Richard Scheffenegger >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Joe Touch [mailto:touch@isi.edu] >>>>> Sent: Freitag, 02. August 2013 18:36 >>>>> To: Scheffenegger, Richard >>>>> Cc: Yuchung Cheng; Pasi Sarolahti; tcpm (tcpm@ietf.org) >>>>> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: >>>>> ... >>>>>> As there have been multiple comments to describe the effects of = this >>>>>> SHOULD, the following paragraph was added right after. This is = new >>>>>> text, and the first throw. Text donations are highly appreciated = if >>>>>> this text does not capture the purpose to the required extent: >>>>>>=20 >>>>>>=20 >>>>>> Implementations are strongly encouraged to follow the above >>>>>> rules >>>>> for >>>>>> handling a missing Timestamps option, and the order of = precedence >>>>>> mentioned in Section 4.3 when deciding on the acceptance of a >>>>>> segment. This is to maintain the integrity of the payload = data >>> at >>>>>> the receiver in particular on high speed networks. However, = it >>> has >>>>>> been mentioned that under some circumstances, the above >>> guidelines >>>>>> are too strict, and some paths sporadically suppress the >>> Timestamps >>>>>> option, while maintaining payload integrity. A path behaving >>>>>> in >>>>> this >>>>>> manner should be deemed inacceptable, but it has been noted = that >>>>>> relaxing the acceptance rules can serve as a workaround, and >>> allows >>>>>> TCP to run across such paths. >>>>>=20 >>>>> This misses the key issue, and it should not be glossed-over. >>>>>=20 >>>>> A TCP that SHOULD drop segment missing an expected TSOpt (as when = TS >>>>> is negotiated during the SYN) MAY experience ***undetectable*** >>>>> wrapped- sequence effects. >>>>>=20 >>>>> A TCP that MUST drop such segments WILL NOT experience such = effects. >>>>>=20 >>>>> So relaxing this constraint turns PAWS protection from a guarantee = to >>>>> a maybe - and it does so in ways that the source cannot determine. >>>>> The source presumably asked for PAWS, and the receiver agreed to = it, >>>>> but that guarantee is being turned into a maybe. >>>>>=20 >>>>> The big problem with allowing this SHOULD is it thus turns all TS >>>>> requests into "no PAWS provided". >>>>>=20 >>>>> So you've just killed PAWS. >>>>>=20 >>>>> Another victory for "rough consensus". >>>>>=20 >>>>> Joe >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@isi.edu Tue Aug 6 16:01:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD68F21E80AB for ; Tue, 6 Aug 2013 16:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.997 X-Spam-Level: X-Spam-Status: No, score=-105.997 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OTUESwqZgs8 for ; Tue, 6 Aug 2013 16:01:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 253DC21E80BF for ; Tue, 6 Aug 2013 16:01:26 -0700 (PDT) Received: from [128.9.184.125] ([128.9.184.125]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r76N13er018003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 16:01:03 -0700 (PDT) Message-ID: <52018035.6020109@isi.edu> Date: Tue, 06 Aug 2013 16:01:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Mason References: <25072_1373972624_51E52890_25072_797_1_012C3117EDDB3C4781FD802A8C27DD4F25C03BB4@SACEXCMBX02-PRD.hq.netapp.com> <85D44DE7-0A0B-4E8A-9E3D-E308D95666B0@iki.fi> <012C3117EDDB3C4781FD802A8C27DD4F25C500AA@SACEXCMBX06-PRD.hq.netapp.com> <51FBDFDE.8030900@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C64F4D@SACEXCMBX06-PRD.hq.netapp.com> <51FFF180.9070609@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F25C6A705@SACEXCMBX06-PRD.hq.netapp.com> <36FAC2F5-4D3F-4D49-ABA5-FB83F33344B9@isi.edu> In-Reply-To: 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 Cc: "tcpm \(tcpm@ietf.org\)" , "draft-ietf-tcpm-1323bis.authors@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Aug 2013 23:01:32 -0000 MUST is what the world ought to be. There are always legacy violations. The point of MUST is that this means they should be fixed, rather than left alone. Joe On 8/6/2013 3:51 PM, Kevin Mason wrote: > Joe, > I understand your point, but could there be legacy stack implementations that prevent declaring MUST? > > Kevin > On Aug 6, 2013, at 12:35 PM, Joe Touch wrote: > >> >> On Aug 6, 2013, at 6:40 AM, "Scheffenegger, Richard" wrote: >> >>> >>> Hi Joe, Kevin, Pasi, >>> >>> I have shuffled the sentences slightly, to reflect the suggested emphasis and make the point early and easier to spot. >>> The typo is also fixed. >> >> Thanks. I still prefer MUST with an explanation of how some endpoints violate that, FWIW. I don't think that having a TCP that compromises integrity "to allow TCP to run" makes ANY sense at all. >> >> Joe >> >>> >>> Unless anyone objects, I'll submit -15 in the next few hours with these changed paragraphs. >>> >>> >>> >>> Implementations are strongly encouraged to follow the above >>> rules for handling a missing Timestamps option, and the order of >>> precedence mentioned in Section 4.3 when deciding on the >>> acceptance of a segment. >>> >>> If a receiver chooses to accept a segment without an expected >>> Timestamps option, it must be clear that undetectable data >>> corruption may occur. >>> >>> Such a TCP receiver may experience undetectable wrapped- >>> sequence effects, such as data (payload) corruption or session >>> stalls. In order to maintain the integrity of the payload data, >>> in particular on high speed networks, it is paramount to follow >>> the described processing rules. >>> >>> However, it has been mentioned that under some circumstances, >>> the above guidelines are too strict, and some paths sporadically >>> suppress the Timestamps option, while maintaining payload >>> integrity. A path behaving in this manner should be deemed >>> unacceptable, but it has been noted that some implementations >>> relax the acceptance rules as a workaround, and allow TCP to run >>> across such paths. >>> >>> >>> >>> Richard Scheffenegger >>> >>> >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >>>> Joe Touch >>>> Sent: Montag, 05. August 2013 20:40 >>>> To: Scheffenegger, Richard >>>> Cc: tcpm (tcpm@ietf.org) >>>> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >>>> >>>> Hi, Richard, >>>> >>>> This is good. I do think that the lead is buried - the last sentence is >>>> the most important, and needs to be highlighted somehow - either repeating >>>> it earlier, setting it as a stand-alone sentence for emphasis, etc. >>>> >>>> Joe >>>> >>>> On 8/5/2013 2:32 AM, Scheffenegger, Richard wrote: >>>>> Hi Joe, >>>>> >>>>> Thank you for your input! >>>>> >>>>> I reworded the paragraph slightly. With my background in data storage, >>>> the one thing to avoid is silent data corruption (storage companies are >>>> generally very paranoid about that), thus the use of "data corruption" >>>> twice in the text below. That wording may nudge market forces to weed out >>>> the "best effort" PAWS implementations over time. That would agreeably be >>>> an improvement above the current state. >>>>> >>>>> >>>>> Implementations are strongly encouraged to follow the above >>>> rules for >>>>> handling a missing Timestamps option, and the order of precedence >>>>> mentioned in when deciding on the >>>> acceptance of a >>>>> segment. A TCP receiver not dropping segments without an expected >>>>> Timestamps option may expirience *undetectable* wrapped-sequence >>>> effects, >>>>> such as data (payload) corruption or session stalls. In order to >>>> maintain >>>>> the integrity of the payload data, in particular on high speed >>>> networks, >>>>> it is paramount to follow the described processing rules. >>>>> >>>>> >>>>> However, it has been mentioned that under some circumstances, >>>> the above >>>>> guidelines are too strict, and some paths sporadically suppress >>>> the >>>>> Timestamps option, while maintaining payload integrity. A path >>>> behaving in >>>>> this manner should be deemed inacceptable, but it has been noted >>>> that some >>>>> implementations relax the acceptance rules as a workaround, and >>>> allow TCP >>>>> to run across such paths. Again, if a receiver chooses to accept >>>> a segment >>>>> without an expected Timestamps option, it must be clear that >>>> undetectable >>>>> data corruption may occur. >>>>> >>>>> >>>>> Richard Scheffenegger >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Joe Touch [mailto:touch@isi.edu] >>>>>> Sent: Freitag, 02. August 2013 18:36 >>>>>> To: Scheffenegger, Richard >>>>>> Cc: Yuchung Cheng; Pasi Sarolahti; tcpm (tcpm@ietf.org) >>>>>> Subject: Re: [tcpm] draft-ietf-tcpm-1323bis-14.txt >>>>>> >>>>>> >>>>>> >>>>>> On 8/2/2013 6:55 AM, Scheffenegger, Richard wrote: >>>>>> ... >>>>>>> As there have been multiple comments to describe the effects of this >>>>>>> SHOULD, the following paragraph was added right after. This is new >>>>>>> text, and the first throw. Text donations are highly appreciated if >>>>>>> this text does not capture the purpose to the required extent: >>>>>>> >>>>>>> >>>>>>> Implementations are strongly encouraged to follow the above >>>>>>> rules >>>>>> for >>>>>>> handling a missing Timestamps option, and the order of precedence >>>>>>> mentioned in Section 4.3 when deciding on the acceptance of a >>>>>>> segment. This is to maintain the integrity of the payload data >>>> at >>>>>>> the receiver in particular on high speed networks. However, it >>>> has >>>>>>> been mentioned that under some circumstances, the above >>>> guidelines >>>>>>> are too strict, and some paths sporadically suppress the >>>> Timestamps >>>>>>> option, while maintaining payload integrity. A path behaving >>>>>>> in >>>>>> this >>>>>>> manner should be deemed inacceptable, but it has been noted that >>>>>>> relaxing the acceptance rules can serve as a workaround, and >>>> allows >>>>>>> TCP to run across such paths. >>>>>> >>>>>> This misses the key issue, and it should not be glossed-over. >>>>>> >>>>>> A TCP that SHOULD drop segment missing an expected TSOpt (as when TS >>>>>> is negotiated during the SYN) MAY experience ***undetectable*** >>>>>> wrapped- sequence effects. >>>>>> >>>>>> A TCP that MUST drop such segments WILL NOT experience such effects. >>>>>> >>>>>> So relaxing this constraint turns PAWS protection from a guarantee to >>>>>> a maybe - and it does so in ways that the source cannot determine. >>>>>> The source presumably asked for PAWS, and the receiver agreed to it, >>>>>> but that guarantee is being turned into a maybe. >>>>>> >>>>>> The big problem with allowing this SHOULD is it thus turns all TS >>>>>> requests into "no PAWS provided". >>>>>> >>>>>> So you've just killed PAWS. >>>>>> >>>>>> Another victory for "rough consensus". >>>>>> >>>>>> Joe >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> > From ycheng@google.com Wed Aug 7 18:32:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5AA11E80F6 for ; Wed, 7 Aug 2013 18:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqW8Fj3Y7A+g for ; Wed, 7 Aug 2013 18:32:15 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 76CDE11E8198 for ; Wed, 7 Aug 2013 18:32:15 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c11so850908ieb.10 for ; Wed, 07 Aug 2013 18:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=k12KqEE1RImlD35gKbkcg+cKzW1wytlYthoNnnV5mUU=; b=Xmo/d4EofOr0b6tVUrKpvL12FsCBhdGyEo0gA0HqOxhA0Bklc3nqfJkMOEOAgJTsoQ zff0LEO56F4zfEMaWHh5TtEgwxrN2Bzz6ABtlSPtb9SLDYzBQuyKHc3IJwAAB6wrrv3g uAGojd+z23jQ2p3rVe9jBtViR4QrsSZpTJAXYR2xcyYmS8tU6dXYU707j5hh2kUbZs6T RTgRbqosH3zntObHYJxq/GjfpjHHRYxlBidv2tiCO3/IqYkjClvFY9Q9vWeJ6dDdGQZn Wt/H3RlAOtlRCXiTq6V41STHnRFUylCaxW5knXlJjtG/bhTcxZDYM4TqzeMVn+rhvqpd wY/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=k12KqEE1RImlD35gKbkcg+cKzW1wytlYthoNnnV5mUU=; b=QL1voJa6VGKmhVbqMFNTxFoeZs/buJT6MwM5RzDbgMh3JByqQ0+V/NAU54PLubdo3E jizUp28vqvrCVh9macDPV+PZl8YFCnpugGZBt7zhCIv19VmQc0AkqZ85K6rwORiJvRg0 kmmxk95PXzCCh5ypnu8YIi+XSsB6b/WjwUIKxw/+pc9XSOJ6i8TAdrh+xxsiMPM+/ra2 wR8iThr+GgSLpvPT+A5a9TeObNTZUkxEbHjFkDQgFerYPXXnF86f0sPkbJnMHnTRLeBB kK7Jhkt9GtGrnsG++PdTprRoKFYZdMgUY08IX+BOOtcD7rZiTVxTtDvkIcTwDjG+o/Kw F+ow== X-Gm-Message-State: ALoCoQnpIiA6TfnlNjhNwtRWYxFkEgb7Rvfr81x+IaWPrgqFZF410hBrGMVyWTe3M/o6I9Y81zpN0Y9W+TsfFfMbw2Er3aOOvBc+QddX+aeQUKmUbB+d3VwHgeHYVBo0QQ4HSOS6jX9T1JO8/fH0RN9/A93akvRG22NPyolI9fcbyoRtkt1fE2xjRjlyc2oqE7BAqXXp7p50 X-Received: by 10.50.70.34 with SMTP id j2mr1002697igu.42.1375925534748; Wed, 07 Aug 2013 18:32:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.252.4 with HTTP; Wed, 7 Aug 2013 18:31:54 -0700 (PDT) From: Yuchung Cheng Date: Thu, 8 Aug 2013 02:31:54 +0100 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 01:32:16 -0000 a few suggestions on the categorization. s/2. Basic Functionality/2. Core Functionality 3.1 Fundamental Changes: I found it a little awkward to have "Fundamental Changes" under "recommended enhancements". Further: RFC5482 is not used/deployed, even tho Linux implements it. Why is it recommended and/or fundamental? both 3.2 and 3.3 have CC and loss recovery, I suggest we put all CC in 3.1 and LR in 3.2, 3.1: Congestion Control: RFC3465,RFC6633,RFC3168 3.2: Loss recovery RFC2018, RFC6675, RFC3042, RFC6582 3.3 Detection and Prevention of Spurious loss recovery Move DSACK and RFC3522 to this section. The reason is that Eifel response function depends on RFC3522 so they should be together for better context. Thanks. From lars@netapp.com Thu Aug 8 00:22:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3211E81B8 for ; Thu, 8 Aug 2013 00:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.915 X-Spam-Level: X-Spam-Status: No, score=-4.915 tagged_above=-999 required=5 tests=[AWL=-2.316, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHW2bYul3fZk for ; Thu, 8 Aug 2013 00:22:20 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE521F992E for ; Thu, 8 Aug 2013 00:21:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,837,1367996400"; d="asc'?scan'208";a="40053058" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 08 Aug 2013 00:21:57 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.240]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 8 Aug 2013 00:21:57 -0700 From: "Eggert, Lars" To: Yuchung Cheng Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 Thread-Index: AQHOk9cjNns8oJLVV0ySwx3x457KlpmLXZcA Date: Thu, 8 Aug 2013 07:21:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_42F43CB9-496C-4C8C-A28F-EF6C39D616B9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 07:22:25 -0000 --Apple-Mail=_42F43CB9-496C-4C8C-A28F-EF6C39D616B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 8, 2013, at 3:31, Yuchung Cheng wrote: > Further: RFC5482 is not used/deployed, even tho Linux implements > it. Why is it recommended and/or fundamental? As an author of that RFC, I agree with Yuchung. It shouldn't be in that = category. Lars --Apple-Mail=_42F43CB9-496C-4C8C-A28F-EF6C39D616B9 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 iQCVAwUBUgNHFNZcnpRveo1xAQL/zwQAmelULJmKvoiYVfQClDVSPxks+vOFeQyb QBn96rt8F0R2t/EMiM1nZXRv/26ToC0yKugRhRo8QhYlLHzDmBQ2ZPRhwlFWgHlF +SMU+hWdxXBllbvCbQlO6zSV2fGhDd4BAZiJZd6+hatu/cMhs2TlXmJpAAFuZ1Mr ZqXy1kPCMfU= =YR4i -----END PGP SIGNATURE----- --Apple-Mail=_42F43CB9-496C-4C8C-A28F-EF6C39D616B9-- From Alexander.Zimmermann@netapp.com Thu Aug 8 02:25:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301F321F9C9A for ; Thu, 8 Aug 2013 02:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-3.700, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxyQByDuscog for ; Thu, 8 Aug 2013 02:25:35 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id F353921F9D02 for ; Thu, 8 Aug 2013 02:25:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,838,1367996400"; d="asc'?scan'208";a="40076433" Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 08 Aug 2013 02:25:31 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.252]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Thu, 8 Aug 2013 02:25:31 -0700 From: "Zimmermann, Alexander" To: Yuchung Cheng Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 Thread-Index: AQHOk9cjavmpBvyUw0+uexU77ND+8ZmLgByA Date: Thu, 8 Aug 2013 09:25:30 +0000 Message-ID: <0FCE61E5-337C-4506-9FDD-2287B98677EC@netapp.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_FB121E76-A872-47D8-8E07-FA6802D899BA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 09:25:39 -0000 --Apple-Mail=_FB121E76-A872-47D8-8E07-FA6802D899BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 08.08.2013 um 03:31 schrieb Yuchung Cheng : > a few suggestions on the categorization. Thanks >=20 > s/2. Basic Functionality/2. Core Functionality Done >=20 > 3.1 Fundamental Changes: I found it a little awkward to have > "Fundamental Changes" under "recommended enhancements". =20 =46rom RFC 4614 (original TCP Roadmap) "=20 3. Recommended Enhancements This section describes recommended TCP modifications that improve performance and security. RFCs 1323 and 3168 represent fundamental changes to the protocol.=20 " As we can see, the original authors of the roadmap (and hopefully also TCPM :-)) saw RFC 1323 as a fundamental change. So, so the only thing I = did was to create a section with this title and put the RFC into. Nevertheless, if we believe now that the original text and therefore = also the title is misleading we can change them. > Further: RFC5482 is not used/deployed, even tho Linux implements > it. Why is it recommended Because it is standard track :-) But I agree with you, we should move RFC5482 to Sec 4. since it is not deployed (@Hagen submit your patch to netdev... :-)) I Sec 4. we do not have right subsection at the moment. I propose "4.5 TCP Timeouts" (or something similar). In this section we could also include "draft-ietf-tcpm-rtorestart-00", but I guess the roadmap will shipped earlier to IESG :-) > and/or fundamental? >=20 > both 3.2 and 3.3 have CC and loss recovery, I suggest we put all CC in > 3.1 and LR in 3.2, Fine by me. Maybe we should do the same thing with section 4.2? Any suggestions >=20 > 3.1: Congestion Control: > RFC3465,RFC6633,RFC3168 >=20 > 3.2: Loss recovery > RFC2018, RFC6675, RFC3042, RFC6582 >=20 > 3.3 Detection and Prevention of Spurious loss recovery > Move DSACK yes... > and RFC3522 to this section. hmm...=20 > The reason is that Eifel > response function depends on RFC3522 so they should be together for > better context. The same applies for RFC 3708... We have the subsection "Detection and Prevention of Spurious = Retransmissions" in both sections: Recommended Enhancements and Experimental Extensions. I think the reader able to connect this together. Moreover I put some = text in both section to connect them together. =20 >=20 >=20 > Thanks. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_FB121E76-A872-47D8-8E07-FA6802D899BA 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 iEYEARECAAYFAlIDZAoACgkQdyiq39b9uS7ubQCggG2YVpswlUdqslz7z/NnoAIV bI8An1EnhW1ey1zuGeTLx3EfR4MSQ50z =3YZk -----END PGP SIGNATURE----- --Apple-Mail=_FB121E76-A872-47D8-8E07-FA6802D899BA-- From pasi.sarolahti@iki.fi Thu Aug 8 07:07:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2F221F9C4E for ; Thu, 8 Aug 2013 07:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvr6NYphIkBh for ; Thu, 8 Aug 2013 07:07:09 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 47BE121F9C20 for ; Thu, 8 Aug 2013 07:07:09 -0700 (PDT) Received: from pc111.netlab.hut.fi (130.233.154.111) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 51BB5BE303F1B2E2; Thu, 8 Aug 2013 17:07:07 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Pasi Sarolahti In-Reply-To: <22210_1375279130_51F91819_22210_5274_1_655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 8 Aug 2013 17:06:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54F72E11-81F2-469D-B9A2-3012AE62EF52@iki.fi> References: <22210_1375279130_51F91819_22210_5274_1_655C07320163294895BBADA28372AF5D07AF5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "tcpm@ietf.org (tcpm@ietf.org)" X-Mailer: Apple Mail (2.1508) Subject: Re: [tcpm] WG acceptance of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 14:07:16 -0000 On Jul 31, 2013, at 4:57 PM, "Scharf, Michael (Michael)" = wrote: > In yesterday's meeting there was support for WG acceptance of = draft-zimmermann-tcpm-tcp-rfc4614bis-02. The chairs would like to = confirm this on the mailing list. >=20 > Please comment on the list if you have any thoughts or concerns = regarding adoption of this draft until August 7, 2013. No one has objected adoption, so authors, please submit the next version = as draft-ietf-tcpm-rfc4614bis-00. - Pasi From wwwrun@rfc-editor.org Thu Aug 8 12:32:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571E721E8064; Thu, 8 Aug 2013 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.926 X-Spam-Level: X-Spam-Status: No, score=-101.926 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d9ML4mr1384; Thu, 8 Aug 2013 12:32:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4521E8088; Thu, 8 Aug 2013 12:32:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 570C7B1E009; Thu, 8 Aug 2013 12:28:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130808192823.570C7B1E009@rfc-editor.org> Date: Thu, 8 Aug 2013 12:28:23 -0700 (PDT) Cc: drafts-update-ref@iana.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6994 on Shared Use of Experimental TCP Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 19:32:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6994 Title: Shared Use of Experimental TCP Options Author: J. Touch Status: Standards Track Stream: IETF Date: August 2013 Mailbox: touch@isi.edu Pages: 11 Characters: 25577 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-experimental-options-06.txt URL: http://www.rfc-editor.org/rfc/rfc6994.txt This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hagen@jauu.net Thu Aug 8 14:11:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C2C21E808A for ; Thu, 8 Aug 2013 14:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnFRAmLHH9+m for ; Thu, 8 Aug 2013 14:11:10 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id A1ABE21E8089 for ; Thu, 8 Aug 2013 14:11:01 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1V7XTu-0002Ol-GI; Thu, 08 Aug 2013 23:10:50 +0200 Date: Thu, 8 Aug 2013 23:13:51 +0200 From: Hagen Paul Pfeifer To: "Zimmermann, Alexander" Message-ID: <20130808211351.GA8110@localhost.localdomain> References: <0FCE61E5-337C-4506-9FDD-2287B98677EC@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0FCE61E5-337C-4506-9FDD-2287B98677EC@netapp.com> X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 21:11:12 -0000 * Zimmermann, Alexander | 2013-08-08 09:25:30 [+0000]: >Because it is standard track :-) But I agree with you, we should move >RFC5482 to Sec 4. since it is not deployed (@Hagen submit your patch to >netdev... :-)) patch is nearly complete: already rebased on net-next but some IPv6 issues are still around. Next week I will post the patch to netdev - I swear! ;-) Hagen From hagen@jauu.net Thu Aug 8 14:20:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBA411E822E for ; Thu, 8 Aug 2013 14:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Vtd3W7EK2o for ; Thu, 8 Aug 2013 14:20:20 -0700 (PDT) Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF0511E822C for ; Thu, 8 Aug 2013 14:20:20 -0700 (PDT) Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.80) (envelope-from ) id 1V7Xd0-0002Rr-5s; Thu, 08 Aug 2013 23:20:14 +0200 Date: Thu, 8 Aug 2013 23:23:15 +0200 From: Hagen Paul Pfeifer To: Yuchung Cheng Message-ID: <20130808212315.GB8110@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] review of draft-zimmermann-tcpm-tcp-rfc4614bis-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 21:20:21 -0000 * Yuchung Cheng | 2013-08-08 02:31:54 [+0100]: >3.1 Fundamental Changes: I found it a little awkward to have >"Fundamental Changes" under "recommended enhancements". > Further: RFC5482 is not used/deployed, even tho Linux implements >it. Why is it recommended and/or fundamental? BTW: a FreeBSD implementation also exists! The FreeBSD guys did some interop analysis with my Linux implementation. Hagen From internet-drafts@ietf.org Fri Aug 9 06:17:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519AA21F9C7D; Fri, 9 Aug 2013 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bybnYF+ctTXQ; Fri, 9 Aug 2013 06:17:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ED621F9BEF; Fri, 9 Aug 2013 06:17:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130809131743.28970.51564.idtracker@ietfa.amsl.com> Date: Fri, 09 Aug 2013 06:17:43 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 13:17:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : A Roadmap for Transmission Control Protocol (TCP) Specif= ication Documents Author(s) : Martin Duke Robert Braden Wesley M. Eddy Ethan Blanton Alexander Zimmermann Filename : draft-ietf-tcpm-tcp-rfc4614bis-00.txt Pages : 49 Date : 2013-08-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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Alexander.Zimmermann@netapp.com Fri Aug 9 06:58:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6E21F9D8A for ; Fri, 9 Aug 2013 06:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.374 X-Spam-Level: X-Spam-Status: No, score=-5.374 tagged_above=-999 required=5 tests=[AWL=-2.775, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jls4N8VTTpe7 for ; Fri, 9 Aug 2013 06:57:49 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F421F967C for ; Fri, 9 Aug 2013 06:57:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="asc'?scan'208";a="40387801" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 09 Aug 2013 06:57:49 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.252]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Fri, 9 Aug 2013 06:57:49 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-00.txt Thread-Index: AQHOlQMQdw8YLMa5JUajZWfD0d1eqZmNXC4A Date: Fri, 9 Aug 2013 13:57:48 +0000 Message-ID: <6F699CA9-5637-43BD-92FC-6D8D80CFB1B0@netapp.com> References: <20130809131743.28970.51564.idtracker@ietfa.amsl.com> In-Reply-To: <20130809131743.28970.51564.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.104.60.114] Content-Type: multipart/signed; boundary="Apple-Mail=_6E5232A7-62A9-43A9-ACF5-AC92C17FEF52"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-rfc4614bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 13:58:02 -0000 --Apple-Mail=_6E5232A7-62A9-43A9-ACF5-AC92C17FEF52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, in the 00-Version I did not incorporate all feedback from Yuchung since I want to have more feedback from the list. Open points are: * Where we put RFC5482 (UTO)? I tend to create a new subsection in section 3 "TCP Timeouts", but leave the doc in sec 3 * Restructuring of subsec 3.2 and 3.3. - 3.2: Congestion Control Extensions: RFC3465, RFC6633, RFC3168 - 3.3: Loss Recovery Extensions: RFC2018 ,RFC6675, RFC3042, = RFC6582 - Move RFC2883 (DSACK to) 3.3 I'm open to this. However, we decide to do this, we may do the same with 4.1, which means to spit the sec into 2 subsecs * Should we move Eifel Dection (RFC3522) to sec 3.3? I do not see a strong reason for doing this (see my answer to Yuchung) * Are we happy with the new IANA section? Alex Am 09.08.2013 um 15:17 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 > Author(s) : Martin Duke > Robert Braden > Wesley M. Eddy > Ethan Blanton > Alexander Zimmermann > Filename : draft-ietf-tcpm-tcp-rfc4614bis-00.txt > Pages : 49 > Date : 2013-08-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-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_6E5232A7-62A9-43A9-ACF5-AC92C17FEF52 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 iEYEARECAAYFAlIE9VwACgkQdyiq39b9uS7uvwCg7ntYkRHJph0oJqgiaqE/EX2j /T0AnR6KyNe9wHFBhyKbBBmyQa+Vkd88 =mIVm -----END PGP SIGNATURE----- --Apple-Mail=_6E5232A7-62A9-43A9-ACF5-AC92C17FEF52-- From patrick.ducksong@gmail.com Fri Aug 9 09:43:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE57121F963F for ; Fri, 9 Aug 2013 09:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3WbM18MTNWD for ; Fri, 9 Aug 2013 09:43:47 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C1DF011E81D6 for ; Fri, 9 Aug 2013 09:36:29 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so7161250oag.33 for ; Fri, 09 Aug 2013 09:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QabS4JQog0HD+7ekzlxFDhN1SN8kdEI5QzikH1Y6akE=; b=EZqFiICciE427hlM7HjPx+k3pZs5Vl4u4l8J9cXhx/YjzJPpdCMjL60CMLnWnT3Neb PsXxkPw0JnnIIkw6qK8Dvrh8lOHuVqA7f/APMQELWPvDV7kXQ0kldHiEu1W87gQnT0fd mnt7YzPfSNgWNpaozUqXIdrfjzcdwBr/njy742wcLHfeoqOHdw0sJxPtqCeCv+xQjVB7 rNnQfGYBzXDFUdT+GmKU1wVIw7NjI+Eet16NvxVMhVgXrhDzbJ8EllVsSV6RCX5UUiWI ruyoS+GrJvgcy0d3qgnS6wDBMGKMw8foXJi4i1X+JOFp0R1si3WKHYKNJ9gJ8Cj8PHR1 6R+A== MIME-Version: 1.0 X-Received: by 10.60.94.210 with SMTP id de18mr1081443oeb.100.1376066189329; Fri, 09 Aug 2013 09:36:29 -0700 (PDT) Sender: patrick.ducksong@gmail.com Received: by 10.76.90.228 with HTTP; Fri, 9 Aug 2013 09:36:29 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 9 Aug 2013 12:36:29 -0400 X-Google-Sender-Auth: zDk-FDJk6IFaZ4nffESTEOBgWj8 Message-ID: From: Patrick McManus To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=089e0117689d670a7c04e38660d9 Cc: "Mankin, Allison" , "tcpm@ietf.org" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 17:12:46 -0000 --089e0117689d670a7c04e38660d9 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael - since this thread has been quiet for a week I'll just chime in with my understanding of the issue. I interpreted Allison as reminding the HTTPbis WG that due to the weak TCP checksum large streams will have a significant chance of containing undetected errors. This is more relevant to HTTP 2 than HTTP 1 (not to say it is irrelevant to HTTP 1) because the application protocol of HTTP-2 introduces a couple new stateful mechanisms (e.g. compressed header dictionaries and credit schemes) that rely on both peers seeing identical streams to work correctly. She suggested TLS as an obvious mitigation and I would concur that HTTP/2 should always be carried over TLS (for a variety of reasons). -Patrick (aka pmcmanus@mozilla.com) On Fri, Aug 2, 2013 at 6:24 AM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Hi all, > > In today's httpbis joint meeting, there was a brief discussion about > potential issues related to the TCP checksum. > > Since I am not aware of a recent discussion regarding the TCP checksum (it > surely has been discussed quite a bit in the past, e.g., RFC 1146), this > e-mail tries to trigger a follow-up discussion. I am particularly > interested in better understanding any potential issues in the context of > HTTP/2. > > Thanks > > Michael > > > PS: The TCP offloading issues and RFC 1936 should be obvious. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --089e0117689d670a7c04e38660d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael - since this thread has been quiet fo= r a week I'll just chime in with my understanding of the issue.

=
I interpreted Allison as reminding the HTTPbis WG that due to the wea= k TCP checksum large streams will have a significant chance of containing u= ndetected errors. This is more relevant to HTTP 2 than HTTP 1 (not to say i= t is irrelevant to HTTP 1) because the application protocol of HTTP-2 intro= duces a couple new stateful mechanisms (e.g. compressed header dictionaries= and credit schemes) that rely on both peers seeing identical streams to wo= rk correctly.

She suggested TLS as an obvious mitigation and I would concur tha= t HTTP/2 should always be carried over TLS (for a variety of reasons).
<= br>-Patrick (aka = pmcmanus@mozilla.com)



On = Fri, Aug 2, 2013 at 6:24 AM, Scharf, Michael (Michael) &l= t;mi= chael.scharf@alcatel-lucent.com> wrote:
Hi all,

In today's httpbis joint meeting, there was a brief discussion about po= tential issues related to the TCP checksum.

Since I am not aware of a recent discussion regarding the TCP checksum (it = surely has been discussed quite a bit in the past, e.g., RFC 1146), this e-= mail tries to trigger a follow-up discussion. I am particularly interested = in better understanding any potential issues in the context of HTTP/2.

Thanks

Michael


PS: The TCP offloading issues and RFC 1936 should be obvious.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--089e0117689d670a7c04e38660d9-- From ycheng@google.com Fri Aug 9 10:39:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3521F9BA0 for ; Fri, 9 Aug 2013 10:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo30Y3iI-Ztp for ; Fri, 9 Aug 2013 10:39:47 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id DC56411E8135 for ; Fri, 9 Aug 2013 10:33:22 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id 9so4411432iec.7 for ; Fri, 09 Aug 2013 10:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yZlehUhIpDYoeGc35h8PPOYOb+ZCjrusSYnF+w+P5cM=; b=ELIyCyH4gcvggkBpv6TTdoFznGS9chPMTlka80uoUoGWhS14QLTpq+nJc2Ktx3lZHv WZjvZne8G9gIgMfmDIqUPNA3uVcuadVNR9zL228UtqCXsHXt1upiCkA5FjNxGr0oMlyj dWbARifvxFrDw5f3VYaWqcZbq4oaH522AareHAYAAfP98E5nHKBD9/wrehYjUc/QcrwG YNXXgvzV5+csQy6UIu/dLvSRrZJwbq9nHVr43V9pii4qMhjJVJirdbLGydv2H8zoDr9l iEngEpx7xojx57M5s5zyqX7EzavLEIe0rXUcerMA0xze55N9HIRC2u2vuD68hhK1Sy1r CFMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yZlehUhIpDYoeGc35h8PPOYOb+ZCjrusSYnF+w+P5cM=; b=hP7FF9PVVEWcI3hCAcL+joHIzwHK+JyNbxGznqU3dDQJkd/RAVuFU9vrN5nGGJTdk5 YS1vRrUb/s0ltKn+WWBrnfb2P9tYOQKSV6IwETTrtREBP28BCwArjKcy3kNAhXYecSvN 2LzS/WnxotxHa0+eQOqy54zJKkySs15xhL8WSExo6nQFvXeDLo6dG6fxV59G92EwZWx5 nazaKd3Uz61KblB4eOoDhuLp+nmR8qKeij/mU+l2mKWRTIeO2/Hi4Lm2Ro4eD4ZU0q2+ qLcvNsTiBosQjQ+8Jb/xZmrWXT9Ch8OBY8dJhr/uxZsZmfozIfBGWqeltdVbQZkeiTer LcMQ== X-Gm-Message-State: ALoCoQlTNqHAs87QXoEasjenQ3J5k+I1jfBxZd8lwTYjowrBCLeq0holugBhAr+I6qVDZGQLzRF48b/dNaEN8QmNzEU/4+JWcAm38dkRFKjAS+kkoYZv7PjddmSro0K+ZMGuseiV4FGMlNdOpNeXiOmgnWf/COFKfn2neM+thijvCjaIevSrtdVqgUm7rYQpoQ6e8na7tavh X-Received: by 10.42.173.136 with SMTP id r8mr5032897icz.26.1376069601402; Fri, 09 Aug 2013 10:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.252.4 with HTTP; Fri, 9 Aug 2013 10:33:01 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Fri, 9 Aug 2013 10:33:01 -0700 Message-ID: To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org" , "Mankin, Allison" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 17:39:51 -0000 This paper has some interesting analysis http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf ""After an analysis we conclude that the checksum will fail to detect errors for roughly 1 in 16 million to 10 billion packets. From our analysis of the cause of errors"" It's no longer a small chance given the Web page size today. On Fri, Aug 9, 2013 at 9:36 AM, Patrick McManus wrote: > Hi Michael - since this thread has been quiet for a week I'll just chime in > with my understanding of the issue. > > I interpreted Allison as reminding the HTTPbis WG that due to the weak TCP > checksum large streams will have a significant chance of containing > undetected errors. This is more relevant to HTTP 2 than HTTP 1 (not to say > it is irrelevant to HTTP 1) because the application protocol of HTTP-2 > introduces a couple new stateful mechanisms (e.g. compressed header > dictionaries and credit schemes) that rely on both peers seeing identical > streams to work correctly. > > She suggested TLS as an obvious mitigation and I would concur that HTTP/2 > should always be carried over TLS (for a variety of reasons). > > -Patrick (aka pmcmanus@mozilla.com) > > > > On Fri, Aug 2, 2013 at 6:24 AM, Scharf, Michael (Michael) > wrote: >> >> Hi all, >> >> In today's httpbis joint meeting, there was a brief discussion about >> potential issues related to the TCP checksum. >> >> Since I am not aware of a recent discussion regarding the TCP checksum (it >> surely has been discussed quite a bit in the past, e.g., RFC 1146), this >> e-mail tries to trigger a follow-up discussion. I am particularly interested >> in better understanding any potential issues in the context of HTTP/2. >> >> Thanks >> >> Michael >> >> >> PS: The TCP offloading issues and RFC 1936 should be obvious. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Fri Aug 9 12:04:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB44911E8237 for ; Fri, 9 Aug 2013 12:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.017 X-Spam-Level: X-Spam-Status: No, score=-106.017 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfniMvys3s9h for ; Fri, 9 Aug 2013 12:04:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 635F721F8F78 for ; Fri, 9 Aug 2013 11:58:51 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r79Iwgs0004963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Aug 2013 11:58:43 -0700 (PDT) Message-ID: <52053BE2.2090706@isi.edu> Date: Fri, 09 Aug 2013 11:58:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yuchung Cheng References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: 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 Cc: Patrick McManus , "tcpm@ietf.org" , "Mankin, Allison" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 19:04:51 -0000 On 8/9/2013 10:33 AM, Yuchung Cheng wrote: > This paper has some interesting analysis > http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf > > ""After an analysis we conclude that the checksum will fail to detect > errors for roughly 1 in 16 million to 10 billion packets. From our > analysis of the cause of errors"" > > It's no longer a small chance given the Web page size today. 16 million would be 22 megabytes, but that TCP isn't the only place that errors are detected. There's the link layer on each link, and the application layer. It's not clear that we actually do need to rely on TCP to detect such problems. However, if that's not enough, simply using security (IPsec, TLS) would protected much better. Joe From touch@isi.edu Fri Aug 9 12:10:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3755B21F9B80 for ; Fri, 9 Aug 2013 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=-2.135, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld4dLJCfvGYv for ; Fri, 9 Aug 2013 12:10:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3405F21F9BEF for ; Fri, 9 Aug 2013 12:02:28 -0700 (PDT) Received: from [128.9.184.177] ([128.9.184.177]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r79J1xFp027982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 12:02:00 -0700 (PDT) References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52053BE2.2090706@isi.edu> In-Reply-To: <52053BE2.2090706@isi.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10B350) From: Joe Touch Date: Fri, 9 Aug 2013 12:02:00 -0700 To: Yuchung Cheng X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Patrick McManus , "tcpm@ietf.org" , "Mankin, Allison" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 19:10:59 -0000 On Aug 9, 2013, at 11:58 AM, Joe Touch wrote: >=20 >=20 > On 8/9/2013 10:33 AM, Yuchung Cheng wrote: >> This paper has some interesting analysis >> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pd= f >>=20 >> ""After an analysis we conclude that the checksum will fail to detect >> errors for roughly 1 in 16 million to 10 billion packets. =46rom our >> analysis of the cause of errors"" >>=20 >> It's no longer a small chance given the Web page size today. >=20 > 16 million would be 22 megabytes, but that TCP isn't the only place that e= rrors are detected. Make that gigabytes. Which I also doubt is a common web anything.=20 > There's the link layer on each link, and the application layer. It's not c= lear that we actually do need to rely on TCP to detect such problems. >=20 > However, if that's not enough, simply using security (IPsec, TLS) would pr= otected much better. >=20 > Joe From rick.jones2@hp.com Fri Aug 9 12:20:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0D11E80D3 for ; Fri, 9 Aug 2013 12:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzoGHEyjgbX8 for ; Fri, 9 Aug 2013 12:19:57 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8D721F8EB3 for ; Fri, 9 Aug 2013 12:13:12 -0700 (PDT) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0026.austin.hp.com (Postfix) with ESMTP id E04C2C1E2; Fri, 9 Aug 2013 19:13:09 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g1t0038.austin.hp.com (Postfix) with ESMTP id D6E41301DC; Fri, 9 Aug 2013 19:13:07 +0000 (UTC) Message-ID: <52053F43.7010209@hp.com> Date: Fri, 09 Aug 2013 12:13:07 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Joe Touch References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52053BE2.2090706@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Mankin, Allison" , Patrick McManus , "tcpm@ietf.org" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 19:20:02 -0000 On 08/09/2013 12:02 PM, Joe Touch wrote: > > > On Aug 9, 2013, at 11:58 AM, Joe Touch wrote: > >> >> >> On 8/9/2013 10:33 AM, Yuchung Cheng wrote: >>> This paper has some interesting analysis >>> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf >>> >>> ""After an analysis we conclude that the checksum will fail to detect >>> errors for roughly 1 in 16 million to 10 billion packets. From our >>> analysis of the cause of errors"" >>> >>> It's no longer a small chance given the Web page size today. >> >> 16 million would be 22 megabytes, but that TCP isn't the only place that errors are detected. > > Make that gigabytes. Which I also doubt is a common web anything. True, but wouldn't that then be one out of ~22K 1MB web transfers? rick jones From ycheng@google.com Fri Aug 9 12:23:23 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E72421F9D4C for ; Fri, 9 Aug 2013 12:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wQAfwG-28iY for ; Fri, 9 Aug 2013 12:23:22 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9772821F98AD for ; Fri, 9 Aug 2013 12:17:16 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c11so4806451ieb.38 for ; Fri, 09 Aug 2013 12:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JYlDYnr6dzQRU9Q078wcO00+V4AIJDBhTbLpe6BZAjA=; b=RaiaDOCYOM+zS4fa26yJG4anEayZKBp/WIaXyVHuDSV4uT2YDqR3V1l0I7KBI6yynR wGwriDiIar4yv6QPktzxDspyE1OxBZS81LZQPXlFx6RgrbJc5YBW57iYwZGxN3tpRnao qAnyixdDorHQYuL09P6cQEDgx8XBJe4ftHTwHlN4SBkxsMVHj2xXn9f77sZyRXgU3Z+J M0zzTjpiCtAbXGNFOhf1kpvKM4l8aXKQBDkkB2Bn6teZA6Qu3RdBw+AErskb7y67ANxN YdZ/1fgxYQ5NQTax7UKZ61f3sHlEBSmSi2Auyb2eBLUhloj5IaTA94HgrSjT8TWY59sX ZaPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JYlDYnr6dzQRU9Q078wcO00+V4AIJDBhTbLpe6BZAjA=; b=C5kvPEpguH0jTT0cJRVV+HI2HcJsHkeff0XnPXHXfr07Kef91eEhqAcywimT3xPcex NpA08+xjWuEfttCj8tQ8Bqf7SbzHHjHRUXkjcQew5d4mJp3HQ7oomu2Ux3nmB7XRrXRE 5zEKtqivvvwlz826sfQpQ7xlY57txqXTcdLiS3XJJIvAT0enkYtDby4YtJ1J3FU0Q/xi A2Sa2GDRzFjp/PfsSbiqQJH9je7tC34iBB26TjBnhG5X0zF6ABDntY9T+AJpXrcMYAre YkmoLEnj9d2Ht1/CL2xGKKZhJ8zM13Xo/f0rXZE44Q4V7cDT06WXeWk/ZyqdD3Dkcebm CuoQ== X-Gm-Message-State: ALoCoQnxYbfYSCZsFucAxQ0bzqaWddls/IzBg4uJmeJTn1q6ezWLDIUuf7lVBi1F1451omvgKMRgHOQUCs4kcUPjL8ycmgJaZ4oEohOgEbIqLbOEx9Gfmq5UIWG5cN2Zl4eZAvfdAJDbqV1ZslQBvV5jFlZwOsxuXQjXxBr7NmMBoeaofdgCQMzGXf+X6jzCM3+ejdR13P2U X-Received: by 10.42.109.138 with SMTP id l10mr5054967icp.38.1376075836169; Fri, 09 Aug 2013 12:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.252.4 with HTTP; Fri, 9 Aug 2013 12:16:56 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52053BE2.2090706@isi.edu> From: Yuchung Cheng Date: Fri, 9 Aug 2013 12:16:56 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: Patrick McManus , "ietf-http-wg@w3.org" , "tcpm@ietf.org" , "Mankin, Allison" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 19:23:23 -0000 On Fri, Aug 9, 2013 at 12:02 PM, Joe Touch wrote: > > > On Aug 9, 2013, at 11:58 AM, Joe Touch wrote: > >> >> >> On 8/9/2013 10:33 AM, Yuchung Cheng wrote: >>> This paper has some interesting analysis >>> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf >>> >>> ""After an analysis we conclude that the checksum will fail to detect >>> errors for roughly 1 in 16 million to 10 billion packets. From our >>> analysis of the cause of errors"" >>> >>> It's no longer a small chance given the Web page size today. >> >> 16 million would be 22 megabytes, but that TCP isn't the only place that errors are detected. > > Make that gigabytes. Which I also doubt is a common web anything. Yeah I thought so too. But the fact this is raised in the httpbis/tsv joint meeting means I was wrong. This is the exact point of having more joint meeting to bridge httpbis/tsv. > >> There's the link layer on each link, and the application layer. It's not clear that we actually do need to rely on TCP to detect such problems. >> >> However, if that's not enough, simply using security (IPsec, TLS) would protected much better. >> >> Joe From johnwheffner@gmail.com Fri Aug 9 12:49:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69241F0D61 for ; Fri, 9 Aug 2013 12:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWG-MSKLMmgW for ; Fri, 9 Aug 2013 12:49:16 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id F357B21F9D71 for ; Fri, 9 Aug 2013 12:42:31 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id gf12so1319467vcb.8 for ; Fri, 09 Aug 2013 12:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XJ9QgS+AxiiMxoKtGp27S4taTFe8XJJAvtv+ixJ6kaI=; b=YVdBTXypiNh2Y0IaOOA5gwxKqSYIHa5Wq6mCiivAhIvT8+GDdHhlpVFFplpqQ2kUia 07NVknDZgH2vD8aXuLzHtaH9Z0/DQJliaei/JzpnypJB89B1FiMrcC2vYINS3WJSsFbf iouosjeS5Z8A69eSRBkkvumN8/bjO97yMFQCZPlHORMDu9G7OARy5F2/0glkTbgdRpYa JIWjJO9H92kQgcVw0C2NX1jE461wTFHNijPuqwATrJPrxL5cVYLLrg9QHfRj1CsW2Q6d z/iwQO0ozWac0dknmls+hpNgtpIs/k6M4zlwofgmMM6pOxTJKrSOh15VFXHjndnccpBU x18w== MIME-Version: 1.0 X-Received: by 10.220.86.200 with SMTP id t8mr1325191vcl.49.1376077350351; Fri, 09 Aug 2013 12:42:30 -0700 (PDT) Received: by 10.220.93.74 with HTTP; Fri, 9 Aug 2013 12:42:30 -0700 (PDT) In-Reply-To: <52053BE2.2090706@isi.edu> References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52053BE2.2090706@isi.edu> Date: Fri, 9 Aug 2013 15:42:30 -0400 Message-ID: From: John Heffner To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: "Mankin, Allison" , Patrick McManus , "tcpm@ietf.org" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 19:49:20 -0000 On Fri, Aug 9, 2013 at 2:58 PM, Joe Touch wrote: > > > On 8/9/2013 10:33 AM, Yuchung Cheng wrote: >> >> This paper has some interesting analysis >> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf >> >> ""After an analysis we conclude that the checksum will fail to detect >> errors for roughly 1 in 16 million to 10 billion packets. From our >> analysis of the cause of errors"" >> >> It's no longer a small chance given the Web page size today. > > > 16 million would be 22 megabytes, but that TCP isn't the only place that > errors are detected. > > There's the link layer on each link, and the application layer. It's not > clear that we actually do need to rely on TCP to detect such problems. > > However, if that's not enough, simply using security (IPsec, TLS) would > protected much better. >From the paper: "Note that many encryption solutions such as IPsec do not provide additional protection. The encryption is applied too late in the transmission process, often after the data has passed through a DMA engine. Rather the application must add the checksum before handing its data to TCP (ala SSL)." It's also worth noting that hardware offload of TCP checksum calculation is commonplace now, which eliminates even the protection of that weak checksum. -John From touch@isi.edu Fri Aug 9 13:29:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B143A21F99E9 for ; Fri, 9 Aug 2013 13:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.969 X-Spam-Level: X-Spam-Status: No, score=-103.969 tagged_above=-999 required=5 tests=[AWL=-1.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS76T39f-ntC for ; Fri, 9 Aug 2013 13:29:50 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id AA95F21F9B4D for ; Fri, 9 Aug 2013 13:22:35 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r79KLqMu022807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Aug 2013 13:21:52 -0700 (PDT) Message-ID: <52054F5F.40600@isi.edu> Date: Fri, 09 Aug 2013 13:21:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Rick Jones References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52053BE2.2090706@isi.edu> <52053F43.7010209@hp.com> In-Reply-To: <52053F43.7010209@hp.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 Cc: "Mankin, Allison" , Patrick McManus , "tcpm@ietf.org" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 20:29:54 -0000 On 8/9/2013 12:13 PM, Rick Jones wrote: > On 08/09/2013 12:02 PM, Joe Touch wrote: >> >> >> On Aug 9, 2013, at 11:58 AM, Joe Touch wrote: >> >>> >>> >>> On 8/9/2013 10:33 AM, Yuchung Cheng wrote: >>>> This paper has some interesting analysis >>>> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf >>>> >>>> >>>> ""After an analysis we conclude that the checksum will fail to detect >>>> errors for roughly 1 in 16 million to 10 billion packets. From our >>>> analysis of the cause of errors"" >>>> >>>> It's no longer a small chance given the Web page size today. >>> >>> 16 million would be 22 megabytes, but that TCP isn't the only place >>> that errors are detected. >> >> Make that gigabytes. Which I also doubt is a common web anything. > > True, but wouldn't that then be one out of ~22K 1MB web transfers? It's possible, but again it ignores protections at other layers too. Joe From touch@isi.edu Fri Aug 9 13:30:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329BB11E81A7 for ; Fri, 9 Aug 2013 13:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.928 X-Spam-Level: X-Spam-Status: No, score=-103.928 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6H89z6owi6M for ; Fri, 9 Aug 2013 13:30:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F121E8051 for ; Fri, 9 Aug 2013 13:25:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r79KPAY5023796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Aug 2013 13:25:10 -0700 (PDT) Message-ID: <52055025.7070204@isi.edu> Date: Fri, 09 Aug 2013 13:25:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Heffner References: <655C07320163294895BBADA28372AF5D07CC4E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <52053BE2.2090706@isi.edu> In-Reply-To: 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 Cc: "Mankin, Allison" , Patrick McManus , "tcpm@ietf.org" , Mark Nottingham Subject: Re: [tcpm] TCP checksum issues? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 20:30:47 -0000 On 8/9/2013 12:42 PM, John Heffner wrote: > On Fri, Aug 9, 2013 at 2:58 PM, Joe Touch wrote: >> >> >> On 8/9/2013 10:33 AM, Yuchung Cheng wrote: >>> >>> This paper has some interesting analysis >>> http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf >>> >>> ""After an analysis we conclude that the checksum will fail to detect >>> errors for roughly 1 in 16 million to 10 billion packets. From our >>> analysis of the cause of errors"" >>> >>> It's no longer a small chance given the Web page size today. >> >> >> 16 million would be 22 megabytes, but that TCP isn't the only place that >> errors are detected. >> >> There's the link layer on each link, and the application layer. It's not >> clear that we actually do need to rely on TCP to detect such problems. >> >> However, if that's not enough, simply using security (IPsec, TLS) would >> protected much better. > >>From the paper: > "Note that many encryption solutions such as IPsec do not provide > additional protection. The encryption is applied > too late in the transmission process, often after the data has passed > through a DMA engine. Rather the application must add the checksum > before handing its data to TCP (ala SSL)." > > It's also worth noting that hardware offload of TCP checksum > calculation is commonplace now, which eliminates even the protection > of that weak checksum. Right, but that emphasizes the point - what kind of error is happening, and is TCP the only layer that would detect that error or would it have been caught elsewhere. TCP isn't a checksum to the app anyway; it's to the OS in most implementations, so the fact that it might not protect between the NIC and main memory is only one of a few places that other errors can arise (e.g., NIC to main memory, main memory to the destination device [video memory, disk interface], etc.). Joe Joe From ycheng@google.com Fri Aug 9 16:44:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18BA11E8127 for ; Fri, 9 Aug 2013 16:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKp7rHTmjnLM for ; Fri, 9 Aug 2013 16:44:28 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 55AC321F9AA8 for ; Fri, 9 Aug 2013 16:38:17 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id aq17so4984606iec.25 for ; Fri, 09 Aug 2013 16:38:17 -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=DC4JZPDMx9UnwEVJmTcVnuIjJNLNsoU35g4q8NLyiTU=; b=XTqadpTIH9RcP+2A7Zk0b3Fss9Ql8XUOp5hPDRI0i4q04tpL/4qA2NmIpTEfwk3+0l mP+FSR6UrXrgnMypzM1eqEgWos57wLhtBnoURbZP1Sw2woOvJ99msuQtdrWux4TZ/4eG u4oP4MGjUrdED1ge0CwPow7qINg9WXTHpPwLdxjzuqro3sPu//JuwfEPBaFJego59BsM EY9Q/YwMuojh/Fl9V8k1hxkCvjk2sGRKKjQf6SAEJtHLlkcx8e2T4+5x+PJFhj80E78U iNihxlv4miNnLvu9r7j4cbllzqy3YQa+GnL6DuKhPKE1N+DzVgQNo6cjCaiRIbvMWbWh O4Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=DC4JZPDMx9UnwEVJmTcVnuIjJNLNsoU35g4q8NLyiTU=; b=gFYa7yAdYJ5iTBlBnh0ySrwXBieLBLk4yj0AbCVLla+DhB9t9h0nNOh/Y4CImETi9U huewpSGcUAdn69jJ4htYoX0wSsOKkk1zGq+H2VMrr14qawiulOC/6t5p9VKdkpXXBwqM 6qIZeTXtMbyIFY+X8tkhwaXhYPNC0Ir0K6bO2v7R9OcDSfjQubCkEbJQPZWKOgTAwYzO y6V06WprYPvKQ4qVksiYDzK224mEg43zkcq6McF99kXCbK+w/O6H7sNjGS27LioarUGD XkK2FmioCL4D56c/l1PpLxuAbosIvC1Opuwxq82Ptmb/ZcoqowwMKhMuOFy3T89iatMO CFWw== X-Gm-Message-State: ALoCoQmgHNfZ67AchoXX1MygIY5Q/I8In7wazBLIHrhJrH9RTKTUoEQkfmN+k28X82W73Q9G71hvU+xig3Cv+5Mnv3WtjfgsWLR5r/43JOcWQODArPxrarymSLQwVaI5ggc2NqL9fkBEqNJBVidtMJ+UCQPWBAwc9v0+Wr9jkYYAfkgwqq6PIDU5sDGXZJmvMrS37/5vJoQY X-Received: by 10.50.152.9 with SMTP id uu9mr3428608igb.53.1376091496816; Fri, 09 Aug 2013 16:38:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.252.4 with HTTP; Fri, 9 Aug 2013 16:37:56 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D07DE77@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D07DE77@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Fri, 9 Aug 2013 16:37:56 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 23:44:28 -0000 On Mon, Aug 5, 2013 at 4:50 AM, Scharf, Michael (Michael) wrote: > Hi Will (and the others in this thread), > > Thanks a lot for this excellent feedback and the insights! This is very m= uch appreciated. > > @Authors: Actually, I wonder if the specific advantages of TFO for HTTPS = could be better described in the document, i.e., in Section 6.3? For instan= ce, by separate applicability sections for HTTP and HTTPS? If idempotency i= s not an issue for HTTPS, it would be worthwile to explicitly stress that. It's already in -04 http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-04#section-6.3 > > Just as a thought... > > Michael > > >> -----Original Message----- >> From: willchan@google.com [mailto:willchan@google.com] On >> Behalf Of William Chan (???) >> Sent: Friday, August 02, 2013 3:52 PM >> To: Scharf, Michael (Michael) >> Cc: ietf-http-wg@w3.org; tcpm@ietf.org >> Subject: Re: Feedback on TCP Fast Open? >> >> Thanks for the invitation for feedback. >> >> I've been the primary contact on the Chromium / Google Chrome >> network stack team for Yuchung and the other TCP Fast Open >> authors at Google, so while I only lurk in tcpm, I've been >> reasonably involved in this particular feature. I've thought >> a lot about how we would use this in Chromium if available. >> For some detailed thoughts intended for a browser implementor >> audience, you can read those details at my blog >> (https://insouciant.org/tech/some-quick-thoughts-on-tcp-fast-o >> pen-and-chromium/). >> >> The short of it is, for vanilla HTTP, it's unclear how >> beneficial it would be for us since we already have such >> gains for browser preconnect (our browser feature that learns >> from past web browsing to speculatively establish >> connections, typically just TCP connections but perhaps doing >> a TLS or other handshakes too as needed). There's a >> fundamental tension between our preconnect feature and TCP >> Fast Open for vanilla HTTP. Further experimentation is >> necessary and we've been working on this. I'm hopeful we can >> find a way to leverage this for our gain, but it requires >> more investigation. >> >> For TLS over TCP, there is a much more obvious win since we >> can squeeze the TLS CLIENT_HELLO into the TCP SYN, and there >> is no concern about violating idempotency. This combines with >> our preconnect feature very nicely, so I am rather excited >> about the potential for this use case. While HTTPS adoption >> is still low, I'm hopeful that it will increase over time >> (especially given the context of recent revelations). So I >> think the importance of the HTTPS use case will grow, and >> thus the potential importance of TCP Fast Open in decreasing >> user perceived latency. >> >> Cheers, >> Will >> >> >> On Fri, Aug 2, 2013 at 3:10 AM, Scharf, Michael (Michael) >> wrote: >> >> >> Hi all, >> >> As mentioned today on the mic, the TCPM working group >> has a working group item that allows data to be carried in >> the SYN and SYN-ACK packets and that is consumed by the >> receiving end during the initial connection handshake, which >> is saves TCP handshakes. The document was discussed aleady >> extensively in TCPM and will be updated. TCPM's understanding >> is that it is not far away from WGLC. >> >> The link is: >> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-04 >> >> In the spirit of today's session, feedback from the >> httpbis community would be very appreciated. Please note that >> this mechanism slightly changes the standard TCP semantics, >> as explained in the abstract: >> >> However TFO deviates from the standard TCP semantics >> in that the data in the >> SYN could be replayed to an application in some rare >> circumstances. >> Applications should not use TFO unless they can >> tolerate this issue, >> which is detailed in the Applicability section. >> >> Further information can be found in Section 6 of the document. >> >> Comments or reviews would be highly welcome. The >> discussion should take place on the TCPM mailing list. >> >> Thanks! >> >> Michael (TCPM co-chair) >> >> >> >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From apopov@palermo.edu Fri Aug 9 13:47:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E83E1F0D5B for ; Fri, 9 Aug 2013 13:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqk-NBKBtE5H for ; Fri, 9 Aug 2013 13:47:45 -0700 (PDT) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id F337D11E8125 for ; Fri, 9 Aug 2013 13:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1376080877; bh=bFf1zKPvRtx0+6sijzWUJ/TG8KIQI0D9beOmAdTg01g=; h=Date:From:To:Subject; b=jTVO0pfI+cO8T2VmX/RlaBftpX0XKfxuB8hKI4x6rvkZFNNUsTF+JE++inndUniG1 mr0FZq1EzQYcMe400JF39nnh9uuwhgafePOkJKlU5QKn4z3G7eiktx2c5/5EYokGZB IIIufbA7KmfmtLV+M+6415K/lf0u8y1q0uZZGgHo= Received: from maxwell.palermo.edu (localhost.localdomain [127.0.0.1]) by maxwell.palermo.edu (8.13.8/8.13.8) with ESMTP id r79KfDXi029286; Fri, 9 Aug 2013 17:41:17 -0300 Received: from [10.30.0.3] ( [10.30.0.3]) by maxwell.palermo.edu with ESMTP id B5N5YQ66.4399.0 Message-ID: <5205547D.90608@palermo.edu> Date: Fri, 09 Aug 2013 17:43:41 -0300 From: Alejandro Popovsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tcpm@ietf.org, Michael Welzl Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authorization-Id: who=apopov X-Host: 10.30.0.3 Subject: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 00:23:00 -0000 Hi, I have been observing that many connections become limited by the receiver window during fast recovery, even when this window is above RTT*maximumPathRate (and using windows scaling). This is because during fast recovery the congestion window is artificially inflated on each duplicate ack (after the third). And the number of unacked bytes may come up to double RTT*maximumPathRate. For this to be prevented, the receiver may grow its reception window up to double its size when generating duplicate acks. I observed this at the traffic of service providers that were having an important percentage of their traffic limited by flow control (most of the traffic is generally limited by the network, or by the data generation rate at the source). Best regards, Alejandro Popovsky. From john@jlc.net Sat Aug 10 18:41:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829221F95A6 for ; Sat, 10 Aug 2013 18:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvvbmJ82aWwx for ; Sat, 10 Aug 2013 18:41:39 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 711A911E80F5 for ; Sat, 10 Aug 2013 18:34:35 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DC64233C24; Sat, 10 Aug 2013 21:34:34 -0400 (EDT) Date: Sat, 10 Aug 2013 21:34:34 -0400 From: John Leslie To: Alejandro Popovsky Message-ID: <20130811013434.GL3328@verdi> References: <5205547D.90608@palermo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5205547D.90608@palermo.edu> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 01:41:44 -0000 Alejandro Popovsky wrote: > > I have been observing that many connections become limited > by the receiver window during fast recovery, even when this window > is above RTT*maximumPathRate (and using windows scaling). > > This is because during fast recovery the congestion window is > artificially inflated on each duplicate ack (after the third). And the > number of unacked bytes may come up to double RTT*maximumPathRate. Good catch! I never thought that through... > For this to be prevented, the receiver may grow its reception window > up to double its size when generating duplicate acks. Does this deserve mention in draft-ietf-tcpm-tcp-rfc4614bis (the TCP Roadmap)? -- John Leslie From michawe@ifi.uio.no Sun Aug 11 01:02:27 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F311E811B for ; Sun, 11 Aug 2013 01:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUzagRGtvTlP for ; Sun, 11 Aug 2013 01:02:21 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id C70C211E80D2 for ; Sun, 11 Aug 2013 00:57:02 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1V8QWI-0007La-W2; Sun, 11 Aug 2013 09:56:58 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1V8QWI-0005z3-IR; Sun, 11 Aug 2013 09:56:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <20130811013434.GL3328@verdi> Date: Sun, 11 Aug 2013 09:56:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CB8EFA6-C23A-44E2-9C91-B6381F820453@ifi.uio.no> References: <5205547D.90608@palermo.edu> <20130811013434.GL3328@verdi> To: John Leslie X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 6512 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D5D27784E98068D5061AAC442765894F3E63131C X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 21 max/h 4 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 08:02:27 -0000 On Aug 11, 2013, at 3:34 AM, John Leslie wrote: > Alejandro Popovsky wrote: >>=20 >> I have been observing that many connections become limited >> by the receiver window during fast recovery, even when this window >> is above RTT*maximumPathRate (and using windows scaling). >>=20 >> This is because during fast recovery the congestion window is >> artificially inflated on each duplicate ack (after the third). And = the >> number of unacked bytes may come up to double RTT*maximumPathRate. >=20 > Good catch! I never thought that through... >=20 >> For this to be prevented, the receiver may grow its reception window >> up to double its size when generating duplicate acks. >=20 > Does this deserve mention in draft-ietf-tcpm-tcp-rfc4614bis (the > TCP Roadmap)? I don't know how that would relate to the roadmap document - but if it's = correct (and a bug in the standard, rather than just an implementation), = it deserves fixing! I'm curious to hear what people think about this, cheers, Michael From nishida@sfc.wide.ad.jp Sun Aug 11 01:49:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3CC11E8106 for ; Sun, 11 Aug 2013 01:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.948 X-Spam-Level: X-Spam-Status: No, score=-101.948 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9EjpehhqJ7p for ; Sun, 11 Aug 2013 01:49:34 -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 3148821F9FC8 for ; Sun, 11 Aug 2013 01:44:15 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E16EE2780B1 for ; Sun, 11 Aug 2013 17:44:12 +0900 (JST) Received: by mail-la0-f50.google.com with SMTP id fn20so3956871lab.9 for ; Sun, 11 Aug 2013 01:44:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AJnc+Zbum3eVNGJNDCi3OrDADEGhl1uTu4dDQktMp7A=; b=iuYGAnoz7EPEt0qRjVCNvaw909MNDj80oWLLc0mj25pofKOsqsPHGO7F2OlokiWYWT 0zx8UP2IbNlFu+YV4A+Xblrk5a/ElNJg4OyCc0k5rQ4njmBa18UNsGbck9SqJJxGtwnl e35zq442TQ2fXm/UhMv6vJqwy2iMTdH6EwN+7LIIfzjRLdIrmHSosKTzHArYZgM93Vh3 E5XqMOT0wMKhp9NqeR4axlLwHKJse4JfYoFkhQu9/bYO/uC89JABCBSx12RdNO4tOVpZ +4h/ZBmWMufIAtyn56AFXapMVMLGbw+70h7dYa3wcpCQ2CDrRZJ/+puX73NvKIhJWqiu geJg== MIME-Version: 1.0 X-Received: by 10.112.74.20 with SMTP id p20mr7457621lbv.36.1376210650277; Sun, 11 Aug 2013 01:44:10 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Sun, 11 Aug 2013 01:44:10 -0700 (PDT) In-Reply-To: <5205547D.90608@palermo.edu> References: <5205547D.90608@palermo.edu> Date: Sun, 11 Aug 2013 01:44:10 -0700 Message-ID: From: Yoshifumi Nishida To: Alejandro Popovsky Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 08:49:35 -0000 Hi Alejandro, Is it possible to see tcpdump files for this? It might be better if we can discuss with real data. -- Yoshifumi On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: > Hi, > > I have been observing that many connections become limited > by the receiver window during fast recovery, even when this window > is above RTT*maximumPathRate (and using windows scaling). > > This is because during fast recovery the congestion window is > artificially inflated on each duplicate ack (after the third). And the > number of unacked bytes may come up to double RTT*maximumPathRate. > > For this to be prevented, the receiver may grow its reception window > up to double its size when generating duplicate acks. > > > I observed this at the traffic of service providers that were having an > important percentage of their traffic limited by flow control (most of the > traffic is generally limited by the network, or by the data generation rate > at the source). > > > Best regards, Alejandro Popovsky. > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From apopov@palermo.edu Sun Aug 11 10:27:49 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1273821F9BD0 for ; Sun, 11 Aug 2013 10:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJX-g5zAX2I0 for ; Sun, 11 Aug 2013 10:27:44 -0700 (PDT) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id C4F6521E8088 for ; Sun, 11 Aug 2013 10:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1376241595; bh=pFP6q11gu+AvjAQhcrSZrpa4bsdaB7nBTDsZVr62eBM=; h=Date:From:To:CC:References:In-Reply-To:Subject; b=gU6f04IFV9s3KWuYUwUpR/brfTYvcf/Uayx4i0TjnIqeU0wX65LvOeUqMRaLUh1kL 1dz+ZHTsMRBfzS2HE0jGC6EDtLv8mqPLaFohZ5NB8KpyTbkLnNKQmtsJepFEfKoI8h LAez46hGkI0uWO/EqB0R/MiaK2F/8x55B76M7sMY= Received: from maxwell.palermo.edu (localhost.localdomain [127.0.0.1]) by maxwell.palermo.edu (8.13.8/8.13.8) with ESMTP id r7BHJrCt013287; Sun, 11 Aug 2013 14:19:54 -0300 Received: from [192.168.2.159] (www.solbel.com.ar [200.49.156.98]) by maxwell.palermo.edu with ESMTP id B5N5YQ66.77675.0 Message-ID: <5207C7B6.7020700@palermo.edu> Date: Sun, 11 Aug 2013 14:19:50 -0300 From: apopov@palermo.edu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoshifumi Nishida References: <5205547D.90608@palermo.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authorization-Id: who=apopov X-Host: 200.49.156.98 www.solbel.com.ar Cc: "tcpm@ietf.org" , Michael Welzl Subject: [tcpm] SPAM Re: SPAM Re: flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 17:27:49 -0000 Hi Yoshifumi I have just left an example connection in: http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap I am leaving also an analysis of the connection showing the flow control limitation reached during fast recovery, here: http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf Let me know if you want some other examples. Best regards, Alejandro. On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: > Hi Alejandro, > Is it possible to see tcpdump files for this? It might be better if we > can discuss with real data. > -- > Yoshifumi > > On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >> Hi, >> >> I have been observing that many connections become limited >> by the receiver window during fast recovery, even when this window >> is above RTT*maximumPathRate (and using windows scaling). >> >> This is because during fast recovery the congestion window is >> artificially inflated on each duplicate ack (after the third). And the >> number of unacked bytes may come up to double RTT*maximumPathRate. >> >> For this to be prevented, the receiver may grow its reception window >> up to double its size when generating duplicate acks. >> >> >> I observed this at the traffic of service providers that were having an >> important percentage of their traffic limited by flow control (most of the >> traffic is generally limited by the network, or by the data generation rate >> at the source). >> >> >> Best regards, Alejandro Popovsky. >> From christoph.paasch@uclouvain.be Sun Aug 11 12:12:46 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4982C11E8115 for ; Sun, 11 Aug 2013 12:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW8F08-T5TIY for ; Sun, 11 Aug 2013 12:12:42 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 27CEA21F99E9 for ; Sun, 11 Aug 2013 12:05:18 -0700 (PDT) Received: from localhost (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 2510F183435; Sun, 11 Aug 2013 21:05:05 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 2510F183435 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1376247905; bh=qYLTkrcsijpk5sts6mqwu2Ogol5IBapJYWWYyTl+NxE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=MsaF8wHxQAD16O7aLT3zlNVDiDELetuLqHEdzAA00g4M1Xm0NYDanqr3vFFyyyMJM G6zyWkDcl82ZM6VCeFfClzTa1eSvzOtfcMer9ZMOvwZHPxpNKQIyOdPN29lDRNo2Ad 01povdhma4zLtvrmlRUHgy30vFVq6piOKZ7BzRPo= Date: Sun, 11 Aug 2013 21:05:04 +0200 From: Christoph Paasch To: apopov@palermo.edu Message-ID: <20130811190504.GA11031@cpaasch-mac> References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5207C7B6.7020700@palermo.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 2510F183435.AEAE3 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] SPAM Re: SPAM Re: flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 19:12:46 -0000 Hello, On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: > I have just left an example connection in: > http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap the trace looks rather like the receiver has its window capped at 64K. E.g., through a socket-option. Because from the beginning on, the announced window is at 64K and it never changes. If the client would not cap the window, the autotuning should do its job to adjust the window at 2*BDP, and thus allow full speed - even during recovery. Cheers, Christoph > > I am leaving also an analysis of the connection showing the flow > control limitation reached during fast recovery, here: > http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf > > Let me know if you want some other examples. > > Best regards, Alejandro. > > > On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: > >Hi Alejandro, > >Is it possible to see tcpdump files for this? It might be better if we > >can discuss with real data. > >-- > >Yoshifumi > > > >On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: > >>Hi, > >> > >>I have been observing that many connections become limited > >>by the receiver window during fast recovery, even when this window > >>is above RTT*maximumPathRate (and using windows scaling). > >> > >>This is because during fast recovery the congestion window is > >>artificially inflated on each duplicate ack (after the third). And the > >>number of unacked bytes may come up to double RTT*maximumPathRate. > >> > >>For this to be prevented, the receiver may grow its reception window > >>up to double its size when generating duplicate acks. > >> > >> > >>I observed this at the traffic of service providers that were having an > >>important percentage of their traffic limited by flow control (most of the > >>traffic is generally limited by the network, or by the data generation rate > >>at the source). > >> > >> > >>Best regards, Alejandro Popovsky. > >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From apopov@palermo.edu Sun Aug 11 23:18:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3B21F9C38 for ; Sun, 11 Aug 2013 23:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPQ-qd+bragy for ; Sun, 11 Aug 2013 23:17:58 -0700 (PDT) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4AC21F9F4F for ; Sun, 11 Aug 2013 23:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1376287628; bh=JGXOgEJ/2XVSwoYpY0iXHn4cUinOetnqtmOU9sGzzuM=; h=Date:From:To:References:In-Reply-To:Subject; b=OX1cq8MSf5QUYHI8U6HM4Z7gw+ti8Es1NGsrw2W7FSrsznhDcbU/9NJvQt0calAxc MksBZAnOgINjWiLs4B+/RRKZJbAwpqgX3aK6QI0tUoZmzBHxnOIedg1mBcGgPSGMiW TDYRAGmwIU4yQgwKFDLDXNk24kNAJqdrwNp4BDWU= Received: from maxwell.palermo.edu (localhost.localdomain [127.0.0.1]) by maxwell.palermo.edu (8.13.8/8.13.8) with ESMTP id r7C677XH028626 for ; Mon, 12 Aug 2013 03:07:07 -0300 Received: from [192.168.2.159] (www.solbel.com.ar [200.49.156.98]) by maxwell.palermo.edu with ESMTP id 9Q6WGFPW.17395.0 Message-ID: <52087B8B.1060204@palermo.edu> Date: Mon, 12 Aug 2013 03:07:07 -0300 From: Alejandro Popovsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "tcpm" References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> In-Reply-To: <20130811190504.GA11031@cpaasch-mac> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authorization-Id: who=apopov X-Scanup: 9Q6WGFPW.17395.0 spamPoints=500, authenticatedUser(apopov), rpath(apopov@palermo.edu), hasUri:100, Subject(re:__flow_control_and_fast_recovery)(matched: fast:400):400, AcceptedRcpt(tcpm@ietf.org), AcceptedRcpt(apopov@palermo.edu); HOST ip=200.49.156.98, type=SPAMMER, revLookup(FIXED)=www.solbel.com.ar, declaredDomain(65)=192.168.2.159, relayAllowed=false, hostSpamPoints=0, conns=910, blockedConns=300, mails=808, okMails=528, blockedMails=8, spamMails=0, virusMails=0, rcpts=1060, badRcpts=10, badUrls=1, mailRate=1.35081, spamRate=0, virusRate=0, rcptRate=1.35081, badRcptRate=0, badUrlRate=0, firstConnTime=2009-10-06 00:48:41 Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:18:02 -0000 Hi Christoph, I left another example where the receiver is tuning its receive window, but not as dynamically as to prevent a sender stall during fast recovery: http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery2.pdf http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap Best regards, Alejandro. On 11/08/13 04:05 PM, Christoph Paasch wrote: > Hello, > > On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: >> I have just left an example connection in: >> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap > the trace looks rather like the receiver has its window capped at 64K. E.g., > through a socket-option. Because from the beginning on, the announced window > is at 64K and it never changes. > > If the client would not cap the window, the autotuning should do its job to > adjust the window at 2*BDP, and thus allow full speed - even during > recovery. > > > Cheers, > Christoph > >> I am leaving also an analysis of the connection showing the flow >> control limitation reached during fast recovery, here: >> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf >> >> Let me know if you want some other examples. >> >> Best regards, Alejandro. >> >> >> On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: >>> Hi Alejandro, >>> Is it possible to see tcpdump files for this? It might be better if we >>> can discuss with real data. >>> -- >>> Yoshifumi >>> >>> On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >>>> Hi, >>>> >>>> I have been observing that many connections become limited >>>> by the receiver window during fast recovery, even when this window >>>> is above RTT*maximumPathRate (and using windows scaling). >>>> >>>> This is because during fast recovery the congestion window is >>>> artificially inflated on each duplicate ack (after the third). And the >>>> number of unacked bytes may come up to double RTT*maximumPathRate. >>>> >>>> For this to be prevented, the receiver may grow its reception window >>>> up to double its size when generating duplicate acks. >>>> >>>> >>>> I observed this at the traffic of service providers that were having an >>>> important percentage of their traffic limited by flow control (most of the >>>> traffic is generally limited by the network, or by the data generation rate >>>> at the source). >>>> >>>> >>>> Best regards, Alejandro Popovsky. >>>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Mon Aug 12 05:05:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB09B21E804E for ; Mon, 12 Aug 2013 05:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.259 X-Spam-Level: X-Spam-Status: No, score=-105.259 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-Mxc3G6LorE for ; Mon, 12 Aug 2013 05:04:56 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFBF21F842B for ; Mon, 12 Aug 2013 04:52:36 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r7CBqRdG018580; Mon, 12 Aug 2013 04:52:30 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0CA2419904C1; Mon, 12 Aug 2013 07:52:33 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: <1CB8EFA6-C23A-44E2-9C91-B6381F820453@ifi.uio.no> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Running On Empty MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma52352-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Aug 2013 07:52:33 -0400 Sender: mallman@icir.org Message-Id: <20130812115233.0CA2419904C1@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 12:05:02 -0000 ----------ma52352-1 Content-Type: text/plain Content-Disposition: inline > I don't know how that would relate to the roadmap document - Yeah - seems misplaced there. > but if it's correct (and a bug in the standard, rather than just an > implementation), it deserves fixing! It is correct. It has been that way for a very long time. It is not "a bug in the standard" that can be readily fixed, it is fundamental. I.e., the receiver has said "do not send more than X bytes" and yet the sender's congestion control would allow it to send more than X bytes if the advertised window space was there. But, it isn't, so what is the sender to do? Send bytes in the hopes that by the time they get there perhaps there will be room in the receive buffer to hold them? The fix is more buffering at the receiver. We can give guidance on that, but at the end of the day there is no bug here. This is how TCP is supposed to work. I.e., the receiver is supposed to be able to limit the sender via flow control. And, the sender is supposed to pick its sending rate based on the network conditions, but with a limit of no faster than the receiver has advertised it can take data. allman ----------ma52352-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlIIzIAACgkQWyrrWs4yIs7j7wCbBJAegpR/Sa5b6jmXpdW99PuU h5QAnRqd1JlNw/muNgT10nt/JEG6zBwD =OYWu -----END PGP SIGNATURE----- ----------ma52352-1-- From Alexander.Zimmermann@netapp.com Mon Aug 12 06:38:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DBF11E8117 for ; Mon, 12 Aug 2013 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.819 X-Spam-Level: X-Spam-Status: No, score=-8.819 tagged_above=-999 required=5 tests=[AWL=1.780, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP81Bc4abcMa for ; Mon, 12 Aug 2013 06:38:47 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A9C0911E816D for ; Mon, 12 Aug 2013 06:31:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,862,1367996400"; d="asc'?scan'208";a="80430232" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 12 Aug 2013 06:31:16 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.252]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 12 Aug 2013 06:31:15 -0700 From: "Zimmermann, Alexander" To: "" Thread-Topic: [tcpm] flow control and fast recovery Thread-Index: AQHOl1JuqM984WvG40Owq0svuFDc3pmSByGA Date: Mon, 12 Aug 2013 13:31:14 +0000 Message-ID: References: <20130812115233.0CA2419904C1@lawyers.icir.org> In-Reply-To: <20130812115233.0CA2419904C1@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_33B3378E-E919-4942-AA07-A0CD66D3C950"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , Michael Welzl Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 13:38:52 -0000 --Apple-Mail=_33B3378E-E919-4942-AA07-A0CD66D3C950 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Am 12.08.2013 um 13:52 schrieb Mark Allman : > >> I don't know how that would relate to the roadmap document - > > Yeah - seems misplaced there. > >> but if it's correct (and a bug in the standard, rather than just an >> implementation), it deserves fixing! > > It is correct. It has been that way for a very long time. It is not "a > bug in the standard" that can be readily fixed, it is fundamental. > I.e., the receiver has said "do not send more than X bytes" and yet the > sender's congestion control would allow it to send more than X bytes if > the advertised window space was there. But, it isn't, so what is the > sender to do? Send bytes in the hopes that by the time they get there > perhaps there will be room in the receive buffer to hold them? > > The fix is more buffering at the receiver. This is for example exactly what Linux do. It only announces the half of the socket buffer at the beginning of the connect to have enough room for growing during recovery. (But maybe this is not true anymore due to some patches from Google. Yuchung should know this :-) ) Alex > We can give guidance on > that, but at the end of the day there is no bug here. This is how TCP > is supposed to work. I.e., the receiver is supposed to be able to limit > the sender via flow control. And, the sender is supposed to pick its > sending rate based on the network conditions, but with a limit of no > faster than the receiver has advertised it can take data. > > allman > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_33B3378E-E919-4942-AA07-A0CD66D3C950 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 iEYEARECAAYFAlII46IACgkQdyiq39b9uS652gCfRFyvMIgNDKBkdwunBUUE4VIJ LioAnA83ht7xq4c27r7qHtqpQWAzPMxr =HdYS -----END PGP SIGNATURE----- --Apple-Mail=_33B3378E-E919-4942-AA07-A0CD66D3C950-- From perfgeek@mac.com Mon Aug 12 08:58:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAFC21E819C for ; Mon, 12 Aug 2013 08:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66ecDQy+z9yK for ; Mon, 12 Aug 2013 08:58:50 -0700 (PDT) Received: from st11p05mm-asmtp003.mac.com (st11p05mm-asmtpout003.mac.com [17.172.108.248]) by ietfa.amsl.com (Postfix) with ESMTP id BAE1721F9AB8 for ; Mon, 12 Aug 2013 08:08:34 -0700 (PDT) Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by st11p05mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-27.07(7.0.4.27.6) 64bit (built Jun 21 2013)) with ESMTPSA id <0MRF00CS1BDZXV20@st11p05mm-asmtp003.mac.com> for tcpm@ietf.org; Mon, 12 Aug 2013 15:08:26 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-08-12_03:2013-08-12, 2013-08-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308120111 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Rick Jones In-reply-to: Date: Mon, 12 Aug 2013 08:08:22 -0700 Content-transfer-encoding: quoted-printable Message-id: <495F251A-AE5A-4041-8D6B-34B61D649E5A@mac.com> References: <20130812115233.0CA2419904C1@lawyers.icir.org> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.1508) Cc: "" , Michael Welzl , "" Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 15:58:56 -0000 On Aug 12, 2013, at 6:31 AM, "Zimmermann, Alexander" = wrote: >=20 > This is for example exactly what Linux do. It only announces the > half of the socket buffer at the beginning of the connect to have = enough > room for growing during recovery. (But maybe this is not true anymore = due to > some patches from Google. Yuchung should know this :-) ) >=20 I think you will find that Linux can more than double the receive window = it will advertise over the life of a connection (and correspondingly = increase its SO_SNDBUF). Take a look at tcp_rmem and tcp_smem. I think = you will find that if you look at the SO_[RCV|SND]BUF at the beginning = of a connection on which setsockopt() has not been called, they will be = at the second of the three values in each sysctl. If you look again at = the end of a reasonably long-lived connection they will have grown to = the values in the third value. One way to see this with netperf: netperf -H -- -o lss_size,lss_size_end,rsr_size,rsr_size_end I suspect that will track rather closely with what one sees in a packet = trace. rick jones= From ycheng@google.com Mon Aug 12 10:02:10 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3416021F841B for ; Mon, 12 Aug 2013 10:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJul9Qxdaq+k for ; Mon, 12 Aug 2013 10:02:09 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E660F21F8CB4 for ; Mon, 12 Aug 2013 09:42:39 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so5244575oag.19 for ; Mon, 12 Aug 2013 09:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LN5QT7TU0hii4/1HjTlsguiBCpPZ9lSSO1FKuRAGXwI=; b=gn3756m3Ldw9kXvfjhpGAqyZONZdGIuVRUVHdZZkbkH/934eYXIjcUlw0GBWaUekVZ Vjqq4g34T1MmoFRXe9ypbzqFDNDKeIJ0O/UFdEovItneN6CbpRZyl0fzQXrJPSCX6o/A /ZwlF3SKmGq1Z8OU2ntg7SMf9PDWTziqK7TcA9ardyZwnA/0o+aHCusnqdHzLjMqmiz8 dfPNs2U1Wx9GT+QyQRVnq6ZN+DHnI/EeV+4sY8jDzFPy+2bnClDodRLyDXzj6Ca93FQI SuB54liBGYhFjN/t0+7EHj4iK9J10C+cfhkrKF2tNmzzmTPYj/Dzm6RlXnXAdcTAeKK3 MwoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LN5QT7TU0hii4/1HjTlsguiBCpPZ9lSSO1FKuRAGXwI=; b=PEL75dNd0CyUvAtl5GV2QZO1aNpEuw4LKvmk2kaEa/4iSBgbHkiBeOtU8UaOMJ9cVW bHXr8SnMUMTQVZvq7MZ5O4wFmLAHeHyma+lTKRYHe6tDgkafB1NKWqq2uquU/w6I4hkf InLMBgWNHK1CG/koZwtHPmSPO3HmeWw0NhZ3A0TeWQ/eEHWEiZXFzNjPFajica22GCiB jr1XfGsiy/h8qCPYjpmUXHb4ujW5hfKLweZD0WA5iJvK08cqzX4b42RdGWnOOj46GY6l jj5uwXRMLN4y3Iyax2Agf3sP3Ja22R6oGqGjmq5iGIoq/EseEpl0UeGUZ6AkavxZR/4A DHpg== X-Gm-Message-State: ALoCoQlRu6P2wz/vVfYSdAAVH8JJG8PDNQ6FZfquKtcf6FgayRztm/LmoqDYRb6PyKUiZ2E8WR+Tx7LXjMab2mEQUGfnkSMYl2jGSLcLRwMydPHisLGw9lOZbWLopKzgHXe0zkAtD2CY6exUMlLi0AgMX3WajGHmZOJmgNEF97wgt6LNUyHvG/oSuDq7br6Tkt2THhUiyZuz X-Received: by 10.60.63.68 with SMTP id e4mr11420158oes.23.1376325744515; Mon, 12 Aug 2013 09:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.81.163 with HTTP; Mon, 12 Aug 2013 09:42:04 -0700 (PDT) In-Reply-To: References: <20130812115233.0CA2419904C1@lawyers.icir.org> From: Yuchung Cheng Date: Mon, 12 Aug 2013 09:42:04 -0700 Message-ID: To: "Zimmermann, Alexander" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Michael Welzl , "" Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:02:10 -0000 On Mon, Aug 12, 2013 at 6:31 AM, Zimmermann, Alexander wrote: > > Am 12.08.2013 um 13:52 schrieb Mark Allman : > >> >>> I don't know how that would relate to the roadmap document - >> >> Yeah - seems misplaced there. >> >>> but if it's correct (and a bug in the standard, rather than just an >>> implementation), it deserves fixing! >> >> It is correct. It has been that way for a very long time. It is not "a >> bug in the standard" that can be readily fixed, it is fundamental. >> I.e., the receiver has said "do not send more than X bytes" and yet the >> sender's congestion control would allow it to send more than X bytes if >> the advertised window space was there. But, it isn't, so what is the >> sender to do? Send bytes in the hopes that by the time they get there >> perhaps there will be room in the receive buffer to hold them? >> >> The fix is more buffering at the receiver. > > This is for example exactly what Linux do. It only announces the > half of the socket buffer at the beginning of the connect to have enough > room for growing during recovery. (But maybe this is not true anymore due to > some patches from Google. Yuchung should know this :-) ) The Linux receiver buffer auto-tuning is buggy. The rule of thumb is to keep rwin 2 times (estimated) cwin for limited transmit during fast recovery but it does not. That bug was hidden for years until Linux sender uses Proportional Rate Reduction to recover losses quicker and the prior rate-halving algorithm is sorta broken. In addition to slowing down fast recovery, it also causes burst right after recovery when all lost packets are acked (which may lead to another loss). Not sure about other stacks tho. Mirja's preso in tcpm mentioned about this too (slide 6) http://www.ietf.org/proceedings/87/slides/slides-87-tcpm-10.pdf > > Alex > >> We can give guidance on >> that, but at the end of the day there is no bug here. This is how TCP >> is supposed to work. I.e., the receiver is supposed to be able to limit >> the sender via flow control. And, the sender is supposed to pick its >> sending rate based on the network conditions, but with a limit of no >> faster than the receiver has advertised it can take data. >> >> allman >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nishida@sfc.wide.ad.jp Mon Aug 12 22:40:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35AF11E8136 for ; Mon, 12 Aug 2013 22:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ7YdG5mTGTS for ; Mon, 12 Aug 2013 22:40:11 -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 24B3111E812E for ; Mon, 12 Aug 2013 22:40:06 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 101432780C9 for ; Tue, 13 Aug 2013 14:39:50 +0900 (JST) Received: by mail-lb0-f176.google.com with SMTP id w10so5465966lbi.35 for ; Mon, 12 Aug 2013 22:39:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zeUVXCjjZY7PWTXkoX9+Z+H4SG1gD6BPJ17iRERAxvY=; b=KfaUDYEjUSOJLJehcGtySKExRSyWD80566IzKa5o6OueZJft9QU/IDbJoPS233rAXk mhZXy2u1CvocW/YjXJf8eoOolsVasw4WqIulDHBHjfPqghEO8oxfD/m6y4F7WEEntH1v Qu++YItuORYcGKF6lrD6UHoeYwdSvQ4x4h53PbsinEaLU+kTSvZM98ZftXJbx1qMJGVZ RAmAmmSRnf7hvFgZ4JJrPoY3A02UxifC3HGIT1FKOozpABggyeFuEE9BHSvgjshydt+f aboPnzgKF3/f81/XaBVJbK/TvYLCuSKtsEWEo7WbmGOu7QkfEjH4vjY/nWk4E9Xaza+s 2AhA== MIME-Version: 1.0 X-Received: by 10.112.74.20 with SMTP id p20mr158884lbv.36.1376372388249; Mon, 12 Aug 2013 22:39:48 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Mon, 12 Aug 2013 22:39:48 -0700 (PDT) In-Reply-To: <52087B8B.1060204@palermo.edu> References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> Date: Mon, 12 Aug 2013 22:39:48 -0700 Message-ID: From: Yoshifumi Nishida To: Alejandro Popovsky Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 Aug 2013 05:40:13 -0000 Hi Alejandro, Thanks for the dump file. Please correct me if I miss something. During the first retransmit and fast recovery, the sender can transmit 2/sender's cwnd - MSS bytes of new data. (because 1MSS is consumed by retransmission) This means in the worst case, you will need to have 3/2 sender's cwnd receiver buffer to keep all data transmitted during this period. But, the worst case can only happen when the retransmit segment by fast retransmit arrives after all new data has arrived. (Another example will be a case where the receiver's application becomes slow to read data all of sudden during loss recovery.) You're right that if we want to prepare the worst case, the receiver will need 1.5 times larger size of buffer than the sender's buffer. But, I'm not sure this is a problem. Because I'm not very sure TCP needs to guarantee full performance when sender's buffer size equals receiver's buffer size. In your tcpdump, the first retransmit segment by fast retransmit seems to be lost, hence you got extra dup acks. But, I think this is not a situation that fast retransmit logic expects. Thanks, -- Yoshifumi On Sun, Aug 11, 2013 at 11:07 PM, Alejandro Popovsky wrote: > Hi Christoph, > > I left another example where the receiver is tuning its receive window, but > not > as dynamically as to prevent a sender stall during fast recovery: > > http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery2.pdf > > http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap > > Best regards, Alejandro. > > > > On 11/08/13 04:05 PM, Christoph Paasch wrote: >> >> Hello, >> >> On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: >>> >>> I have just left an example connection in: >>> >>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap >> >> the trace looks rather like the receiver has its window capped at 64K. >> E.g., >> through a socket-option. Because from the beginning on, the announced >> window >> is at 64K and it never changes. >> >> If the client would not cap the window, the autotuning should do its job >> to >> adjust the window at 2*BDP, and thus allow full speed - even during >> recovery. >> >> >> Cheers, >> Christoph >> >>> I am leaving also an analysis of the connection showing the flow >>> control limitation reached during fast recovery, here: >>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf >>> >>> Let me know if you want some other examples. >>> >>> Best regards, Alejandro. >>> >>> >>> >>> On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: >>>> >>>> Hi Alejandro, >>>> Is it possible to see tcpdump files for this? It might be better if we >>>> can discuss with real data. >>>> -- >>>> Yoshifumi >>>> >>>> On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have been observing that many connections become limited >>>>> by the receiver window during fast recovery, even when this window >>>>> is above RTT*maximumPathRate (and using windows scaling). >>>>> >>>>> This is because during fast recovery the congestion window is >>>>> artificially inflated on each duplicate ack (after the third). And the >>>>> number of unacked bytes may come up to double RTT*maximumPathRate. >>>>> >>>>> For this to be prevented, the receiver may grow its reception window >>>>> up to double its size when generating duplicate acks. >>>>> >>>>> >>>>> I observed this at the traffic of service providers that were having an >>>>> important percentage of their traffic limited by flow control (most of >>>>> the >>>>> traffic is generally limited by the network, or by the data generation >>>>> rate >>>>> at the source). >>>>> >>>>> >>>>> Best regards, Alejandro Popovsky. >>>>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Tue Aug 13 08:57:18 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDF811E817B for ; Tue, 13 Aug 2013 08:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnS3yWVaE58P for ; Tue, 13 Aug 2013 08:57:17 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 576FA11E8129 for ; Tue, 13 Aug 2013 08:57:17 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so9755117oag.13 for ; Tue, 13 Aug 2013 08:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=swQCzKXRQZfEVhr3P6iFALWMsa3gh8BBJlqP9Hgher4=; b=UZzT46lkOhAwsO+eaqIAuLy6AHipwLAXQzVghQYT7Ec8MhIjNXksEwB4w2jcciL8Ly L/p0MUXj58HHGCHLPfBPBzoUy7qXdW7Ajo5S601EYiTZjO6YTpV8J0FhXqLWoib3hWLJ ERT+X7untZ30zkU2c/nCRSh10WwGlbvukv0+Lt0il/Yj5rBNbAW4i9uLpIJ05D5agU2K MLQ9YhGQmz96+WuE2vTkx7jt/ztW4zyTbJuUiExsTDJu+hybM5FxTlkggBONGSXb3GmO bexnBNEs43IICYKJYVT+8Oqsq3wB3VZD4NFWKFKDIBA9CDZDCXFs6t6nXCNRgNLf+KdQ W6zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=swQCzKXRQZfEVhr3P6iFALWMsa3gh8BBJlqP9Hgher4=; b=QocwPoLfGiRR1K0ciLIpnAs/Zn4sFSIa+iO9KY1wH34QrEBJSlkqqXprLc/x5ohKkc y+yMpFhHfjiRgNmYzqMxia5M5ORi/BQF8fJAseTkZo5E0uuUCsTl5I4xFHqCj3qVh+0L G5wD0CXFJXuY8nGEYQO57IsNk70a2SY3kq8NbOYPVxPmgClNWJnc5S8sm4drrJO8vh5w 486xw9AnUuxjYG/4odpJlTzF2SgK2qPD0Stfgu2BKyS4ycrnkdcFKl+nmXUcw4pCD8XG pLqJ9nIECTnIMYJ3zsudCEsQ13wpilVNfh5nZ0uBmzV6CQ7UBBUicl1geitnCtcV/Auf POiA== X-Gm-Message-State: ALoCoQmU8tlV1DI5W3JLaNCLLGa/mM087+lZcepnlxOOd41Ga72V1BCUssLzsayBxyRHSM0b1U0Mady6pEptidb+njshU9wq4Zxxv/KE5tZIyBaSW9XnR3wKGvbpJkOIVQ64J1kQPpymomGBMgnl07sLeIUm5PmsLmitGDdOvtaC60E5XHGkh0hVXXZmBfpw+GNLrvKPF3H+ X-Received: by 10.60.173.235 with SMTP id bn11mr4927051oec.43.1376409435701; Tue, 13 Aug 2013 08:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.81.163 with HTTP; Tue, 13 Aug 2013 08:56:55 -0700 (PDT) In-Reply-To: References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> From: Yuchung Cheng Date: Tue, 13 Aug 2013 08:56:55 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 Aug 2013 15:57:18 -0000 On Mon, Aug 12, 2013 at 10:39 PM, Yoshifumi Nishida wrote: > Hi Alejandro, > > Thanks for the dump file. > Please correct me if I miss something. > > During the first retransmit and fast recovery, the sender can transmit > 2/sender's cwnd - MSS bytes of new data. (because 1MSS is consumed by > retransmission) > This means in the worst case, you will need to have 3/2 sender's cwnd > receiver buffer to keep all data transmitted during this period. > But, the worst case can only happen when the retransmit segment by > fast retransmit arrives after all new data has arrived. > (Another example will be a case where the receiver's application > becomes slow to read data all of sudden during loss recovery.) > > You're right that if we want to prepare the worst case, the receiver > will need 1.5 times larger size of buffer than the sender's buffer. > But, I'm not sure this is a problem. Because I'm not very sure TCP > needs to guarantee full performance when sender's buffer size equals > receiver's buffer size. It's not about sender's buffer size. It'll be easier to explain with time sequence graph, but I doubt this list allows binary attachment so try this tcptrace -CSzxy && xplot.org b2a_tsg.xpl During the recovery, the rwin remains stale and the yellow line is horizontal. The fundamental problem is that the receiver (likely a Linux box) does not account for OOO packets received to adjust RWIN. But congestion control, or cwin, does account for SACKed packets and retransmits. When the receiver have too many OOO packets it unintentionally thwart the sender, creating a bubble in the data pipeline at 5s. Due to bufferbloat, by the time the loss happens, the network has buffered a ton. By the time the fast retransmit finally arrives to repair the losses, the rwin opens up the flood gate, hence the big jump of the yellow line. Interesting the sender is probably application-limited so it didn't send out a burst. So the receiver is unintentionally throttling the sender to make forward progress during recovery. Not a good idea unless the receiver really can't afford the extra 100KB. > > In your tcpdump, the first retransmit segment by fast retransmit seems > to be lost, hence you got extra dup acks. > But, I think this is not a situation that fast retransmit logic expects. > > Thanks, > -- > Yoshifumi > > > On Sun, Aug 11, 2013 at 11:07 PM, Alejandro Popovsky wrote: >> Hi Christoph, >> >> I left another example where the receiver is tuning its receive window, but >> not >> as dynamically as to prevent a sender stall during fast recovery: >> >> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery2.pdf >> >> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap >> >> Best regards, Alejandro. >> >> >> >> On 11/08/13 04:05 PM, Christoph Paasch wrote: >>> >>> Hello, >>> >>> On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: >>>> >>>> I have just left an example connection in: >>>> >>>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap >>> >>> the trace looks rather like the receiver has its window capped at 64K. >>> E.g., >>> through a socket-option. Because from the beginning on, the announced >>> window >>> is at 64K and it never changes. >>> >>> If the client would not cap the window, the autotuning should do its job >>> to >>> adjust the window at 2*BDP, and thus allow full speed - even during >>> recovery. >>> >>> >>> Cheers, >>> Christoph >>> >>>> I am leaving also an analysis of the connection showing the flow >>>> control limitation reached during fast recovery, here: >>>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf >>>> >>>> Let me know if you want some other examples. >>>> >>>> Best regards, Alejandro. >>>> >>>> >>>> >>>> On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: >>>>> >>>>> Hi Alejandro, >>>>> Is it possible to see tcpdump files for this? It might be better if we >>>>> can discuss with real data. >>>>> -- >>>>> Yoshifumi >>>>> >>>>> On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have been observing that many connections become limited >>>>>> by the receiver window during fast recovery, even when this window >>>>>> is above RTT*maximumPathRate (and using windows scaling). >>>>>> >>>>>> This is because during fast recovery the congestion window is >>>>>> artificially inflated on each duplicate ack (after the third). And the >>>>>> number of unacked bytes may come up to double RTT*maximumPathRate. >>>>>> >>>>>> For this to be prevented, the receiver may grow its reception window >>>>>> up to double its size when generating duplicate acks. >>>>>> >>>>>> >>>>>> I observed this at the traffic of service providers that were having an >>>>>> important percentage of their traffic limited by flow control (most of >>>>>> the >>>>>> traffic is generally limited by the network, or by the data generation >>>>>> rate >>>>>> at the source). >>>>>> >>>>>> >>>>>> Best regards, Alejandro Popovsky. >>>>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From shep@xplot.org Mon Aug 12 11:23:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33921F9E22 for ; Mon, 12 Aug 2013 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1ygxZBkPTvu for ; Mon, 12 Aug 2013 11:23:09 -0700 (PDT) Received: from www.xplot.org (www.xplot.org [66.92.66.146]) by ietfa.amsl.com (Postfix) with ESMTP id EE98221F9DE2 for ; Mon, 12 Aug 2013 11:23:03 -0700 (PDT) Received: from shep (helo=alva.home) by www.xplot.org with local-esmtp (Exim 3.36 #1 (Debian)) id 1V8wOW-0008I2-00; Mon, 12 Aug 2013 13:59:04 -0400 From: Tim Shepard To: Alejandro Popovsky In-reply-to: Your message of Mon, 12 Aug 2013 03:07:07 -0300. <52087B8B.1060204@palermo.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <31833.1376330264.0@alva.home> Date: Mon, 12 Aug 2013 13:59:04 -0400 Message-Id: Sender: Tim Shepard X-Mailman-Approved-At: Tue, 13 Aug 2013 09:33:10 -0700 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 18:23:16 -0000 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31833.1376330264.1@alva.home> > http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap I took a look at that trace. Note that in this trace that there was apparently no delay at all in delivering the whole transfer of data to the receiver. This can be seen by plotting the acknowledgement numbers returned as a function of the time the acknowledgement numbers were recevied by the sender (which can serve as a fairly good proxy for the time the data was received by the receiver). If you look at the acknowledgement numbers vs time before and after the loss and recovery episode you can see that they are colinear, which indicates that the loss and recovery event never let the queue at the bottleneck go empty, so there was always useful data to be sent through the bottleneck, so it never went idle. And apparently the SACK blocks got enough information to the sender so that the recovery episode wasted no time sending duplicate data through the bottleneck. The end-to-end flow control window appears to be much larger than it needs to be to enable the sender to saturate the bottleneck link on the path. This example does show significant queue bloat at the bottleneck. It would be nice to see this same demo with codel or fq_codel managing the queue length at the bottleneck. A few pictures attached below. ( Also the .xplot.gz file for those of you with a working copy of my xplot program. ) -Tim Shepard shep@alum.mit.edu ------- =_aaaaaaaaaa0 Content-Type: image/png; name="z0.png" Content-ID: <31833.1376330264.2@alva.home> Content-Description: .png image Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABQAAAAMgAgMAAAAB9idoAAAACVBMVEUAAAAA/wD///9JuQheAAAg AElEQVR4nO2dT+vsLH/wc4SriKs+8FyF7iSLMvgqLm440OVd6Lmhu25a2ndhB24Ysuqmi2fnM6vg q2xMTKKZ/NHEJKN+PxzmN38yM87nGDX6VYsCAAAAAAAAAAAAAAAAyA4kcMHVLRLNLSO1fobUklP5 FM0hvOCsuVG3RfOS5AUmtbqPhDqG3/sD7gbjEjVG8APj5pZz3D/TCKPFq/lTUMT5kxbNLS8eiPKi eBRY3W/ewtXDrGmkvZRApUoJpP0zBSoEwrg7hDcvK2eNUaxuC9o8aO43x/B7038/WGWsRlKrSuW6 7hncnNS0E4iKVmChj6vUcUqgyqyIVrem/gugrUCKiVAnqyrr2mcIZohiVMuqbsyxVqBsBQqlrisP aXNM9lmQtwJ5mwU5biuLLk8WL4oLnQOLLgfyNqe2Atsc2DxP1TtyBrUuUGsGqSyon2n0VDUt9Ik9 FaiOUbeFyp83/4KbwUWpsp8yo9wok90zqkKhbRnYZLKmFm5zHW8KvfZWPVDHc1UYZg2pVaOuafU9 RXtbsO6Zpk1YUNo0Dpucp1p9nLVPyqY8bG6bw5rbqnmesrt/wTeAF24/juHF9BYAAAAAYuOzklt6 EpjlMfckCHRGXbh/AgKdmc2AINCZ9gLpExDoysLlIwh0ZL4EBIHOzJeAINARvJQBQaAbeCkDgkA3 FjMgCHRjuQcXBDqAC7ryGrAJZmL5teuSES+Yrrx2WSoiZiUDgsBt1kpAEOgAlmLt1auSES+Er70K AjdZH8UHgZvQ1VdB4BarJSAI3ATx9ddB4AbrVQgI3ALVGweAwFX4ZiAdCFxFxb+vAwJX4WLrCBC4 BtqeEgUC1yDbh4DANRbsINnOLVD/QOAyeDl7Icxf3T8QuAwu2FIjENMSdf9A4DK4EEsvURC4DSXL VXA9CNy8UskXupK3EOTAbehiNAcIdGKlHxBBLbwN4ysv1tAO3IQ6HgcCFxCOx4HABbjjcSBwAe54 HAichTkv7QMCZxHOR4LAObaG4gxA4BweF7ggcAaPDAgCP8GLk2rmjwYmrEVEzxx9VjLiBQuvo09K RcSsdiN8AAInrEdEzx0PWKyMhCwcD1isjITMAgIn+K5rBgInUM/jQeAE4Xk8CJwgPI8HgQZoO6b8 AxBogJCUvu8BgQbIIR5wCgg02BPoAgIN0I73gECDHWcwCDTZIwMEjsg9sX4gcITveRMIHPDrSO0B gQN017tAYM/CCpVbgMAe74u4DhCo2VcCgsCe5fXtNgCBHbs9gMCO3fNlQGDL3hIQBGrE7neCQMWB vTpBYOEXDzgFBBbIKx5wCggskFc84BQQuPciWAMCDzRhFCDwUAkIAgsQeJSNBRa3yF7gkTagInuB R1fdyF2gdzTWlNwF7uzIH8lc4OEMmLvAwxkwc4FHq+Aid4EBFr7KWuDxEjBzgcdLwLwFBigB8xZ4 rBdBk7NAEeJDMhZ4rCO1J2OBIsin5CswTAbMViDdHY41IVuBQargIl+Bh8aCTXIVGCoDZiuQhvqg XAWKUB+Up0DftU1WyFNgsBIwU4Gh2oCKLAUGzIB5ChQBPytHgYGugjsyFHgsoHJKjgKDflp+AlGI oaSR/ATuWZpjhewEht5FKjuBvgssbpGdQBH483ITGLQNqMhMYNg2oCIzgYGr4CI3gSds5JiZwPAf mZXAwBchLVkJ9C8BEaJ0eMDnjshKoHdHKlf7Zw6PyrlD8hGIdvTkS06NYnPWf04CfTMgQqwwcuB8 CZqRQO8MSKR8GmUgec0dlI9A4tsGfFX1m48PUT3rKh+B3r/0/Zacjw8X2pAgcAkk36X1MMzHxotn FUKIfJhyltqQuQhEvjP7SS2tSmPJfyYCue9FCELCCkBarMIzEfj0rYJVE4aPD5e7cTIRWPm+gUhr 8GR5JCUPgf79gERaZpZroEwE+h5flm/ridwF+lYhpKqsPMuWc3AOArn3VVwlKzPPrc2JyEGgdxVc vGvrwnetDZ6DQO8q+CUlNR+v/QdkINC/Cn5Lq9C0L0km5CDQ+w3M7MbaCGZIXiD1b8M8Zc2Nx+u9 EOkLZL5jmc1VnHXOrpcA6QsUnm9ASFbceLxaAmYg0DscC0n5NB+uv/+EYJEvg/q+gUirCtm6iEk+ BwrP45sy03SychHXkbpA32mZTRPGqnTo1hvSFsj9S8DqaQkUW29IXKDwfQeRldF5irYzcNoC/edV k9oci3NYnixtgcL7HXaz2wjNWiJpgf47zmNm9URnL9D3Dexh9b1utmGKpAVyb4G4ElYIFnV5j+d3 RASXvt0IjAkjotdtm4KEBVpdAk7Y3TBuK4SmK3DHZb58C+ORm5pkBfIdc0LkixuP3MK5QOAAxlah 57hlPQgcIA9ToOv6eKkKRN5V8CSgTVC3tyUr0P8dUpg9qZy6vQ0E9m8o5cOMKedLB05IVaD3tDhS mT3RDv1YmkQFOlahI4hIMwLEvQBNU6D/NgOokkY/jMf70xTofxHCrXgij/enKZD7vgFLM57IJwMn KdD/DCbMLAF9pKQo0L8bASEzGsEroDVBgch/qyQihfEer0lhILDhwaQhzW+VeBBYqH5AsxHtNysx RYHe3QjMmtgKAn2PL6UVk+9XBYFAdRVsloCe0QwgED2tiFTfpT0SFOhZBCJpXgV7XwWmJ9C3Dkay pMZDEOh5BmNiDQZ7r9CYnkDPrtRKmrWG90hKggL9agFUmiG9O7YrTU+g8Dr6Id/GOb9jzkJ6ArnP wciKyd+zYXNyAv0kPKwScM8StekJ9DpaWrUGCCw8JWBZm3UOCCz8KuHmKs7MgN5joYrkBAqPY4k0 ne1bJT45gdzj2FIKMT6iu74vNYE+lTBm5lXczmX2kxPocWxlTWzdudFIagI9KlLVEz0+2rvhcGoC PSphImsxPqI7vzA1gcL5SETkgw6Pdm+3mZpA7nwkqcyruPWVJVZITKB7JdxkQKMn32VW3DyJCZzd L2AWUpljmXT3NyYm0L0tUllXcWL3NyYm0LkSJswICHSPiP4kMYHORZkd0XvgGxMTyB2PaxrR4y8/ tPpQrgLNnuhDu0VmKpAYJeCxLevzFCjeoTJgngKRNJcnAoEjjrP8G4FGi9u98T1HWgLdqlO1xufw u4nvPhkTshRo9mP5xgNOSUqgY688NuYVHt4vNy2BTkeVpTGr5vCO4RkKNMM5jm/YnKFAZuy1cnzD 5qQEOumgrBp/9PE1eJMS6PRjzJjyAFvWZyeQmm0YsXhY0O+MBocfgyo5rgizJ6Byx3dGg8s8XyKN EfQQO4anJNDlt1RGPFGAEjAtgQ5XZU0jWgwPaIgvTUkg3T7kYcQT7Y2GsUlJoNg+RBpDITTIlyYk 0GGWTNOIHg4KkwFTEuhQBDKjES3CfGtCAun2Eew9HBSkCi6SEig2j6iM1U22j3YjIYF86wCzJzpU BkxIYMm3juDGVRxdPsyPdARu9y1LoxEtFo/yJB2Bm5Xwc1wm2nvL+mXSEbjVk4CN7c6Od0SPHxvu o+5ls2vqaQyFHB3LNEhH4NYBclwe5lg4kU0yAjfPSvkezuCAGTAdgRs/xFrdRFz3vfGwkavYYygB UbBGtCIZgWL9ZTkulH98MN0kFYEblfCDvfsqxHt5wXWSEbj+clMF90fs2KhljVQErlfCRj9W4AyY jMD138HGXdMDXoQ4fHE8rFfCxiq9x6NhbFIRSFdfHTtSdywvtk4WAvnQ+RJ+S/RUBIqV1x5sGIEL XAUX6QjkK6/JccO90FVIFgKbNky/WVL4MzgHgUYbJvwZnIrAtSu5sQ1DAjeiFYkIXB5RQiUb2jBn /NhEBIrFV0g1tGG8NlpxJQ2BK2cwG0fTT/mtiQhcfoXU/Wj6KRkwEYHLzTs0bnd2ir9EBC7/inHD wuBXwVtfHROLfTGvasiA4S9CWtIQKBaeR+9xoffD8zINalTQ7l8aAhcrYSKH3ZKsTUOOfh/C/NX9 S0Tg0gtEPvQPDFoCIkRL/S8NgUvFGyF1P5oetgpOTeDSjxiXCAwxK878wkHgCf07N7D0I4ZuhNBD cTSxHMgXnh/2ugicAQuelsBFPcMai4EFNtqSqoWf809jzPoqJPBVCJJptQOr2WfRU/RjSbu2aXAk BYHzSxiXUugN40KXgBYpCJzPXw/56MaSQlfBNgkIXMhgw1YNp2bAJATOP836qdUgcIPZCzlK+6GQ I2scO5CAwNnOwMdYBZ/77QkIpHNPsl7guSdwEgLF3JNS6HiYkP2ocyQgkH8+hZAUOh6GnvztaQok 1RDQJj5fDUr0Amcr2WetBR5dYnab6AXOlXFY1roEDDkrbp7oBYqZ5wgrdQk492pYYhc4N+8NPfur uKCz4uaJXaCYea4cgvLnXg1M5AJnL9Mew1DI3KuBiVvgrCF6UT9MR9wCZ6vgh3zy7u5J8UT2153/ FSciZp4rmW77kTN78geiFjiXw0hV6YjK89uAiqgFziV+COkNOzHdKw3RMJN4VMmadvf4XWmIh5nE 4yGmHARuM5P499khvQ5piIfPxJO+CkaXVMGzaYiIz8SzfoGsi07g1ATiqs94INCFj8QT1o+EnDuW uZaGmPhIfNVfBYv70hAT08SXpd5p4KIaeC4NUTFN/KMvAS8MXE5KYKU7Ai/MgEkJpLLqisBruhFm 0xAXduJRv+33Rd0Ic2mIDDvxL71O9MnhWKtpiAwr8c1VXBcReMLSHK5piA0r8VLW7WDcuRG962mI jYnAboREQg50xkz8Q4/FXXYRPJOG6DAS31TBXUfg2fGAK2mIDyPxTC8wdmkTZpKG+DASL/VWDVdn wFQEIt0TfXkGTEUg0W3Aa5swdhoiZEg86qdWi/vSECND4vtt00Puc+GbhhgZuv3ku+1GQHpM/Uqi Fsj1X8bqWxrRiiQESr3C2JUdqT0pCMS9v2Gt1AtJQeBbt2FuWcIlAYFNBmzVXRCSP0MCAkvWDmZe fxHSEr9ApMM5rr8IaYlfIJZ3ZsAEBOpYckbvSUMCAtuQVDTufHst0QsU3QJZl/cD9sQuEMmqPYPF XWmIXeBLVqoj646r4I7IBaK3rPHlY8EmkQsk3ayGk9aIdiFygawdTb9zIdO4BeJuNP3GDBi5QNYG k9+6km7cAmXbCLwzA8Yt8Cnr+uYMGLfAbmbmPf2APbELbG6HPaduIQKBhFRScllVlSBSSCIr1vyR 9Vs+23iOfte9e4haYDeczm9NXdwCmeoO5LemLgKBcpnXtXNC5vh+gZ+j5aiPhKn5HdEwNt8v8LOV R/W6CBjfnwG/X+BnBsRyWBfhtqGkka8X+JnF3uNmj3eNZRp8vUA6faIpAYcNuu6IJprw7QI/z9GH fNPh/pVJmefrBU6foHLcsPr2Krj4foEfXVX1WAL++I9r0zLLtwucpo+waqiCf//j2rTM8u0CJ61A RMYS8MevPy5OzBzfLpDbDx9yWGC2+D8gcJtJTwGp3u/hmX8Cgdtw+2E3jN7xzyBwm2lvvXER9xsI dEBYjxAyLuJ+gcAt8DQDPmo2XPv+BgI3wdOYNSnGzS1+gcBN8CQDNtcgYxUMArcZNqXpqNUYEtcP /gwCt6HmA8SYlEPny+8g0AFq3MdqZK5bFaFQF3Eg0AEx3iWVGsccnvgdBG5jLiGmJqTXo78fINAB oyPw1Zy+ZTejVfHjJwjchBoxa+LdnL7V2DX9Owjcho4TZ1BT/UpjF/Afv0DgNkYb8CVZbXargkAX RmPoLV8v45Ufv4HAbYyJR/3Cnj2/gUAHxhqjyYD2PMJfINCBUWApa/MELv4WBDowdvuhys6A/1+A QAfEcI9MMuA//DcI3Ma4iCPyab30eyuwvft/QeASfLhHJhss//jLvzYCZw68jy8UaGXAsQ9a8duv /waBm/DhHkJjH2rLb03hBwI3MEZCiJRW+v4MArcxIioRsdswP0CgA0Y/IK7sDPjzCwXeO1V0BiNB KpTNfOm//vqFAr8uB1oZsLZS9+/fmAO/TuBY6zZVsDWJ4cfPUeAPuBJZwAgbR9LOgL+pHPjP1tH8 iiRt8GUCjWYfmvRj/fz5VxC4hZEBKbOqYPQ3P39CDtwAmxnw8bancf0/ELgJNjIgrp6WQPz3hsC2 O+sPEDgFGxmQscoqAv/0n63AP1tv4FekaoNvEmiMZSJm18E//vSXUeCP3/WZzK9L2yLfIxCb4Viv Sm8UrPn9T//284+Pt/BTE+TGNwkU430jlk3xX//zj/8CAjfAho+S2Rtb/MOvP36BwHWwuas3mw4G mwJ//PxbfY8X9/M9AqnxgNljcT/+8usPu/7t4GcmyJFvFIie0u5l+/nrf0DgFkYbhkg7QP+3n78g B25Cx7uVfAjjlR8g0AU63GuqE2td97/+1RJIx9f46ana5jsEYjOcg00Gg//OzoHGUifWYTfxJQKN mHxs92OtLT7Gi/v5EoFGs48xe28pVlXW8ndsXP6OF/fzHQLtbgSrDViI5fUD+bWpnOU7BNLxrrBr kIJxELgFN4eSmN2Ivn95tg2+QqCRCCFrK57oto1WXPkKgcZgsLSjEe7baMWVLxCIjCDK52RSw72L bLvwDQKNu+/YMuCXCaTGpGDF92fAbxA4xhOhypxVWMwsX/l93C+QjM2WpolnBeVPlp34Sm4XaPgr quhKwC8QaPhDpV0Ff0VvyxZ3CzTmZSI06cf6iku1Le4WaFxpoElIdARVcHG3QPMqWI2mc/PFL1jj 2IGbBZodB0Taax6DwG2MzWgQIlY8G5oMbX4rtwo0F9dB1UTg1YnZyb0CzfuSWFnu/m0G3LhVoDEp pGnDELPQu2+/W0/uFMjMRnTThjHTEksGvFWgMO5PZtV8wT4Xjtwo0GooE6sf5uum8C1zo0Bq3i+t RiCiRSzcJ9Dsq0LMnhUCArexxitR9SyNh2RcLPDruUsgN3daQZOJhXFcxHXcJtCsJp6VFVP+DTv9 OHOXwCc3HrztNkw8VXBxm0BkGZN2FcyvTcsx7hJoPbDH4qK5CGm5RSCyNutq2oDmWFxcGfAbBD6E 1RP99eFENjcJNL+WCTMkNaoquLhJILF6m+XbjI6JqgoubhJofSm3BoM/djL8dm4RaF5p8LcVwBHT RUjLDQLNeMACy5cpMLYS8BaB1lnKWCnE8Ci6EvAOgZYkRKQxtBlfCXiHQEvS0w6HiS8D3iDQkvSu zbUR4hkJGblcoDUSgpnVdRpdFVzcIFCYD5jVDRNDQOoHVwu0zlLKrBIwxgx4sUBsl4APaU3MjLAK uV4gNx9KOwLLnqUZCRcLNDuuEGLmvDgWRUTvB9cKnAQjxH0V3HGlQGRHw5C6pMZjELgJskpAVFlX cSzKKuRGgdNVjiPNgJcKtKqJRy2tq2IQuA01H0grnCiWkPJP7hKIJ4PpFyYjLHcJLJlVAkY2lmlw k0BqL84RZTdCx00CH9LoyI+3BiluE2hfBZNYa5DiPoHW2gj46k61gFyZdDHetdd3ivgMvlLg2Izm VjQCmsxTj4vrBBpha29bIJ8eGhMXChzvSm71C/LpoTFxnUBjeRjJzbGQGAczR64TONQUlEpudGTF 3IYprhRI+zvSikiN3N+FAoX+2+Q/Mxohcn8XCuT6b21FpMaxtskKlwnsTWFpRXPQzyPj4jKBVP8t mRXPJq76/rO4SmDfYTXZ9Dv2EvA6gUL/rex+LH7R15/HNQJp31hG79pcaSLOYASLiwT2X2NXIXFf xHVcI7DU2Q4Raywz7ou4jmsE6gEkRCoznm2y60CcXCOQd39QZUUjiEu++2QuEdiXddhaGiH6i5CW KwQO09OJtV0cveCrz+cKgcNpS8w1PiMeCza5QGB/AttLLH79PheOXCCwP23tFQIjnNU1y/kCh6xG zBUCI5xWOM/5AvvT9sHMFQLjDceacLrA4SrYCghEca1tssLpAvuzltgC+dnfexVnCxx6TJmsjHoj havgjrMF9nUFspe0A4GucP13stFAxOFYE07+Jf31LkLmfoUk2pDyT84VOJSAr8o8g6NvRFPU/ztZ 4PDpb2tSQ7wh5RqB+av7d67A4XKDmpMa0GTjn/hAlJao+3euwD6n4YfZjxX9Cazioy4ROF4Fm1ve pnAVPAo89dcMZy0x2zAJZMCLciAeBLJa8OHpBDLgVQL7sbiSGascJzESQi+phTHv/pKqMnKdOO8L LwPJS9qB/fVuKV9jFZJEBjQ5Mwfqv1VtzKoR533fPZwnsB8AKdmbDk8mlwFPFNiHw1gTW8VpX3cX pwns+5xflRFRmV4GPE9gf+32lhUfnkyhDTjhLIF9R1ZzBhtbrUS5OtY6ZwnUn4ueVjgMCHSE9yGp RBrdCJEuL7bOOQKfuuZFxCwBy4Wjo+YkgfovqcydLkCgK0PcgbnKcfwd0bOcI7D/K+UYThT9QMg8 pwjs+0xLycbPF2d80/2cIrBvwxCZcDeMJrxAOqzEVpq7ztPgX/QdnCDQGIsbd49LJCL6kxMECn2H mOu8i5kjkyC8wOG0NduA6URjTQkucAydfBsd0elEY00JL3C4Z3SkpjCYvsBpAvHLmFWTTET0J6cJ ZGbfiwj9Ld/DWQKRGc6RyqykOc4SqLoReP9URDt+exNcoL4ONjdLSrgEDC+wGw1W67zT/ql05oTM EVigbq+gio17Lifaj6UJLFCfwLQer0JSrkGK4AJ1BmT1WAUnXQKGFqiLu1JWQxWc7lVwR1CB/VjI wxj+iHmJYxeCCuyri2pcZjv+5dk2CCpQ6L9yDGhLPQMGFahLQEqNeCwxe2RCBBXY3TIxCkx1KGkk oEBdhZBqXGY7+RIwqMAucgMTY5ntdDuiB8L9RJ0BGatp3whMuCN6IKDA7g97j23AtK+CO8IJ1I1o Ixwm8avgjkACUV/fcvkaPjLxq+COUAJ1bsPSaAPyMJ/93YQSqHPb29jyNvVuhI5AArUslQFF4I/+ cgL9Sv0xjI0Tg2Pf58KRoAKxOa2rhhzo/TElG0/g9K+CO4IKNPcrpGE++OsJJLBtPGNWD43oDLoR OsII7Bp/ZgmYRwFYhPmhtGsyU2NmNQWBHtCuwnjIYW38eHf89iaEwFKoW2QsT5TMErPbhBDYXcaV 45a36Swxu00Igby9fYxb3qYdTmQTQGCnC5NxeaI8uhE6Qghsb4gc47H6NYty4LhA1hZ4qBrCOTKq govjAnl3zYabNgzVT+UwEjJyVOCzuwghbOx8EQc/Mi6OCtQNludYAqa4ssQKBwX2A29yLAHFsU+M jaMC9Z+xBER04dBEOSiwi4nGxtR0Qo99YmwcE6jHPchjDCfKqQmjOCZQx5SjYdf0HKJhbA4JHGLK 3/36RCmscezHIYFdGwZjyfr+q+wy4CGBOgMSOcwMzqkbRnNEoG5Es2FWUk79gD0HBPadVizTq+CO AwJ104+PnS/iYGJiZL/AfmJmOTT9MiwBjwjUVTCRrF/wOMMS8IDALruhkkpK9TMh0hMduwX2Q3HP 4Souxypkv0AdfPWQ72G1RREgOfGxVyDt/rB6qIKzLAF3C+wjoY21JfjhtETJToGi+8PHmdW5BFRO 2SMQDTHlbIjJz7QE3CtQF3ysHgRmWgLuFKgvOTB79zHROQVz2OwS2HfDsCEgML+O1J49ArUtbAQE gsAd73mP8Wwy2yJwl8AuFB/Lcbs4Hig1EbJHIG1vyTipIdc2oGK3QGNaV7ZtQMUegULdkHFaV74F YLFLYNvmM+cVimCpiZAdAtu3sLEfJuszeIfAdiwEkXzjsWy8BaIuplwOGZBlXQTuEKh8oWc9ZEC6 fGwOeAtsRz7I2JFqrNKRJd4CRdHuV9iHROfchm7xFdiOwTUZUIfD5F0DK/wEdjODUTmsk59lMIKF p8A2A5bjhpkg0FMgL7pZXbx7TDKbFDKDn8DWl9EGzC8g9QMvgd0J+xraMHACewrsOu7fw2Bw3tcg HV4C++V1ePcQMmDhJ7ALBHywPgwLMmDhJ1CoGzqMxeU7FmziLhB1Z+5jaMO8lo/NCA+B3S2p9Gh6 frO6ZvEVSGQ/FgclYIuzQKLX2R5W1+HhExMjzgL1GpWkb0TDRVyLc0HWHdj4041oaANqXHOgLgFZ revePEPyZ3AU2EW04WEsLpsFKjdxFdjejqvDQBOmx00gGla46x7DRciAi0A67NQAGfADJ4Hd0Bsa VhWDKnjESaBo/6BKz8vMc1rmAi4CdZsZ14y2d6AJY+AikLe3ZdnvOFqelpoIcRf4kLLbbIq8V47N DgeBuspgkjm/JSNcBLa3vKqw81sywlngMBYHHakWDgLbwUza7zaF8lwaYZFtgd2qJg/5Fu3DzANS P9gU2J2xlOkqOPeA1A82BCIdjfDo/UFA4IQtgbonmvWRvHACT9gS2GVAxvTETBgJmbIhsKtBXlWf Afm5qYmQVYGoexm935ABl3ARiGU/lCROT090OAjERD5o91icn6DYWBVI2i7ocSwzt0W2XVgV2L1Y 9isiMLgK/sRB4DCWSc9OTIxsC+TD2hLi7MTEyKZA3O84iqANM8emwLJfYAy6sWZZFfhoXq/6fqx8 FydaZVUg7Tb95up+dvtcOLImsLkAbjKgLgHB3zwrAtVo3HACQwm4wJrAQg0lvXh7H/oBF1gRqGoN yIBbLAvkajqDzoDQEb3IqkDeL1MO8WyLLAusRPHmnUACGXCRZYG16oDW8+OuSk2ELAokvKl6n91u XeKq1ETIokBcPB7y2da+0IuwwrJAJPV2e9CRv8aSQFY3AnUjml6WmghZEiiKl6z09Bp6WWoiZEEg 47iPZ4NumFUWBDZtQC0QumHWmRWoZtZIHRIN/ajrzAsUalpXOxgMGXCDWYGMD9O6IANuMCuwLoiO x4IaZItZgRw9a92NcGliYmReIJF6WhcI3GJe4FOWeizu0sTEyKzASq+PRSQUgVvMCZT9Gp+Q/7aZ E8jfeoE2ELjNp8CnfDHdAwgzq7f5FCiboq/Neij3Vd6d+BQokF7cGPKfCx8CkTRwevcAAAPDSURB VMB6hUCogV34FIh14wUW13HiQyApyzYmGrph3PgUWFXtMDpkQDcmApmUen0nzG9ITYTYAqkoHnqh fBDoxkQgb/IgVffgKtiRD4FVu1cNlICu2ALZU28yBfnPFVugrIp2VghkQGdMgc35W3c5EDKgM5ZA +awL1RMNGdAdU+DzqSe2QgZ0xxQosY5GELckJU6sU5jI7qG4JSlxYgp86WBy6Ej1oBeI2v3iOoH8 ttREiCGQlFKF48PEai8GgUTWpO2HgZ58LwaBtR5Gh5ByP8xTuO3IglldfhgCWbvVBQj0oxdI+i5A uIzzA49/lUAKixx70vt6ca4EMuiJ9qQXWL+56gkUNyYlTgaBUl3BdRuHAB50AhFqruLeHDKgP71A 9uZNKSjuTUyMDDlQ8KLg9Na0RIkW2E6Mgzb0DrTAtg8QlpbYQbfGIsJKIL83KXHSCSRqqXc4g/fQ CcQqrBwE7qEVKGvWVMIwqWEPXQ4sWA2zkvbRCaTsDfr20QlkEvaK24kWWIPAnXQCpYCxuJ20Mxoa gdARvROsehK4hDpkL0ogeen5wYA/rcCHfPK7ExIruJ3YLyEeZi9YbflTwxm8GyWQ1XAG76YTCP0I u2kEvmQNrcDdqJAOEHiAViD0ZO1HCRTi7lREDOa83zoY8IcW+M3hMmQ/L7XrmYTx4L0g1AjkcBm3 m0YgkbzbcADYAVJhbYArn429JgcGi+eggT4nVJs+2C5QfO1LQOA2fO3FFwjchK+9SEN9CwAAl8PU Ou+qGY2PzdAkT6k2gBAFORZjjdQWRLhJFDo4zF83aUFqM8v6WAk/CGLzgjjHKiaQFw98qOSmFKkZ OrS58zryOU0qmrQ0tQjGh7o3mrYFLUhTizR3jnzOKIi/5tcr57RJKlIvHxSIEaIFp7Q8VPVhrNJS NIk6LJDTsjmvGo58ziiIL2QMzlnBm/MXHxPYGGxOXtScMMcEKoOiyYWswMdyTmOwbnIh4ejgGn69 oGJeINLJ5QfLwIJ3yaXF85hAqv8/C3rwP6L7/0SqLDjyOYMgRMTs96hGqzrFD+ZApBqtTQmoLq2P fE6XljZRB88IlZY2UZQf+ZwtQTSQQNwLxMcEtteVuP04euRzmk/RAtsJqPsZBNF5QVyJ4w0HBVKV 86hioaxwpE0Mxm2qjnxOmxhVgxy90h8E8XlB8imalk7TxmnuHPkeJuqmKUh40/yiRz6nT0uTqEN9 vKhLi0rUMYEOgnSM/mHaU5ce/5w2LSG6E2gRpjshlCAAAAAAAAAAAAAAAABgD/8Lb+BnK7RLrA8A AAAASUVORK5CYII= ------- =_aaaaaaaaaa0 Content-Type: image/png; name="z1.png" Content-ID: <31833.1376330264.3@alva.home> Content-Description: .png image Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABQAAAAMgAgMAAAAB9idoAAAACVBMVEUAAAAA/wD///9JuQheAAAb SUlEQVR4nO2dTY7juJZGacIPYGuUUStga5TQKjKBaKDeG/UWGuiFEB4ZMevhmwk5MrzKFuX4sUMk xctLySL1HbhcmbZEXZ+kJIq/QgAAAAAAAAAAAACA3SF7JYx9l/3w3jWX90+ay9Xo66kfNjHCdMOb fRfDV1cjVHOxf5a93cY89wc8G6VaORhRP5Ua3o1RH58MwrQ4D/8TWhpz0mJ4N+Kn1EaIn0LZPw+7 GPvXXTNIO1uBVpUVqD8+EVL0UqnbJmb42jobjCr7LvTwl+HPwzbmufE/H2Uz1iBpVGVz3e0TNZzU +iZQilGgeN/uzW5nBdrMKvXbU6PfAHoUqFXT25PVXuvGTxrVSa3k5fp2Gcx1o8DrKLC36m7XQz1s s/ssaEaBZsyCRo03i1ueFGetxHsOFLccaMacOgocc+DwubZ77Bk5upCjGWmz4Psng563ixbvJ/Z3 gXYb+y5s/nzyL3gySrQ2+1kz1o01efvE3lD0eA0cMtlwFx5znRkueuO7/Yvd3tiL4a5pLrZQN5T6 Tv34LrrbJ0OZUGg9FA6HnGdLfaYbP7wO18PhfdhseH8bPtfds3/BFlCe98k2Rnx/BwAAAHIgcybW avo+0ztfWWQV2Bj6PhD4hUqpo4DAL8aaXCoQ+EV3TtgJAr9IaiiAwC8gkIc6m5S98gXwFDIKHGuB yEDgZ0pJ9xAI/ERfknaDwA+aP0m7QeBHQp0Jft9dr1fX5xD4wUUHv/Z9C4G3ZFrZhrfQns8h8JaM 8/S8R3s+h8BbMnMCr73nCwgcUXNlGOPdM08ATyNXDpwrwxjfFxA4osJPIdJfzwCBI034FA4cBQJH IJAJBDKBQCZzN5HAnnkCeBq5ijF96lEgUNj8F8yBjbse5n3fHAE8kSwCZxqEg44gUMw2CIccybR6 7O2QReBMeyZy4BwQyGG4f8w0CENgkJkytIDAGeYEdtfgBhD41oe/1+GvIbCbUaDDX0PgzB3EDigN sXuBambY2Jyg3QuUFxP8HgJnCN+E2/AtWEDgnMDZ/XcvMFyVCoHzCfShbyFwFuRAJrgGMoFADmcz cw2cn5xh3wLtTD5BA3o2iX0LDD4H217R/WwSexaow9OnzF//LHsW2JhgDoTAOd5M8GsInKPTwa/D 336wY4FzozN1XCrpAWwChsC50Zk6KpUdCww+BXcxRZgxlfQANkGyQCmDOVDHprNbgeISyoHxg6/3 KlCdg5UIsyO/vhJKDGArpAqUf4J7muiE9irwHKxHJczfsVOBM63BhpBSWgCbIVFguDV4ZvD6A/sU KNs+9G3oy+/sU+BQhsmV5j4FtsGalvgyjNipQBmeaTH45Xd2KVBcdeBL2jyWuxQYniGBNvIDAicY Ulq7FPgWmCEhMLrfyS4Fhh5DqAnuUGCrQ3X51IUi9idwpgyjicntT+BMGaYnprY/gW2wmEIevbo/ gc0p9K2hJrc7gSrjU8iYHnWHjUEWGB7eT9exO4HB4f0JA/j3JlCFnuLmp2F0JEjfZVNQBcrQqpIp jzV7E9iFTtKEDLg3gTrYXhT67jGZxuhxTUu9N4HNHx340sQm02t9Vsa+diZQBTulRt+CpdatvL12 JlD2OvCtiU5ntwKDHToIzem6Ob0L3NnUT8HKPh2fzl5zYLBXNKU/wk4FhvukUlLSO70LX4KXQMJB r/ssB4aqUrvIPuUT9iQwVJWqTWIAOxIoQ4u3QmDEpqG6AgiM2DQksE8NAAJvmNQAIPCGSQ1gRwKD 3VJNagA7Ehis7gt9F2RHAoNL0JvUAHYksOsDX5rUACDQck1am3lkPwID1fnK+01Esum7boEmviUy UJ2/Y4Gx4atzaIQ/vUsRPYKNEht+7i5FefbdALHhh7oUXWcnms0RwUaJDD/YpSjY4TJXBFslMvxg lyIIjNgscAaHu/zmimCrxIUfbI5jGtiFwGBzHARGbBW6zTL7ZuxCYHD5ZbNGBJslKnwZ7FhuVohg u8SFHzxLzRoRbJaY8NVbcIoJs3wEGyYm/JmVM83yEWyYmPBnVs40y0ewYSLCbwPdrporoy46OoIt ExF+Ywxn9wwRbJn58INdiiAwQmCoJgsCWQIlqyY1OoJNMx9+oFtqs04Em2Y+/EB1X5bfXrvA0D0k yxiZygWqUE2WWSOCjTMXvvzjfQ7uuEXouAg2zkz4gblSU4c1ECPYOnPh++dKNStFsHFmwvd3SuX0 5qBEsHVmwvdryva7qxYYKMNkG+ZbtUDj12TWiWDzhMPv/GUYs04EmycYvr9LEWmyd0YE2ycYvr9L EXtN2MgItk8gfNn6uxRRJ0pNi6AEQgIDNal6lQhKIE0geaLUtAhKIBC+d9WpLBXRMRGUQCD8znen kFl/c7UC/XPEdBD4hT98f1FP5/zNpU/95HfhnSYrYyE6HEEReMP3r/6dsRAdjKAMvOE33ktgyjyf KRGUgS986a0tyFaTOhNBIXjDv2jqHrkjKANf+N66/Ox3zUoFekenZ76F7E5gylzlaREUAlVgdn97 E2hWi6AQvDcR7fw4dxkmEEEhEHPgAr92XwIXePLflcB8jZnzERQCTaBeMYJC8ITvXnkqc0VWMIJS 8ITvVpX9KSQQQSn4cqCzNjVja/BsBKXgCb9x3m71ihGUAgQycYRvq6Kd18BF7iEVCrRXOuX6WYvc QyoU6G0MgUAHk/ClXKs5zhdBWUzDvyAHUpjmQH+Vaf7KVGcEZUERaNaJoCy+h++dI4Y/u0RkBIXx PXx3CVoslf0cERRGrMAF6vI9ERTG9/Dfevd2y3VCq0ygr/OkWS2CwvgevqcQuERdvieCwpjkQPdm er0ICuMhfHX25cB+pQjK4yF8bxlmwUvgPgQueAnchcBc80vMR1AeUQLNahGUx3347U/3yIblnkK+ R1Ag9+H7urQt+xPrF7jwWKL6BS7SnO6OoEAiBOr1IiiQu/A9k8Qs0xrsjKBE7sN3X+uWaUpyR1Ag DznQucXCl8CaBLqbk/R6EZTIrMBFH+O+RVAid+E7J5lYshphEkGJ3IXvnGRCrxlBidznQDP9euky jKhJoKvhfOkyjKhd4NJlGFGNwOH8dcjKOcXTA7rrtRT2VYvAwZ5j2ZDFflwv9FkZ+6pFoLs1bqmK LKnFSerWvmoR6O565fwwB/sQmGmudxdayneBlUz9dHY8xjWh9SCZfAmsJAd2rjvIgoVArSoT6LqH XBYVKOq6C7sKzGa5o8qrEnWVAx05cNnW4EkEpTKGr11z3a31w2oQ2JhpDlyteFGDQFd75grVCHcR lItXoF41gnIZw3c0CK9Qk3ofQbnY8JXjhrtCTepdBAVjw5d/9ORzCIzEhu/qVwmBkUAgk/Ea6OiY CoGR2PBP/fRzCIzEht8hB6Zjw39Sg/BdBAUDgUxs+K7a1GUmmPBFUDDjNdDxuVk1goJRw3OwKwc6 PloqgtWOtAjK0zXfrBfBakdaBIfA5rrYFCfOCFY70iI4BK78iyCQG8FCyQ5XdnVqbWWnalpxavVZ Dx+357Pu1Umf7cKXw38n+6F4O41bnIbvx32kUudhB1tAaZVpx62H5M4ncb5taYaElP1cnydVWd3K fS0KFzi92OllfpAXCGSyjEB5XYvvR158XMh3FhKYNzl/L4NJpyLvlkuxiMAm76Po9E7hx2Q9cgSL CMycKKWR3OQ99DwFCPSv0zplrS5FXywgMO8CyEJSGsnXfy5YQmDm9C7u2UycQOCUNj4/X/Pm/Si2 L7A5RW9q8h45ivwCM5dhPHNJODFZjxxHfoGZb8GKcFaarIeOY+sC5R/fOq3TTVesRv0iu8DM1Um+ aXkdrNeUeU92gTpvcr5peR1AoIP2YqK3Xa1b9APbFigpj2ZZjxxNboGZ6+OcC+x5IGyakdwCTc7E lHMuGA+Lje8Ps2mB8g/hxvCk9sXMpba8RbEzoRqhEoFZU6PdVyFwSnxNavOMipiRTQuMvyA8r4MF BDLJe+S8NVkqOjn/MgSLk1egyZqa7GPTe2IXqe0KPBv3MssuIHCKopRhIHCKjK+HydyOSiLr1AI5 n0Nk28dvm+2oCeTMgVl/yGXrNanvbFVgG90UsuaoGgcbFUiqSSVsmp+NCiTVpJqMxyWTU2DGRglS TarJd1w6OQXqfEk5Z9X28NyRGtsUSOkSCIEOSPPmQOCU+Lp8+bSa1HcyCsw33ZKJL9k9tRBtySkw W0pd/CUQAl3EP1P/66lPIZbCBf6d7ZipbFJg9Bn8AwJduKZEdVOXwGyXoyY2Bx7qEmiypNLq6Ifb IwQ6GOxpHbcpBDqgjGp4hUAHhAezygTmqZYjVOX/qExglpRcM/L6gEAHrhl5PRxqE5ilVokwrual NoEmRyKEcTUQ6IAwruYIgQ48k9m5qE5glpV84wUeqxOoM6Qh4/8VXiHQxSU6lcoENtcMY+RaLaMf Qw6VCcyRCuUhBAIdEB5CqhOYo58rpUvqUIquTGCORAhdUiHQkQSlHusXBE4hXAXqE8jvWane4jPg S30CNTsByh0EAqc0hLHph9oEZngKITwDC/G7NoE58nD8MzAEuiAUYQ4Q6EiB8BQMgQ4oT8EvEDiF UIY5QKCDhlKGqU5ghpoYQn+i3xUK5MfwZqI3hUAXnY7d8libwM6xoged+E75r7UJ1FligEAm0X3K IdBNbHXidgTqxmgp7IsnMM/wwujBwb83I7DX+qyMfTEFcgORNoXof4bNCJRaS6lb+3qywLElJHaK rONmBIpcAtlFGMJaIfYWvB2B3eldIO9BzHADIawVsi2BN3vsHGiYcSjK7DAQOOXUU7belMAMd+EM yyB38fVYYksC5TVHOdCw42hJDfLH7Qi855kCm8nKmCFqE8ifbJEyMFP8qkygzjGqgVKEgsAplDkW jxA4OTCpT3RtAht+EUb2hEvgoTaBGdqCaV2iIfA7zZnUJbo2gey24JZShDkeqhNomAcl3UAgcALp BmJn54DAB2g3EDu5BAQ+QLuBQOB3zpRBcbfZOSDw7oCkhUIEBH5H9pQ5osVtdg4I/ORMq8YX4hcE PtAp4hGrFJg+z9iZeP6KY5UC0x+FycMSIfBxR2oGfIHAB2iPIKJGgVdLcmUMYUDDyK/6BJrUA40n L/Huc4TAL8bbR+z8vO9UKFCatMPIlnr7sNQoMO0oid3oIPCTK6EN+IvX+gSm9UlVlFXOPjhWKdAk HUT+Sci5EPgBZaXlL368QqBFysRpeWoUKFM6dFzi16e551ClwIT0SQMZ7niBwBukgQx3VCkwoQxD 6oV6x7FKgSYh/cQzGAItshXx8/I+8gqBtgU4vRNXhQLpZRj5JzH72SENFQokJ90kZ8AjBFog8J6G WIYZHn9TnoBv1CiQ+sxM7cHxAASKLj37iRoFSmJLJm0c5oT6BFIfaGnjMCdAYOIT8DsHCOQtE1mf QOoUbcRe0A8cahRoiIlyRiJCoOAJfKlQIPGK1sYvMj/lUKNAYiF6KMOYlFBGShMY1WeFKJBVhvld mMAFcqAhTMo7BQJFx8mBRwjklWEgEAITt/kgrSvqBxAoJGtWSwiEQAeU/s1JfVG/eKlTICG5pL6o X0AgpynkAIG8uc1rFNiMQ+PiU2t/MnLg7woFUgeCdX1yIBBo4Qj8UaNAYplEMSpiDlUKNLTEZK+T A4FA5i3kBQIlqzW4SoGUZX8HSEsLfONQpUBNSip1TM3I4UXvXmDqmJr3vU38tmUI7IhLf9MWB/nO b2cO9GxchkBNTInVJ1X8z3+6roGzu1FL+vnJJ5C2OMh3/vl/0QIPZVwDyU9lvB5FU4H+jcsQqKkp 8QROT+GoHTd8CmtqQpzWuLFwsnOBrGUiKxRI9sGqzK9RIDWh9IFdEDjCEfi7QoHU9nFJnlvxi0ON Ag01oUv6b4FAIZLH9lsgUBjDWaOlPoHkZTM75MAHDDUV3hpf/4BACHyA3DjUXqh7PFCdQHJUvMGZ EMgcHgyBvAbh+gTSpyxmNScJ8V+1CaSmwehYPmqCQAi8oyOP7zfpTyGHCgVqagqsxiQI5An8XZ3A htadw8IQeKxPYEJAEBj4awzp7cEHCBxgTNFRocCOXq/cpOfAl/oEanoC6UNDDuUK1F2vpbAvCEyi 1+KsjH3xBSZXZR3LFSi1llK39sUXmFyVVbBAoduTUyC1R5F9CE7Oga8lC/zZvgt8rPuj1sOwJkgo WqBo3TmQmA5H4LFCgdSKLM7QmkPZArV23YUNNR3G0JqiBcprY1zlQENNiNEa91KyQF8EhrovozWu RoHkeimZPlnvoUaBhrovY70LCLRA4H0EkngG8xYMOfxFEVjEeGFqIZrTK18Q5wOBwO+8TnLgr9Dm RQgk1syrtz79oOMgfoLAQBjpQWTiMwJN208yhjVAoGAOjYNA5jx39QmUxAkm0lb9/uB3hQKJe/F6 5UMgT+CxPoHkZQs5Vfk/KhRI7lXem/QjQiCvDCP+GwJ5j3EVCiSu+8gT+KNCgYa6E0PgEQIFBD5G 0NALdYybyGt9AhNiYDwIQ+C4U3pdfn0CU65njNak+gSmhJAu8BUCLenV+RA40iXHXZ/ApLMxeWTD oT6BxAjkWHOYPLbmP/7eu8Bbg3h6DvxfosCDYybz+z4LxQlUvP4IfoG+HWoTKP+wjuY/hRMpTmDC YLp7/DeRRMoT2LOOBoFMgS97F8hZdcq62r1AzqpTEChYNalHCBSsmlQItONqmDlQ/kUTeHxfU8mf alkCmbdgQV4pEQLveL3Pgb/i9qlMIKcMI3683l8Df6Un9EhRAjllGAgU7G7REMhaMQQCeQJfILDV jFL0AQJFY5Ia8G5AIHOy7d8QyJvuHQLFOX14vzhAIHfhx3oFRk/7zhH4UrHAyAhaxkSf78vu7Vtg Y4xJPgQEMssw/9i9QMWZomgQ+NfeBcqelwP/nSTQLhH+a272mDIE8mY4Od4LJOwHge8c709hTkIu yhB45gzO/HG8v4kwEnJShkDW+HQI5C65AoEQyI0AApkRpK/XAIEjjIoECLRwcuALBDLrAiGQIfAA gZY2+Rr4AoGWJrkyFQJHkuuyDhA4ktyvEgJvJAv8DYFjCTC5Ph8Cb88gWiemDYGsZxAIHL7kPAVD oO34YRhJHyGQ05r0CwIhkBuB7BhD4yBQkIe23QOB4rZ0ZiqvEGgMJwdC4PAUwsiBRwjkNWZCIAQy I5AtqzX4+DdHYPyhNyyQs2ADb8EbSkN0rQLldSVYPRez4BPIWHvZrk+ihrNQncYl2FXTilOrz9qm ej7rXp30WbbK/neyH4q307jFafh+3EcqdR52sKdyq0w7bj0kdz6J821LMySk7OfDn56NTyBj7WWb KASyupVDIHNw5vMv7evh+a3qqpOTlBu4tK+HRyCnJpC6RFjZQCCT/AKpa6wVTn6Be7qDCPfPZa3+ DYHcoV0QyBPInGm6OFwCOat/U9cpLh6XwPTlQgQEWjhVqbSFnktFC6OlsC+XQM4MHfRF/oqkF+as xpdLYMPJgYxdy0FqeZK6tS+XQMZcs5K3dngxaLWUwPSYiuJL4GTqJ9ly6lL38histT8HssrBhrNz Qejuj08gp0PRXq6AYzHGcxc2BhWB88irtxzYcXIgr0t6oXwTyDkJeb0RSiWnQFYgpfIgkNejaC9l mEceBGqUYcg8CGw46xaymuLL5UEga8WVnVXlfwCBTB5+NqtH0c7aQj64E8icKpWzb8HcCWROlWqY kRTKnUBec3BnmJEUSjaBmhlIqXwJVKypUiGQWxegeXEUy30OTE+lue6jPdjBp0Dd9hlS2R+fP73h XAIhkPcYF72sS4XkEZghkFL5ECg5TyEQyBxcCIFMgbtsjnvnJnA4fzn3AZ0llDK5CWyM5JyGOkso ZfKZA5PZ8VOI5SMHclPYLePP5yycCYGCuWQNBEIgB2XrsVjlOAiUPWPhTAjk1aTuuybGoriNSXt+ DrZAIBMlzqc+ee/uet1nr8AvlOhU+m1A5wukVBRrbKbOFUa5KMM5B3WuMMpFdYwcuM9++Y8o9Mvn AYFMFAY28GA9yZpMQZQMBDKBQCbpAoenOJMvjmJJF2jyBVEyEMgkWSDO3xvJAk3GIEoGApmkCWxw B/4gTaDSeaMol8Q2NQj8BDmQSZrAnbcF35Mm0OQNomQgkAkEMoFAJhDIBAKZQCATCGQCgUySBO50 njEnSQJ33i36AQhkQnWxkSVBtwNVoFkiiJKBQCYQyIQoUJpFoigYqsBloigYCGRCFIg+qd8hCjSL BFEyEMgEAplQBEr0iJlCErhYFAUDgUwoAlGGcUARaJYKomQgkEm0QNyC3cQLXDKKgoFAJhDIJFZg gzKMm1iBaMn0AIFM4sRINAX7iBS4cBQFA4FMIJBJlMDdT9EWIEoga4rQyoFAJjECGwj0EyMQhegA EMgEAplAIBMIZAKBTCCQCQSmoLteS2FfEJhEL/RZGfuKkbP39RqmSC1OUrf2FSVw+YhKQ0sJgRx0 85EDY05PCJygRRuXA5txbOFKURVEtEDcf91oHXkXhkAn8tqYuHIgCjCzhAWadYIoGQhkAoFMggI7 s1IUBRMUqFcKomQgkIlfYLfvpb9j8QvU6wVRMhDIxCuw61eMomC8AvWKQZQMBDKBQCY+gVg2MxKv wFWjKBgIZOITiIaQSHwCzZpBlAwEMoFAJk6BWDYzHqdAs3IQJQOBTFwCMdM7AZdA9EcgAIFMHLLQ I5WCS+D6URQMBDKBQCYTgR16pJKYCNRPCKJkIJDJN4ENunMQUcG/glkgkAkEMnk01uEpjsqDQLSm 03kU+KwoCgYCmUAgk3uBeApO4F6geVYQJQOBTO4EojE9hTuB5mlBlAwEMoFAJp8CJS6BSXwJfGYU BQOBTD4Fds+MomA+BeonBlEwX/1g9BOjKJlbDpQYXJ3Ku8AnR1EwEMgEApmMArHmWTq3GQJBDDFt vibXP4zOlVC2pv51LlMmV0I6V0IQyKQwgQCAQuma4S5trkZ03C5GNoHmooRhXr5kP0SjhrDGP7BT upohIF46QWzy0gxHMGfmD7cJqHGiZV46yv7en0NSivvDxwTMOPMzL6QQxmiljBz+n0egnWXZsNJR aojmLIawFPMOOiZglGL/tCDGdMNBhtOPe+rZBFTPF2h/dz/8S3Q2B3FTEuJtYYHyPVgjuWU4m0Cj MgjUt39RZf/ATkn052UF2tPOXikE+0o7JpBD4C2a97DYKYmFBeqPSDW3yD4mkEGgvW6NAiX3CemW wMICh2vskHUsOS6BSmW4C9twlLrFxU/JnJa9C19P/VAUHMpw1zdmV/0hgW68oDL/JW7R3MLKkJK9 oC7cfWX8wVkOke1MMdkSM1lSAQAAAAAAAAAAAABr8v9c2R+1JdiOkwAAAABJRU5ErkJggg== ------- =_aaaaaaaaaa0 Content-Type: image/png; name="z2.png" Content-ID: <31833.1376330264.4@alva.home> Content-Description: .png image Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABQAAAAMgAgMAAAAB9idoAAAACVBMVEUAAAAA/wD///9JuQheAAAT GElEQVR4nO2dQXLivtOGjYqFixWL3wFUrFKcgiN8R+pilZpTUP9VilN+kk0mZCKM8Gu3pM77FOUh uLGcZzqyLMl21xFCCCGEEEIIIYSQX4e79J3EpbuE5XH3cftk93EVfz1fQoh0cgyLuOzCqqt0/e4j vneXGCNlf4HS9P3BBSP9W9+HpUj/+UkQ5rv38E/nncjZd2Ep3Zvz0nVvXR/fh69I/PFXE6S9R4FR VRToPz/pXHdxfT+GSFgdnQWjfVx2PvwQ3ocYKbv/5eljYgVJg6qYdeMnffij9qNA1w0Cu1vcnxgX BcZkdf5P0b2vAD8I9P3uEv9YY103fLLrj8737uP65yOYOw4Cr4PAS1Q31oc+xPz6FJRBoAwpKP1w sBhzsnv3fXfLwG7MQBkydRA4ZGD43Mdv/Gbc4MINZlxMwdsnQc+fD9/d/rD/FRhj4rKL+Vn4NyhM 3x1i+kUz0U00OX4SDyh+qANDkoWj8JB1Eiq9YRl/iPESK8Nfze4jNupCq+98GZbdcfwktAk770Pj MGRebPXJcfjwGurDsAxhYfknfO6PpX+DGugfLH/ESPfvkhBCSI340jsAEM6lS/D9yOeL7MMyFGra GBHoUo0gFYwI3Empko0IPPhSJRsRWEUGXq/XS6ndAIkdOoW4EyjFdgLmo1zRJgS6Q7myTQhkBqJ4 hTJ212vqYxsCNTLwQUPdhECVOtCyQGYgilcow7RAZiAG60CUGjJw1/Ccuzg7aV3c9frgP6n/8aY9 hpH4lYt4uMaCwP599SJsC2QGzscPS1m9HLMCtbphrApU6wi0KrBUBvrd+TrMDPWNC1y/AdgNHYH/ dgVe/KHr5T282haocPjtUmacj8l3cOHVtkCFBmCXNBMEvlkQWCoDO388n0eBbqyFH5/q1Uyv0/+R zEDvvmVguXFpBKX5WHYFKs0ITAo8uG9H4TYFFstAd93Jx7d2YJMCvc5x78nRoWGBSoc9mV7drkCt 82CZXt2uQGYghtOaDSrTq5sVqDYn9Uk5zQpUmxUt06ubFVhVBh6TM9+qRmtWtHs2XD4I9OvvyNKU Hwy50ajACgZDbjQqkBkIojIYEjEqUKcreijpWUCbAnUGQyJGBTIDMVQGQ64jz/ela0+gSle05IU1 KVBlMCSzjCYFVpaBrrHLhHudSQCSF9a31xWjNBgneWENClQaDs4spUGBzECQ9WvATWwESl5sgwLX z8DNCw31BgWuXwcaF8gMBHlbu4C9cYGrd0YbF7j+cIhxgdVl4K6tQWG/dtfH5lWBjU3PXz3/jAtc vwY0LpAZOJvbfvp1SznZFajTCWNYoE43oGGBzEAM0djPjV2BOnMRDAvUmQ1jWGC9GdjGhcJO5dLg /RyB+aEl0ZmTb1igzlUhhgUyAzFUrgrZGBaocqAzLFDnqhDDAmvOwHJPMnkBlatCtjMzcL09Wgyd sxDDAnXOgw0LZAZi6Nwia29XoE5XtGGBOoMhhgUyA0EUdnFvWqBCBtoWqFAH2hbIDMRQuE3gybRA hZ4Y0wI1+gJNC2QGzkeGpV+/IKMC9W7NYVSg3s1hjApkBmJ4tScFbmwK1Jv0ZFOg4nPTbQpkBmKo 3SY6jiZZFKg44G9ToNptoq0KZAZCiMpV4NugqzMpUOkcxK5ApbNguwKZgRBe44HB8ZoaqwJ1TkHs ClQ6CbYrkBkI0SvdEndjVaDS7SntClS6QapdgcxADKXnZXYnqwK1uqGtClQbCLEqkBmIoTQQsjcr UKkb2q5ApYEQuwKZgRg6z8vc2BWo1Q1jVaBaR6BVgcxAEO81StnaFaiTgHYFKlWBdgUyA1G8RiEn wwJVMtCwQJ060LBAZiDKZf0iNpYFakzJMi1QY1KgaYHMQBRZvYS9aYEKGWhboEIdaFsgMxBF1t38 1rrAtTPQvMC160DzApmBGGvfKfVkXeDaU1PNC1x7crR5gczAOfTJtyuwMSpQa06+WYFaV4UsLdDv xLs4m8wzA2cJvHj/3kt8lRWo8rzMyHZZgc575/whvooK1Ls928ICu0oE6t0gcHGBx/NNoCv5YMiW M/BQQQbqPC9zwKZA1ZsTLS2whqOw6u2xlj0KX6toBzacgXeUE6hzVcjIfxYFah7/LQpUvEeqTYHM QAzFe6QGXQYFqj4U1aJAxUagTYHMQIxeqRG4H5YGBWp1RZsVqDUYYlYgMxBDazDkZFSgWle0VYFq gyFWBTIDEaRTuU90N9xo26BAvaE4owL1BoONCmQGQohW/dcNUyrNCVRMP5sCFStAmwKZgRBerwI8 3R42YEug4jicSYGaI8EmBTIDEXyndHOsyMagQNWZsAYFqs6EsSiQGQih9aCkG3tzAtUuSBqxJ1Dt krgRewKZgQi9co/FxppA5fSzJ1C5ArQnkBkI4FYv4Qd7UwJV56GO2BKoOhN6xJZAZiBCP9aBmmxM CdQ+/HbWBGo3ADtrApmBCK7E1MO9IYEFjr+2BBZoAdoSyAzE0LoW7o6oy47AAkdgWwILtAFtCWQG gmi3ATfWBOp3QxsTqD8QYkwgM3AG94XqD4S0L1B1Bv4/mBCoeg3IP5gQyAyEkO6FQhenfYEl06+z ILBkBdhZEMgMhOiLVoDdaK5lgQX6Xr7RvMACvX/faF4gMxBBew70N26CmhZYNP0sCCxaAVoQyAyc jYO3gPElqFGBRWYf3NG8wCLzX+5oXiAzsJst0MeF/vyXb+xbFljyYWCftCxQ9xYID2hZIDPwL/ME ip/1tSXZtCywcP/zQNMCC4+ADDQtkBn4xRyBig/FfMi+ZYGlz0AiTQssfQ4caVogM/COlwTegguf A0dObQosPfr2RaMCS4//ftGoQGbgT14QKCWf5vyNbZMCazj9uNGmwBpOgG+0KZAZmOSlOrAOto0K rCYDWxVYTR3YqkBmYJIMgZ+nvvkbXZfmBNbQ+XJPcwJr6P67pzmBzMApngh0XRXdf99oSmBt2Rdp SmBt9V+kKYHMwGdMC/S11X+R/xoSWMMkrB80JLCKaYA/aEggM/A5T+rAWb/hquybElhhBjYlsMY6 sCmBzMDnTAhUfhrcM7bjPw0JrGcewkB7AuuZCTPQnkBmYA7TdWBFnNoTWFcGNiiwrjqwQYHMwBwe CPSPVxVhU5dAf/zf1cXeUv/IUm2nIJUJvAR3vbyH1wOB1Z0E1yXQ+Zh8BxdezMB5f8KH89u0QL/A L70g+9oEvh3Oo0D3INUqy8DqBIYDyGQG1lYHNieQGTi9Pz6omzgKV9YROAqqSaC77uRjoh1Y1ylI V5/Ae1IC6zoJ7toTyAwEBdZ0Etx9mmlJYGUZ2J7AyurA9gQyAxGBwjoQEljN9UhftCWwmivivmhL IDNwgTqwMtoSyAxkHcgM/IeWBPoK68BTSwIr64geaElgbUMhAy0JZAYuUAdWxGlctiSwrgw8jcuG BFZWB57GZUMCmYGQQKmrDty3JrC2c5DmBNZ2FtycQGbgAnVgPWzaE1hXBjYosK46sEGBzEBMYF9V HbhtT2Bd0xEaFFjXhJgGBTIDEYGusgkxp9YE1naTtuYE1nabwOYEMgMxgd4t9Isvw6Y5gXV1RLcn sLKhkPYEMgMxga6qoZCuPYG1HYIjSudFp7iABdbWCIwonZmf4oIZOJ9TXKAC+7oagXc11Wn4MasO nFnUUAIqsK5umE5V4EMkO7KvrCOwa08gMzCBZEf2UlVHYERL4DLtwN1lTtnrotQsWKghXdVo8IhS w5QZCLJQBuaHqrB9qQ6EsJmBigKnkOzI2urA5gQyA5NIdmRldeC+PYHr7cQcKBCEAkEoEGJDgRgU CEKBIBSIsadADAoEoUAQCsTYUyAGBYJQIAgFglAgCAWCUCAIBYJQIAgFglAgCAWC/B8FYlAgCAWC UCAIBYJQIAgFglAgCAWCUCAIBYJQIMSWAjEoEIQCQShwDtv7txT4OhQIQoEgFIhxokAMCgShQBAK hNhQIAYFglAgCAVi7CkQgwJBKBCEAiE2FIhBgSAUCEKBGFsKxKBAEAoEoUCMEwViUCAIBYJQIMKe AjEoEMSAQH+8eBcfCOkpMI1Mr7747r2X+Cog8NS+QOe9c/4QXxSYRqZX+8OZAieR6dX+7XAT6PQf q2lCYHcolYEbCsQwItD7UkdhEwLddSel2oEmBN6jLPBEgRgUCEKBIBQIsaFADAoEoUAQCsTYUyAG BYJQIAgFImwpEIMCQSgQhAJBtAVuxi+Om/hv/P7fLYf9GNcPJWMPqc9XgLMTvbJMCjx4vbJMCmQG zmf/Qh24SIEUWBTJjqTAJJIdSYFJJDtSR+CGAjEoEIQCQSgQY0uBGBQIQoEgFIhxokAMCgShQBAK hNhSIAYFglAgCAUibCgQgwJBKBCEAjE2FIhBgSAUCEKBGCcKxKBAEAoEoUCILQViUCAIBYJQIMae AjEoEIQCQSgQYkOBGBQIQoEgFIixpUAMCgShQBAKBKFAEAoEoUAQCgShQBAKBKFAEAoEKSLwFDYQ Nxu3nHHfmCkku9CVBB7X2ew0lgS+5+/BclgSyAwEQerA2VAgKHBBJDuSApNIdiQFJpHsSApMItmR FJhEsiMpMIlkR1JgEsmOXEfgiQIxKBCEAkEocBZfHXkUOAsKBKFAEArEOFEgBgWCUCAIBYIUFLgf y7kfE8GQ7MhVzkTcZY2tTmBNYP++xlYnsCaQGTiD7ZM6cKlyklBgbUh2JAUmkexICkwi2ZFLCTxR IAYFglAgCAVCbCgQgwJBKBCEAjH2FIhBgSAUCEKBGCcKxKBAEAoEoUCILQViUCAIBYJQIMLmdwr0 3fnqOh9eFJhGpldfunPXy3t4UWAamVzrvDt3/uDCiwLTyPRq35/fFhG4/70Cz6NA9wGV82sFenHM wClkerU/XihwEpleHZoxbomj8OmXCnTXTj6WaAf+VoH3UGASyY6kwCSSHYkI3FAgBT5AsiMpMIlk R1JgEsmObFvg5/0Bx/1YEMmOxM5EsDNpnNYFugPy7QVoXSAzEBG4n6wDZ2/2JSiwViQ7kgKTSHYk BSaR7MiZAvcUeIMCk0h2JAUmkexICkwi2ZHzBJ4o8BMKTCLZkRSYRLIjKTCJZEdSYBLJjqTAJJId SYFJJDuSApNIdiQFJpHsSApMItmRFJhEsiMpMIlkR84RuKHALygwiWRHUmASyY6kwCSSHfmiwFNc UOAdFJhEsiMpMIlkR1JgEsmOfEnglgJ/QIFJJDuSApNIdiQFJpHsyFcEbinwJxSYRLIjKTCJZEdS YBLJjnxB4IkCE1BgEsmOpMAkkh1JgUkkO5ICk0h2JAUmkexICkwi2ZEUmESyIykwiWRHUmASyY6k wCSSHUmBSSQ7MlvglgKTUGASyY6kwCSSHUmBSSQ7MkPgZlhSYBoKTCLZkRSYRLIjKTCJZEc+F7il wCkoMIlkR1JgEsmOpMAkkh35VOCJAiehwCSSHUmBSSQ7kgKTSHbkE4EbCnwCBSaR7EgKTCLZkRSY RLIjpwXuKfAZFJhEsiMpMIlkR1JgEsmObFDgEs+UfoZkRz7bG3dB9mMVjgplSHbkM4H9O7Qja/Au 65eRXwQzMIlkR04LPF5/KUsJ9K6T3t0Cpe/H/5nwoY9P93MS1scVQ9jw4Y34JR8+ceP68adha+N3 h0+GL93tyMV/hcX1tzSQvwWMu9S93Yr0f4u824/haXkhurvfJXkbv/93y8Oeye3X6d3w6/R/v+hd tj4KpMCKBe6u18sLW/qlTAjUaLC2DwWCUCAIBYJQIAgFglAgCAWCPLB0DCfUpR9b2AYPBHrVnWgZ CgShQBAKBKFAEAoEoUCQlED2pL5ASiBPQV6AAkEoEIQCQSgQhAJBKBDkhyx2BL7GD4FSYCdahgJB KBCEAkEoEIQCQSgQ5LvA4yvTq0nku0BfZidahgJBKBCEAkEocA5+vM4iXjFBgXO4dPLeDy8KnIPz 7uz8Ib7uBV45HJyL71MCpdj+NMeXQHfX+yzF9qc5vGcGQvjj/34I3PEsOB+fOApzKC4fd020Aylw HhQIMnpzHAyey01g4b1oGAoEoUCQQeDxWno32mUQ6AvvRMtQIAgFgvSxEXgpvRcN0/MQjEGBIBQI 0nc7NgIRenbDYOzK3WazOVbrsFqmEvWLbEWW2Ij2HyUFglAgIeSX4i7HeG/2zzsKz+ToLmFL/bfb Ir++kV1oZshVxjdz2Z3DecXHi7dCBuh7kU7OcZoDsBV5D+35Pk6VQDYS9LuwM8Ob2fhgzrlh1gGw L/mMAvtYILCVUWDcaQE2Ij5sw4V/7+4I/jLeh/+GYd4LsJFXiH+7sMD4twsLDOZiXRJqA2grUZym wFhXXFGBcY6Ju4AC3VCLHuNd3i/AvkioQHtFgbG+GWcqARuJaQxn4NAtEutAqH/ExdMCrydwvLM/ KnB4lgAq0H8K/Hfm/Ev0UaDoCRyqQPwoHKtA+Cjcx6dNRHrkKOwCnd5RePdxPV/gduD1z8cRbgfG HdnF7YQ387dyvHyEpqBeOzAiS2xkkfP3YSOCboVDHIQQQgghhBBCCCG18P9CYeUtVGV5QAAAAABJ RU5ErkJggg== ------- =_aaaaaaaaaa0 Content-Type: image/png; name="z3.png" Content-ID: <31833.1376330264.5@alva.home> Content-Description: .png image Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABQAAAAMgAgMAAAAB9idoAAAACVBMVEUAAAAA/wD///9JuQheAAAQ GUlEQVR4nO2dQXLivBZGFVUGroyyBFVGXayCwVuYihHVq6B6RLHKZ8n5A02gY/zZ1r3JOUU5AWxZ faIrf7TBhAAAAAAAAAAAAD+OeOhCLst46Jebl+P7Iy/HU06n3aFfJYe86RdlGfqnTjl0L8fyezyU dXLbf0Bruu4t9ka6X13XL3Pu/nukF5bCvv8RUsx5l0K/zOFXTDmEX6Erv/eb5HL3R9NL2xeBRVUR mP57JMRwiF03rJL7p4uz3mhXliH1d/rf+3Vy2/63pysDq5dUVZVRNzzS9UWdBoExVIHhfb3fZb0i sAzWmH437b0BUhWYupdDKdYy19VHXrpNTF08nn4fe3ObKvBUBR6KumE+TP06P34I5iow1yGYu3qw GMZk2KcuvI/AMIzAXEdqFVhHYP94Klv8ZGJ1EauZWIbg+yO9nt/HFN4L+1pgWacsQxmfjf8FjenC Wxl+xUxxU0wOj5QDSqpzYD/I+qNwHXW5n/Tqstwp6+cyGf5oXo4l1PWpb3eoy7AZHukzYUipD4f9 yCupL2/qg6d+PuyX/Wr98nf/eNq0/hdYoLuz/LRODtdLAACAyucjhzVeQ3gOr0/h6eazzfvfvANf gkARBIoYF7jPrXvwFcYF2n9VZlRgat2B0RgVeGy142nc7W4rgfGt0Y6ncb+7zUvYCeneEwgcR7r3 BALHke49gcBxpHtPIHAc6d4TCBxHuvcEMWYUBmMMQVoktdrxgzzzUk7DqkA3c6BVgZSwSmq14wdB oMgXAmOzuTy12vGDMAJFEChiVSAxRoUgrZDdlPDWpMD6Jl4f2BTY7VvsdRI2BTp6qzMCRRAogkAR BIrYFMhRWIQcqJKb7PVxXo0KdDMCrQp0MwdaFUgJq+Qme30cBIogUASBIggUsSqQGCNCkJ5MGn7k dfc6kWeDAr2czKwYFOjmdHrFoEAvZ4MHECiCQBEEiiBQBIEiBgUSY1QI0iJp3d1JbC0K9DQCLQp0 NQdaFEgJq6R1dyeBQBEEiiBQBIEiFgUSY1QI0hLRTQkXWQYFvuQ196ZgVOBbWnNvCkYFxjV3JoFA EQSKIFAEgSIIFDEqkBgjQpAWcVPCz0YFuhmBVgW6mQOtCqSERRAogkARBIogUISjsAg5UMRJCT+b FehkBH4tMIV8jCGVs4zMgZ/5WuAh7GKX9/2NEr7BlwJjiruY3soNgTcYUcIdAv/BGIH5OAhc91Lw 30dgYgT+gxECN38QeJ8xMabNUfi7xJh4apQDv02QvoASvubJsEAXI9CyQBdzoGWBlLAIAkUQKIJA EQSKIFCEGCNCkBbxUMJbywI9jEDTAj3MgaYFUsIiCBRBoAgCRRAogkARYowIQVrEfgm/2hZofwQa F2h/DjQukBIWQaAIAkUQKIJAEQSKEGNECNIi5kt4a1yg+RFoXaD5OdC6QEpYBIEiCBRBoAgCRTgK i5ADNRIlrGH/mwhsC3TwXRi2BYa04r6mgUARBIogUASBIggUsS2QGKNCkBZJK+5rEk/GBZofgcYF 2p8DjQukhFXSivuaBAJFECiCQBEEihgXSIxRIUg/SvrnXXuYE2h+yF0RD49vs6RA+5PeFd1+wjbz d+NMWrLxJcgPb7HslczTko0vQX58E0bgJfnxTRB4SX58EwRekh/fBIGX5Mc3IcZcYC7GEKRF0pKN LwAv5USsCXQ3B1oTSAmrpCUbXwAEiiBQBIEiCBSxJpAYo0KQ1shpwcaXwJjAKS/N22JM4JT/HGqL MYFT/nuyLQgUQaAIAkUQKIJAEWMCiTEiBGmVvGDbS/BqTKC7EWhNoLs50JpASlglL9j2EiBQBIEi CBSxJpCjsAg5UCO7KOHni99tCXQy/uwKdDID2hXoooARKINAEQSKIFAEgSJ2BRJjRAjSKnmxlmdk a1egjxFoWKCPOdCwQEpYJS/W8owgUASBIggUQaCIYYHEGBGC9GTS8CPP3/L8mBTo7SOGH0zq+PwC 3X3I9T+mdXy5EvZHmrIRAs+kKRsh8EyashECz6QpGyHwTJqyEQLPpCkbEWM+eKDjKeRjLN+XnAjS F4zv+CHsYpf3/e1nl/DrqJdyn4kp7kJ6i/3tZ4/AqQJD6hYU6GgOVAQeB4FLXAo+zd/kQkwXmHZx uRJO8ze5ENMFbv4gMCgCOQpXJh+FT4vmwDR/kwsxeQRegMCLuzYE/oQYcwFB+uKuCYHRTQl/8mND 4Eueu8WlMCrwLc3d4lIYFRjnbnAxECiCQBEEiiBQxKhAjsIi5EARNyX82Y8NgW5GoFWBbuZAqwIp YREEiiBQBIEiCBRBoAgxRoQgLeKkhJ/NCnQyAu0KdDIH2hVICYsgUASBIggUQaAIAkWIMSIE6cnk unRRwk8WBfq4UMyASYE+LlU0YFKgjyvtDCBQBIEiCBRBoAgCRUwKJMaIEKRV8nxNLczWpEBHI9Cm QEdzoE2BlLBKnq+phUGgCAJFECiCQBGbAokxIgRphXIuLs/T1MJUNfYEOjkbHMwKdPJ+hGBWoIvT 6RUEiiBQBIEiCBQxKpCjsAg5UMRNCW+NCnQzAq0KdDMHzi1wrkvBU8IiCBRBoAgCRRAogkCRHxtj CNIXzzUSGD8W9nm2KNDN4AtGBbqZ/oJRgU6qt4JAEQSKIFAEgSIIFDEpkBgjQpAW8VTC/7Mo0NMI NCnQ0xxoUiAlLIJAEQSKIFAEgSIIFCHGiBCkp+PphFzFmkBPg29g/k9ESgI9TX8D838mVy9hX+S5 G0SgCAJFECiCQBEEihBj1BaVjQnSP6qEX79+KTeh1R80Ag0K9DUHGhRICSMQgeNBoAgCRQwK5ChM DmwqsPNTwkWNPYEbYduVsSlwn4WN18WmwNm/FXE5ECiCQBEEiiBQBIEiNgUSYwJBmhIexatNgX5G oFGBfuZAowIp4YBABI4CgSIIFJlbYAq5iyH1NwRerzWKQy+wy/v+Roy5XmsMMcX8K73F/kaQvl5r FKkfezMI/CVsuy7LCZSuZD7TVdBXYHaBadfpIzC+Td92ZWYXuPlzmqGEk7DtuiwRY2Y4Cidh23WZ +yh8micHJmHbdTH6SiQJ264LAkUQKGJT4A+OMRcoI/DnBukLKOGrtR6FEXi11qMwB16t9SiU8NVa j4LAq7UeBYFXaz0KAq/WehQEXq31KAi8WutRiDFXaz0KQfpqrUf5CSX8bFWglxFoVaCbOdCqQEq4 gMAzCLwDAkUQKGJVIEfhAjnwDCX8iW1dmhVofwRu69KqQAdz4LYurQqkhAsIPIPAT2zrEoGT2dYl AiezrUsETmZbl1YFEmMKBOkzKwuM5kv41bZA+9f/NC7Q/hVojQu0fwFVBIogUASBIggUQaCIcYHE mApB+mJ9SviSJ+sCrY9A8wKtz4HmBVLCFQSeQeBfIFAEgSIIFDEvkBhTIUifoYQv2ZoXaHwE2hdo fA60L5ASriDwDAIvQaAIAkUQKGJfIDGmQpA+M0XgI5eCv3JNCVceGIF+vryhYFCgn68PKRgU6OcL bAoIFEGgCAJFECiCQBGDAokxtyBIn6GELzEokBF4C+bAM5TwJQgUQaAIAkUQKGJQIEfhW5ADzywr UPsi2LV5tSfQ+FnMKwwKNH4e/QqDAo2fBr4CgSIIFEGgCAJFEChiUCAx5jYE6YuNKOEiq2JQoJMR aFegkznQrkBK+DYIPIPAgEAZBIogUMSuQGLMbQjSZxYVmHyU8NasQPvf3FAxK9DBd4dUzAoMaULb DUCgCAJFECiCQBEEipgVSIy5B0H6DCX8aligixFoWKCPOdCwQEr4Hgi82ByBCNRAoAgCRQwLJMbc gyB9sfkSAvP7zzSh7ZV5sigwHia02QiTArv9hDYbYVLgRwk7AIEiKwpMIR9jebdGQuBFA+MFHsIu dnnf3xB40cBogTHFXUxv5YbAiwYeKOEujxTIUfgmvcBuEPjVlczJgTdJKadvV8LbNQVuDnmcQEcj cFWBYRfGHYUdzYErCoynsDt9uxy45gi8AIFnEIhABQSKIFDEpkBizFcQpM/MLrB8uitPaLMNBgU6 +XzhmRbnXv8l0MknXD9ocvb/qxJ2RWqwTwSKIFAEgSIIFEGgCDFGhCAt8n1K+LQ8t3b7fUZgLqd4 8vu/J73frXe64aItKYR9ebiu2pVVz+sPG8Wchue6utb7Cum9hdvj6fvMgQYF+iphBIrkNrtFoAgC RRAogkCRbxRj2uz2GwXpNrv9h8Dsp4Rj/zort9n1fYGOTgm3nK3vC3T0pgSbAh2dU0egCgJFECiC QBEEipgUSIwZBUFahBIWYQSKMAeKUMIiCBRBoAgCRRAowlFYhBwocldgclLC8e4799bhrkAXl6wM 7c/+3xPo46Kpwa5AD9f8rCBQBIEiCBRBoAgCRawKJMaMhCAtQgmLMAJFmANFKGERBIogUASBIggU QaC4+3txjxgzEoK0iO8S3jQ9IVfxPQJT6w54fymXWnfAewmn1h1AoAwCRRAogkARBIoQY0QI0iKf BOb3n2nVbkwkte7AZ4Ge3thrUqCnt5abFOjkndHvpNYdQKAMAkUQKIJAEQSKEGNECNIifku4nJE7 tO6E5xGYWndgwO8cmFp3YMBvCafWHRhAoAgCRRAogkARjsIi5ECR7vpubtKNCaTWHRi4Erhp04sp pNYdGLgSuM9NejGF1LoDA59K2A2pdQcGECiCQBEEiiBQBIEixBgRgrSI0xK2cUKp4HQE5tYd+MDp HJhbd+ADpyWcW3fgAwSKIFAEgSIIFEGgCDFGhCAt0v19hxJ+lL+MeRl/ZgV6mQHNCvRSwAiUya07 8AECRRAogkARBIoQY0QI0iIOS7h8xiu37sQHDkdgat2Bv3A4B6bWHfgLhyWcWnegfu1jiqHcEDiJ Q8j7rt4QOIWY4i6mt3JD4CRSh0CJs8C/LwWPwJGkdHsEEmNGkjZ/bgokSI8kXR+F3zV6KOEXA++s jKfrHOhj6FWs/ZGH/viY/Co2BVrr1T+w1lUEiiBQBIEiCBThKCxCDhTxVcKn08naNf59jcDcugOf 8TUH5tYd+IyvEs6tO/AZBIogUASBIggUQaAIMUaEIC3SVYM+SvjF0NsCP+i8DL5g9M/ceZn+glWB Jnt1G5NdRaAIAkUQKIJAEQSKEGNECNIifko4mjshV/EzAmPrDtzGzxxoVaCfEm7dgdsgUASBIggU QaAIAkWIMSIEaZGXE4xlpZeSC4yUNHuLlmd+BIogEAB+KPGwKe/0yjN+R+ymfF9v6kqbM/GS+zhy rJ83N0fX5RzyrlyOYa4m8743V6/vMFeL5UoRMdYrHszV5GwMAuvlGOZqsjZ1KG3mmVqsAuvfJM3U 4ozU2p1VYKndmOYUWGrXrMAyr8RuToHlwhgzCyx/kqNRgWWq72YVWMZ0N6vA+ieJNgWWvvWHzDkF ljH9cpxTYPmTWBVY+pZznPUoXL6iY96jcDkIGz0KvxxPu8Mpz5kDT7+Pm3lz4ObPqY+CNnNgIc/e 4vwv/I2qAwAAAAAAAACAK/4PlaaKHKZlev0AAAAASUVORK5CYII= ------- =_aaaaaaaaaa0 Content-Type: application/xplot; name="201.216.227.201.53479-190.16.105.178.12345.xplot.gz" Content-ID: <31833.1376330264.6@alva.home> Content-Description: xplot input file Content-Transfer-Encoding: base64 H4sICOkYCVIAAzIwMS4yMTYuMjI3LjIwMS41MzQ3OS0xOTAuMTYuMTA1LjE3OC4xMjM0NS54cGxv dACUvVvO7ExyZfmuUeQE6kfwTr70XAotoSC0Wg2olV3Tb/qVbu5r2/kdAlKZZ9uKzdjGiI9k+OW/ //3//rf/73/+xz/+33//X//5b//6L//97//9H//2L+tv+Wtdzr/W9for/Pdj26/nf/yP/2N5fn+9 /7z8jr+W6/5rWbf9+Jd//Z//9V//z//+x7Jd53pdy3P99dzb+dv+8fuXfypp+Zf/+Pf//DdisLi3 uP/6Ldu9v8WDRSNZi0/AYrZ4FmkRpH1/0CVoqh6Nnt8vqegV1PV+LvIqpEKE3ZlUYXf+Yw+dRbtE KoTtliWpbPeqx/VsaJdJhQi7K6nC7vrHte54ehRSIWy3rkllu1e9zxvPk0IqRNhdSRV2b2ve/8/n SkYlw4bblmV2DPJy3Hy6FFZCwvLOsrB85e238SlT2BnoXu7uE3se8d/G4izAv6mPaKzf9xsNwr9L EwGt20pfPN9R9P+87eLgPg3+mT+UzSHQS8lDKyL8+/b+XYHT5zuK/p/fb2x5cFmDf+av6+YQgNGH VkQyuu8DP0yvfOz5LIQzO8vylCishNjy3LLMlkE+npWjKayEhOWdZWH5ytd28QlZWAmx5XVmmS2D fN8r97KwEmLLZ88yW77y+lsvPk0LKyFheWdZWL7ycq18+hRWQmj5/NYso2WUt+XE06eyM1D5qNp/ fvbtUJ/gqtE/81d+80ElKH6AlZGAjvdilT8Pz35s+f1Shknez4UtCyshYXllWVi+8vnGwJaZlRBb Xr8ss2WQr2OhbnyshITllmVhuYU/bid9Hj5WQsLyyLKwPP6x/fYfn6eFlZCwvLIsLF95UWdsYaeg 8sEx/35tx/XLH6h//e9//z//L6mKl4yfEIDSJ+ef4iWTOrxk49f++3u1+ZynOI5WpH/nv7zNYQDE h9eK9O/370fnV5DvLTdmbHaRtw0uSlpWQsLyzrKwfOX3FOU8CzsFlbDtv6+/dDMLTWhF+nf8096G DVBqgnBS0LX88CY+yld+yxRjks9VWWZ2DvqNFxHh39/bY5XIJ9K/43Vg+84BSokIJwWd64p/RoL8 Xi6kt8wxBvk6hWVhJSQs7ywLy1d+fnAD1bISYstw0xFltnzl/XfAQ5iWnYJKf+2/H8d6yr5/Ivw7 //Vo+wtQ6rtwUtBzPPikIMj7kd8yxZjk5YFbxZaVEFuevyyzZZC3HR4wtayEhOWWZWH5yvsND5la VkLC8syysHzlc4PnTC0rIWF5Z1lYvvJ1wYOmlpUQW75/2JPMlkF+VryS+FgJCcs1y8Jy/cfxO/FP 4MdKSFjuWRaWr7wu4hugsBISlmeWhWW4NjrgCUDLSkhY3lkWlq98/PCP4sdOQeVL0P77c7yftfTl OFwlG1W8ZPy2Ayh9Cw5XyUYdX/LzM/9+/N4vPnUcjUj/Lq7qvsMASBxeI9K/3zef0q8crshjY6DZ WT53ePbSshISlkeWheURHjzCs5eWlRBbvhfRSWbLID8bPEZp2Smo9Lf/92dVfW9E+ne+Umv6C1Dq u3BS0Huxf9H3SXMcw7+fzvEVEf5d/HlvjwMo7wBPD7uOE79lj9/yK73E8yPI5++G50otKyG2XPYs s2WQ+RqvYSUkLJ8sC8tX3i54rtSyEmLLs8hsGeRjgedKLSshtny/CpLMlkE+8VFDw0pIWN5ZFpav fP/4L0RlJcSW95Zltgzyc9DTjYaVkLC8syws739c7x8vPn0KOwPVrwj779v7/S+/Oj4R/l1cgbTf D0DlLw7hpbHlef8bRrmd7+covW2KMsnrTg8rGlZCbHn/ssyWQd5u/A7/WAkJyy3LwvKVj5WeBjSs hITlkWVh+crnRTf2DSshYXlnWVi+8r3QnXPDSogtn1+W2TLIzyk+H4WVEFpevy3LaBnk+/2Lh6dP ZSXElssvy2wZZb5O/FgJseV7lZdktgzyxpd8HzsD1W8l++/Xee/522q89WlV9aUUv3uAyl9K482P kcdX/SzNv9/nb5M3do1I/y4u8ZvjAEodYKuSsK7iafOrH0fuD/Q8yzte+zWshNjy/GWZLYN84rVf w0qILd9bpiSzZZAvvPZr2Cloo9umAMnbu0aEfxcX4G2DgcqdF14Otj/8hX+H48hvm6MM8oPXtA0r IWG5Z1lYvveAP7ymbVgJCcszy8LylVe8pm3YKaj0eIDkzVcj0r/zVX7bYKBy54WXxrb306A+7u8f 2/S2Ocogb3it3rASEpZnloXlK+942d2wEhKWd5aF5SufeE3bsBJCy+X3yzJaRvnCa9qGlZCwXLMs LF/5wWvahp2B6pls//3Zw423OMM/kf6dbwvb0xiofH4LLwfbTn6Af8eRDOltU5Rp7MTvhxfrDawp Ng2jlZLOrlFf8Xq9pTXGtuHUTjrbRn3Da/aWnsNKt82/P9v2fg3n+/zhOrBVZbNDT4HKzR4vLo08 vGpj2f57+NI71OnaivDv4ua5PQ6gxAEaFYWHn3UHPQytSQ0a+171g26cDK0xYbsXXdgG/TzgE21o jQnbs+jCNj5moV8wDD2HlX4PlDoPWpH+HR+DmGYDlc8C4aWxfePrhqDfW3nfHGfU3688tq20xtg2 PgyLOtsG/b23hp8WDD2HleAH6nYaUkT6d3zMY1IHKrdDeGnsWBfVxTucZOl9Y5xJXzf42djQGhO2 e9GFbdA3+iXF0Bpj26XqbBv1Y4UHBoaewmq/7b8/x/tXWZ0Hnwj/zjdTptlA5bNAeGnsvVDDK9yg H0t53xRn1s8Tv3kaWmPCdi+6sA36vcBdvKE1JmzPogvboD/0NN7QGhO2T9GF7auv4YdFti20xtg2 3JInnW2jvu7wHMjQGhO2W9GFbdC3Bx7rGFpjwvYourAN+rHBcxNDa4xtr7vobBv188aPe0NrTNg+ RRe2Qb9XeBRiaI2xbfgzkXS2jfpz4RV1Q2tM2G5FF7ahbQs9uTX0HFa+p82/L1sYapCfa/U3IkZV X9Px2xio/DU93N1YeXjVxtL8+3srsqindq1I/44Pi8xxAKUOsFVRuHn6c9C3X2kQ9L3o6ylsK60x YXsUXdgGfafnvobWGNvud9HZNurHDs9xDD2HlX6bf3/PjF09NGxF+nd8BmeaDVQ+C4SXxq6FZ5cH /fyV9w1xFv2kh7GG1piw3YsubIN+b/AAyNAaY9vwByPpbBv154YnOYaew0q/+3+/f+o8aET6d3xK aZoNVD4LhJeD7Tx5P+pHed8cZ9D3948ZfAW0tMaE7V10YRv0FW8hW1pjbPv8is62Ud8XekDS0nNY 6bf99z08e1LnwSfCv6vnXG23CUungTDT2HunioNeg35f5Y1Tnlk/8GFgS2uMbcOoxqSzbdSvHz0h aWmNoe0d/g4kHW2Tfh/0AKKlNSZsr6IL26A/Dz2AaGmNse3yKzrbBv14Pw900jf0FPad3la47/is TZz3jUqCuK1vT2/C0nmv3CT2rDwf+dWf8LcgvXeKNOvrjUfb0BoTtmfRhW3Q940eQrS0xtg2/MSR dLaN+nHRQ4iW1hjbBiLpbBv1a6WHEC2tMWG7F13YBv0+6SFES2tM2J5FF7av/l6i00OIltaYsL2L LmyDvhz0EKKlNca24YYm6Wwb9e1Ht4ItrTFhuxZd2AZ93+khREtPYd9XVytsv/Ul6jPH/h7ayupV 41cUYem7a7gzt3L/qsbTCOv2C8nywRgVBXw+aY6FMHGQrYrCzgssBD0MBEx9Gttf9YPW5TG0xtj2 WIvOtlG/NniqY2iNsW3IJ+lsG/X7hpseQ89hteFWeAH5pNqoJPAjX9NwwtKZoNw0dvEaS68eVpfJ 750iTfr1o4WqDK0xYXsVXdgGfTnhDsTQGmPb9Vd0to36tsDzCENPYV/DrXC9f8z1mdCoKOBTdNNw wtKZoNwUFlZWEJ/J98Z+Le+dIs36fsDDAUNrTNieRRe2QT9/8NDE0Bpj23A7nXS2jfq1w72Aoeew 2nAjhJWhNnkmtCoK+MOEaThg+UwQbg628XoSQd+e8t4h0qK/VyRwtC2tMbYNf6mTzrZBv38bPDgx tMbYNnzAks62UV9ueCxh6DmsNrwXwoNUcSa0Kgn8o41pOGD5TBBuDnYe+LQ36kd57xxp1LcV7pgN rTFhexdd2AZ9v+CRi6E1xraBSDrbRv1c4JGLoeew2nAjvHcO8R6Yz4RWRQGf+5uGA5bPBOGmsWXl tTSCHiYXpPcOkRb9/Re2rbTG2DY8T08620b9vaThbCutMbYNIyWSzrZBf79Q4JGLoTUmbO+iC9ug Lw9dTbe0xtg2nLlJZ9uobzs8cjH0HFZPbyuki7P8w9VwJ2tkdX7H0xiwfH6P98dGHl+18TRC+GrS B9OqKOCvVeZYAFMH2aokrD9ef+jVt7AkeuoTtL/o+02X4C2tMWF7FV3YBv3c4NGXoTXGtuG8Szrb Rv266Hqxpaewr+EDtsszoVVRwB9nTcMBy2eCcNNYGBjhHGT/m2wULucgP5UE/snSHAtg3kFeDvbe APC16KuHh3ypr3y6RP29ueWjrfQcViMwwnP8FvlzrlFRwB/UTASA5WyEm8beKxr8ZSro33uHSJP+ 3iWddMHd0hoTtlfRhW3Q14UeA7a0xtj2+BWdbaO+HXR12NIaE7Zb0YVt0A8aCWXoOayeZwOmT8BW RQF/mDfnGWD5BBRuGntv5byD7H/t3o8jXkvyQRoVBfzZ1xwLYOIgjUrCtvMFb9Dj7UTs63i6VP2k 5bINrTFhexRd2Ab9oiFXhp7DavK9EAYRcUuMSgL/7GuSByy3RLg52MkX80G/t/LeOdKoP7Qdi6E1 JmzPogvbcHX6o/FPhp7DavJWeNZT/hJvVBTwR16TPGC5JcJNY/t64e9WQQ9+6b1TpFlfaesZQ2uM bUOnk862Ud9oLJKhNca2z1l0to36scDNj6E1JmyfogvboJ+0HY2h57B6nhnhvX1dVnkCtioJ/Eu0 Oc8AyyegcHOwmy89gr7W9w6RFv2m9dQNrTG2DRvCJJ1to/7QoCBDa4xt96vobBv097sNHnEaWmNs G67/ks62UV9pTxRDz2H1PLPCFVYVzyfg8MzGyvJEu7uLzYzlE214ZmPl8VUbTyNc7x/kUx5Mq6KA P9ebYwFMHWSrknCI/d2Cfm6lT9D+om+0ZLuhNSZs76IL26AftEeNoTXGtu/HI+tsG/WT9qkx9BxW Gz5gmzwTWpUEHiVgGg5YPhOEm4OJLfSifpf3LiIN+k1b6hhaY2z7LEVn26g/tHWNoeewmrwRnpf6 yZa0Kgo4lMEkD1huiXBzMLFdYNDXs7x3iDTr20KjqgytMbbdlqKzbdRX2p7H0HNYTd4Kx3qssiWt igKOgDDJA5ZbItw0doqNEYN+3uW9U6RZ32h4k6E1xrZhf6Kks23UD9qCyNBzWE2+FY51i3+3uSVG RQFHQJjkAcstEW4OtvG1aNDDU+r03sdIq37SOCNDa0zYPkUXtkG/abMfQ89hNfle2FfVEqOSwMM0 TPKA5ZYINwcTOw8eaZRnfu8cadQfGvBjaI2xbbgOTzrbBn1faB8fQ89hNXkrvFe3h25Jo6KAoztM 8oDllgg3BxO7KwY9/DSc3jtFmvWVRt4YWmPC9iy6sA36TpsBGXoOq8kbYb/SlBluSauigCNfTPKA 5ZYIN41dG6/qFPT7Ku8dIi36QUNgDK0xtn3WorNt1E/6ddXQc1hNvhPitDPRklZF4aJxOiZ5wHJL hJuDXfzwJOjLUt47Rpr0m5Y4N/QcViMYsM3J5lNJ4MFAJgLAcjbCTWNvZ/EiMup3ee8i0qA/tLmT oTXGtvFr8OH9nYr+XpvSxUBLz2E1eSMcyxL+komWtCoKOGLJJA9Ybolwc7BHXES++vGU9w6RFn2l DawMrTG2Dc+Aks62Ud9pEytDz2E1eSuE7WVKS4Yni1aW0T/9VV/CcvTDk0Urj6/aeBrhvNawYrc4 mFZFAQc6mWMBTB1kq5LwLOKC93y/xZfSJ2h/0Q/aUMzQGhO2Z9GFbdAv2lTM0FPYl3yPhUmqoiWt igKO6jHJA5ZbItwcbBcXvK8e7hbTe+dIo37TpmmG1piwvYoubONNNS2Vb+g5rCZvhPfaKg655Za0 KghiMJBJnrDUEuHmYBdvmR70ay3vHSIt+kLrbhpaY8L2LLqwDfpKa9gbeg6ryRvhDk+2ZEtaFQUc sWSSJyy1RLkpbPv9eBf1oIdncem9Q6RF32mXDENrjG3Ds7iks23UD1pc3tBzWE3eCM/yC9eSoiWt igKO6jHJA5ZbItwcbOOd4oMefhdO7x0iLfpFu1cYWmPC9im6sA36TZtRGFpjbBsfoN682UPRrx/t 9mDoOaw2vBXO33k/mzoTjEoCDyYyDQcsnwnCzcHOHVclOMOiQ09572OkVV9oXTxDa4xt443lwhta VH2jzSkMPYV9yRthWeLVLbfEqCjgGCSTPGC5JcLNwR7e7j7o61HeO0Ra9J0WqTO0xoTtU3RhG/SD drcw9BxWk7fCE7/tRUtaFQUcKGWSByy3RLhpLGx2QxdaQT+v8t4p0qxftGKcoTXGttdSdLaN+k2r fxt6DqvJG2ELO3bKlrQqCji+yiQPWG6JcHOw44erGAQ9PB9P7x0izfr9o+XbDK0xtg0/XyedbaO+ 0FLchp7DavJWeH7hS1m0pFVJ4EFgJnnAckuEm4NdPD0t6OH7KL13ijTrG+1UYmiNsW24EEs620Z9 py1HDD2H1eSNcKUWi5a0Kgo4HsskD1huiXDT2PrjZ8RBD7fw6b1DpEU/6UcGQ2uMbeOH5+RNQKp+ 0SYghp7DavJWeOLvhaIlrYoCjscyyQOWWyLcHGzjZ8RBD5Oe0nunSLN+004lhtYY28bnuTdvBFL0 9z/hkaih57CafC+kOTrckkYlgUfxmOQByy0Rbg728NO6oIfB4em9c6RRX2i3EkNrTNjuRRe2Qd9o MxBDa0zYnkUXtvEJHW0GYmiNCdu76MI26Cft6mFojbFt+DU36Wwb9YtWdzP0HFZPbyPc7ydPjl4z Kgo4VMqc3oDl8164aWxb+ZHoq4f12PJ7h0iL/tCGIIbWmLB9ii5sn/AUi5ZZM/QU9iVvhfD3Rrak VVHAoVImecByS4Sbgx38SDTo72c2v3eKNOsrbXZiaI2x7bUUnW2jvtF6Z4aew3A82BmeeW11GFr/ O6iVZfRH91g4Yzn64ddVKw+v2nq2wvVLE3H4YIxKAg/rMscCmDhIo6Jw8+PboIfMUp/G9ld9p01n DK0xYXsUXdgG/aRF0gw9h9XkjbA8RxxLgi0xKgo4rMskD1huiXDT2L7wVsRBD37pvUOkRb9oQx1D a0zYPkUXtkF/aLUyQ89hNXkjrHnqFrekVVHAMUgmecByS4Sbg908l+pKw5vze4dIs778aLMgQ2uM bUOnk862UV9p2TBDa4xt96vobBv1jdZRMfQcVhs+YI88E1oVBRzgZxoOWD4ThJuD7T8cdh/0Yy/v nSP9dLKt6hxWIzBCGISps2lVEniknYkAsJyNcNPYsfLvja/+LKcTadEP2trI0FPYF4EVjvVeZTat igIO0DMRAJazEW4OdvFCNEEPfum9U6RZP2n/JUNrDG3fU6foaJv0i5ZQM/QU9iVvhScOlFAtaVQU cPCiSR6w3BLhprFzUZE+63t8+b1TpFl/aOEtQ89hNQIj7HEtRZVNq6KA4whNBIDlbISbgx281kbQ z1957xBp1tcfrdNm6DmsRmCE8Bz0lNm0Kgo42NFEAFjORrhp7PqJC43waGYt7x0iLfpKa5kZeg6r EQzYJbNpVRRwjKSJALCcjXBzsH3HhwdBv7by3jnSqOPOzYaeww4akXmFQWePzKZVSeDBiiYCwHI2 wk1j7//Dn96vtFZifu8QadEPWt3L0Bpj22cpOttG/aSdtww9h9XkrXDFldRES1qVBB69ZZIHLLdE uGnsuXiiXdC3tbx3ijTrN61BZ2iNCdur6ML2io+a6YunpTXGtuGJT9LZNj6c+9FaZobWmLBdiy5s 1/g4Fn7JMLTGhO1edGEb9I3W+zK0xoTtVXRhe8XHgPC039BzWP1UGeFZ1qsOGBwe1lpZfazipwew /LEaHtZaeXjV1rMV7nBXsKiDMSoKOIrQHAtg4iCNCsL++/GEzzvcY9ylT2P7q37SDmiG1hjbhscX SWfbqN+0A5qhp7AveSvksWvYEqOSwCOWTPKA5ZYINwd7VpxKF/R7L++dIs36Q+uuGVpjwvYpurB9 4iNLuNM3tMbQdvutRUfbpK+0u5uhNSZs96IL2z0+DIIn4obWmLA9iy5sg37Qel+G1piwvYsubIN+ 0q5ihtYY24aRPkln26jftDiVoaew78M8YJv+lDcqCTzE2HyYAcufcuHmYNuOCyhF/SrvXUR6uZEW dRLbYKzwva/3fchsWpUEHo1mIgAsZyPcNLYcP7xee/UnflWoSIv+0G5yhtaYsD2LLmxf/VhovS9D a4xtl6fobBv1lTZqM7TG2HZdi862Ud9pTSxDT2HfeWaFaw1joNIJOFydWlmdaPF8AiyfaMPVqZXH V208jXAccTKyOJhWJYHHCZpjAUwdZKuicD04Jijo4fsl9QnaX/SDNpUztMbYNgxQTDrbRv2i9bsM PYf9aJzhHWay7bIlrYoCDi80yQOWWyLcNLb+bnysF/T7V947RFr0m3a+M7TGhO1RdGEb9IfW7zL0 HFaTN8J1rN/QzAFrVRRw6KRJHrDcEuHmYBv/bBn0+EvQwxvmFf1caEcNQ2tM2F5FF7ZBX2n9LkPP YTV5I9xbXA5KtKRVUcChkyZ5wHJLhJuDnTxNMujhr2B67xBp0Xfah8HQGhO2Z9GFbfo1hj4lLT2H 1eSNEFaO1C1pVRDE0EmTPGC5JcLNwR6eJhn0N4383iHSol+0kJahNSZsj6IL26DftNiUoeewmnwr PL+4cqRoiVFRwOGIJnnAckuEm8a2ladJBn3/lfc+Rlr0sBT3eLSG1piwPYoubIO+0GJThtYY2x53 0dk26ivtOmHoOaw23AjL737kmWBUFHAUpGk4YPlMEG4OdvDszFcPC/rm9w6RFh1/YzS0xoTtUXRh G/SDNtgz9BT2JW+EdQvbQaiWtCoJPArSJA9Ybolwc7CbZ2cG/brLe4dIi37RAk6G1hjbhguxpLNt 1G8aSmHoOawmb4TjCFuqqJa0Kgo4rtAkD1huiXDT2L7w7Mwn3Gz9ynuHSLN+/2gBJ0NrTNjuRRe2 QV9oEzpDT2Ff8lZ4jkUO9TQqCjhkzyQPWG6JcHOwjWdnBn37lfdOkWZ9o9FwhtaYsD2KLmyDvtMO HIaewxYalxiE/dYtaVQSeKCYSR6w3BLhprFjV5/J99zZy3vnSKN+0gJOhtaYsL2KLmyDftHwbUNr jG3DIL2ks23Ub1ptyNBzWG24Ec5tCcP0xJnQqijgGC7TcMDymSDcNHaG5WMo0lc/nvLeIdKsh7UQ 4LxtaY2x7bkXnW2jvtBqQ4aew2ryVrjSpHxuSauigGO4TPKA5ZYINwc7TvxxLOjhyUF67xRp1jfa CsPQGmPbbSk620Z9p9WGDK0xtt33orNt1HGlX0PPYbXhRrh+4VeRfCYMP6lYWXb86JbLyFju+PCT ipWHV209jfDe+C2rPJhWRQFHx5ljAUwdZKuicB+4dnbQ17v0Cdpf9ItWRjK0xtj2jSXrbBt1XOnX 0HNYTd4KR7zdEC1pVRJ45J9JHrDcEuGmsWvZccBP0MONXHrvFGnU99+PVkYytMbY9r2RyzrbRh1X +jX0HFaTt8KznnIwplFRwOGJJnnAckuEm4PtvGRH0K+nvHeKNOsbrYxkaI2x7b0XnW2jjiv9GnoO q8l/wvPXL6zJJ1rSqSjgkD+TPGC5JcLNwS5ajiTp213eex9po5/jykgdrTG2DVdMSWfbqMNKvx09 h9XkrZBbDC3pVBJopGCXPGC5JcJNY/ePliNJevzwXLR5YKM/48pIHa0xtr23orNt0BdY6bej57Ca vBHe818N3uxUFGAUZJc8YLklws3BNlqOJOphicz83iHSoq/j5oEdrTG2DRenSWfbqMOSux09hX3J W+FaD92SVkUBRnh2yQOWWyLcHOygJT6Sfh3lvVOkWd/H5Zc6WmNse/+KzrZRhyV3O1pjbPtsRWfb qF/jEkUdPYfVhhvhvJbwrFCcCa2KAoyC7BoOWD4ThJuD3bSySNKPpbx3iLTosORuR2tM2J5FF7Zx LM647E9Hz2E1eSOEg71kS1qVBBrh2SUPWG6JcNPYs9DKIknf9vLeIdKiw5K7Ha0xYfsUXdgGfRtn 6XT0HFaT74VjlS1pVRRg1GSXPGC5JcLNwfZTRvp+nPJ750ijDkvudrTG2Pb8FZ1to36Os3Q6eg6r yRsh342LlrQqCjBqsksesNwS4eZgF63ZkPTwA3l67xBp0WHJ3Y7WmLB9ii5sg/6M4/87eg6ryXdC fOYkWtKqJNCoyS55wHJLhJvEjt9vU5GGAdL5vWOkUd9gyd2O1hjbrr+is23U13GNmo6ew2ryVnhv 1X66JY2KAoya7JIHLLdEuDlYuBLHSJ8wvjW/d4o067DkbkdrjG3D5Meks+2TBsUMD9I6eg6rybfC sryX3o9qiVFRgFGTXfKA5ZYINwc7aTmFpG9nee9jpFU/xwVVOlpjbLv/is62Ub/HRUc6WmPCdiu6 sA06rH3b0XNYbXgvHKc6E4xKAg3W7BoOWD4ThJuDPbSKQ9LDc5f03jnSoO/LOIenozUmbPeiC9ug w9q3HT2H1eSN8L6BfZUtaVUUYERplzxguSXCTWPv68KD+6SH2+b03iHSom/jHJ6O1hjbnlvR2Tbq sJ5sR89hNXkjvNfZuxjk26kowIjSLnnAckuEm4PttPpG0uNZfNCmdY1+jnN4OlpjwvYpurANOqwn 29Fz2D6OSE1CHBrKLWlVFGBEaZc8YLklws3BLlrRIut3ee8cadSfcQ5PR2uMbZ9f0dk26AesJ9vR c1hNfsA2ryVVJYFGlHbJA5ZbItw0tv5oRYusX+W9i0iDvo5zeDpaY8L2KbqwfeJANRFSpSexbRiR +grv1VmYQiFa0qoowIjSLnnAckuEm4NttFpH0q+9vHeItOjHOIenozUmbJ+iC9ugn+PyBx09h9Xk jXDfPzXIt1NRgIGoXfKA5ZYINwc7aSWSpIcn7Om9Q6RFv8fJNB2tMWF7Fl3YBv0Zd5/raI2xbfg7 mnS2Dfq5jBNOOnoOqw03wrPERXzFmdCqJND4167hgOUzQbg52LPBSp1RD6si5/cOkRYdhpZ2tMbY dq0jVtk26vs44aSjp7Av+R7bdtmSVkUBxr92yQOWWyLcNLattBJJ1p/y3jnSqMO4yY7WGNvudTgm 20b9GkeZd/QcVpNvhfVNJy4Thy0xKgowSLdLHrDcEuHmYMeCH46gP0d572OkVYdxkx2tMbQN06ay jrZJf8YJJx09hX3J91jYnYVbYlQUYOBrlzxguSXCzcHuH344ov6U986RBp3GTXa0xth2rSNk2Tbq 67ixW0fPYTV5K5xxjKpqSaOCgMMlu+QByy0Rbhrbt1tEesZfmtJ7p0izjuMmDa0xtg3j05LOtlE/ xk3rOlpjaBsWwMs62iYdxxYaWmNsu1SdbaN+j7vPdfQU9p1nRngv5cPFhDgBWxUFHBxqzjPA8gko 3BzsvPgEevX3GzK/d4g06zy20NAaY9u9jiJl26gv4+5zHT2H1eStsL//TbakVUngwaEmecByS4Sb gz0nfzj2Pf7cn947RZp1HFtoaI0J27vowjbo+7j7XEdrDG23ZSk62iYdB8IZegr7Gm6FsN1mORO6 2Vi9LDv+nP03RcRyx/8pXjXL46s2nkZ4v/7CI0pxMK2KAo6fNccCmDrIViXhWGkBlKjHvxSpT9D+ ol/j7nMdrTG2jafHRRu7NToO2jP0FPYl32NhiRTRklZFAYfdmuQByy0Rbg520AIoSd9+5b1zpEF/ fuPucx2tMWG7Fl3YykF7hp7DavID5rXkU1HAYbcmecByS4Sbg920AErWn/LeRaRB38aNTzpaY2z7 XqtnnW2jjoP2DD2H1eSN8Jy/cI0hWtKqJPCwW5M8YLklwk1j50ILoCQ9jG1J7x0iLfo5bpXW0Rpj 2xj5SbuQNToO2jP0HFaT74VDjoQ2Kgo47NYkD1huiXBzsJ0WQMn6U947Rxr1e9wqraM1xrZhbEvS 2fZc1aA9Q89hNflW2NZfGpyOLTEqCjjs1iQPWG6JcHOwixZASfpRxzmOkVZ9GdcG6WiNCduj6ML2 UIP2DD2H1eStsIfLC9ESo5LAw25N8oDllgg3B3tuHO4d9PfeOL93ijTr+7g2SEdrjG3jqKmddrNq dBw9Z2iNsW3s9Em7WTX6NS4O0dFzWG24EcKTfX0mtCoKONrXNBywfCYIN41d64WjzOO0/Lu8d4i0 6Dh6ztAaY9utDspj26C/X2zwXMPQc1hNvhfevw6qJa2KAo72NckDllsi3BzsoDVlkn4s5b1zpFHH 0XOG1piw3YoubIO+jYtDdPQcVpM3wnsfHibpi5a0Kgk8kNUkD1huiXDT2L3Q6h5JD99H6b1DpEXH 0XOG1hjbnr+is23UT1ocwtAaY9trKzrbXnKEmaE1JmyPogvboD+0gIKh57B6ng2YPgFblQQeSm/O M8DyCSjcNPZ+DdLXZHssRrjO8NRIHWSrksBDks2xAKYOslVJuHdapyXp26/0FU6XrPPoOUNrTNju RRe2QV9pcQhDz2E1eSOEkVq6Ja2KAg5JNskDllsi3Bzs4nVagr4+5b1DpEXH0XOG1hjbxsg32rWs 0Q9aHMLQc1hN3gjP9t5HyZa0Kgk8JNkkD1huiXDT2PPjdVqCHsevHbQjW6PjMDZDa0zY1tFxwjbo F63SYOg5rCbfC8cmW9KqKOCQZJM8YLklws3BNl6nJep3ee8cadRxGJuhNca24dIk6Wwb9Pcejm7a W1pjwnYturBd1VAvQ89hteEDdnhnQlVRwJHQpuGA5TNBuDnYwcvDRL2OjhORBn2jVRoMrTG2vdai s23UcaiXoeewmnwr7Mu6/zbVEqOigAOoTfKA5ZYINwe7b/x2DfpSByyOkVb9pFUaDK0xtg0/cCWd baOOQ70MPYfV5K1wXmFZIm6JUUk4cQC1SR6w3BLhJrHzt1z47Rr05yzvnSLN+kOrNBhaY2gbvhiz jrZR33/jvmEdPYV9yfdYWFJdtaRRUcAB1CZ5wHJLhJvGlh+P1g16HH70o+3GGn2lVRoMrTFhuxZd 2K5qGJuh57CavBHW3xW2ixUtaVUUcHC5SR6w3BLh5mA7X3oE/d7Le4dIi37QKg2GnsNqBFYI+xLL bFoVBRyTbiIALGcj3BzsoS1ikh4uu9J7p0izjkP0DD2H1QiscIff4GQ2jYoCDpw3EQCWsxFuGnvv ZvmD/+pnHdVIkWb9pqUgDD2H1QiMsK1HXAo/ZjMMyLOyyiC+VcByBsOAPCsPr9p6GmHfjzCrTRxM q5LAo+3NsQCmDrJVUTj5+XfQw+Vv6hO0v+g4DtDQGhO2dVCssH31Y6FlKwytMbaNg+QW2vat0XGs nKHnsNpwI5zxV311JrQqCjg3wDQcsHwmCDcHe/hh7R4G6dT3DpEWfaNlKwytMWF7FF3YHmqsnKGn sC95K4RxtLIlrYoCTmAwyQOWWyLcNBbmSuGH4219GAuc3jtFmvWTlq0wtMbYNvx2m3S2jTqOlTP0 FPYlb4RrXc9LtqRVSeAJDCZ5wHJLhJuDHfywNuj3Vt47RFr0h5atMLTGhO1ddGF7q7Fyhp7DavJG uH/rccuWtCoKOO/BJA9Ybolwc7CbH9YG/arDCyHSoq+0bIWhNSZsn6IL20eNlTP0HFaTN8KzHtsi W9KqKOBcApM8YLklwk1j7503fzhePazPk947RFr0g5atMLTG2PZYi862UcexcoaewzaaMHH8fkf4 ZYVbYlQSeC6BSR6w3BLh5mAbPzUN+jfic4y06jetH2FojQnbp+jC9lGD1gw9h9XkrXAf74WSaIlR UcC5BCZ5wHJLhJuDnfzUNOhhCFt67xRp0q+F1o8wtMaE7Vl0YXuqQWuGnsNq8kZ4W3TesiWtigLO JTDJA5ZbItwc7Dn5w7GGYSblvUOkRd9p/QhDa4xtw41f0tk26jhozdAaQ9s7/LqQdLRN+nuOwMel paewr+FWeLaw/oQ4E1oVBZzCYBoOWD4ThJvG3tflz+T6pBGk8b1TpFnHoU6G1piwPYsubF/9/tEa C4aewr7kjbBdx7rKlrQqCGIKg0kesNwS4eZgx86fyVePI/F+tE1co+OAPENrjG33rehsG/V13O+t o+ewmrwR9vfy7JItaVUUcAqDSR6w3BLh5mD3hj+FBX3fy3uHSIuOg9YMrTFhexdd2Ab9oPUjDD2H 1eSNcD7XtcqWtCoKOM/CJA9Ybolw09h7o4mrrAT9/VuT3ztEWnQctGZojbHtU4cnsm3Ub1o/wtBz WE3eCG+Lwk8ioiWtSgLPszDJA5ZbItwcbOd1yoMefn1M7x0izToPWjO0xoTtU3RhG/SFFkcw9BxW k++EeKEkWtKqKOA8C5M8YLklws3BLl6nPOjhLiW9d4w06Th6zNAaE7Z30YVt0HdaHMHQc1hN3gjP FZ4dqJa0Kgo4PcMkD1huiXBzsIfXKQ/6Xt87RFp0HD1maI2xbXgGlHS2jfpFiyMYeg6rybdCGGmj Z8wYlQQenW+SByy3RLhp7Dp4deugh98v03sfI606jh4ztMbYNqw4nXS2ffXzvSaG57aG1hjbhjuD pLNt1HGElaE1JmyvogvboG+0gIChNYa2701F0dE26Tvd2Bp6CvtObyusv02e90YlgadcmdMbsHze CzcHW3lZ/6CHwRLpvVOkrU62VZ3DcH7RuWzh9w6VTauSwLNKTASA5WyEm4PdvCp70C8v0qKftCaD oTUmbO+iC9ugX/SswNBzWE3eCG+LwnxG0ZJWRQFnlZjkAcstEW4auxdelT3o77Vtfu8QadFvWpPB 0Bpj22cvOts+cRQmPSsw9BxWk7fCk77/uCWtSgJPRjHJA5ZbItwcbOdV2YN+XeW9U6RZX2hxBENr jG3vpehsG/WNnhUYeg6ryRvh2I4wU0y0pFVRwMkoJnnAckuEm4NdK3/NvepR3ztEWvSdFkcwtMaE 7Vl0YRv0k54VGHoOq8lb4Yq31aIlrYoCTkYxyQOWWyLcNPb8eCRy0O+9vHeKNOsXLY5gaI0J27vo wvaOw4DhWYGh57CafCekCRyiJY2KAk5GMckDllsi3Bxs+/HXXNDP8t4x0qivP5pSb2iNCdun6MI2 6Cs9KzD0JEYzbsIfpVW3pFVJ4MkoJnnAckuEm4MdD3/Nvfr7xZjfO0Ra9I0WfjC0xth2X4vOtlHf 8VlBS2uMbY+j6Gwb9ZMWEDD0HFYbboXj3C95JrQqCjiZxTQcsHwmCDcHu2/+dn31cyvvnSLN+oX3 XC2tMWF7F13YBv2hBQQMPYfV5HvhXnRLGhUFnPBhkgcst0S4SeyKD7ZEpPdV3jtHGvTthw8kWlpj bBsH+v54d7qqr7SAgKHnsJq8EcLTy122pFVJ4LkXJnnAckuEm4PtJ3+7hsfBS3nvEGnRN7x7bmmN Cduz6MI26AfN5Df0HFaTb4X36jSuSc8tMSoKOPfCJA9Ybolwc7DrwN/wgr7V9z5GWvWT7p4NrTG2 3Zeis23UL5rJb+g5rCZvhO29ZVxUS4xKAo/zNskDllsi3DT23p7g7wVBX+/y3iHSoj9092xojbHt e7uUdbYN+v6jmfyG1hjb7mfR2TbqK91hGlpjwvYpurAN+kaz3Q2tMbYNX4xJZ9uoH3QXZmiNCdut 6MI26CfNCDf0HFY/VQN2yo9bq5LAM6TMpwqw/HETbg724602gh4ebqX3zpF+OtlWdQ6rEVjhOuLM OpFNo5LA0yJMBIDlbISbgz28Zn3Qt9WLNOs33dgaWmPC9iy6sA36QxPRDT2H1eSNsC/xwV6ectLP prayjP5Z8FVz9MMcbSsPr9p6WuFppr+M2MPTW6qAUzjMsQAmD7JRSVhXXl8/6GksNG/gV/TjR3fD htYY24afOZLOtlFfaZM7Q2uMbe+z6Gwb9Y3uGA09h9WGG+Fc3r+X8kxoVRJ45ohpOGD5TBBuDrbz sv5Bf68P83uHSIt+0CZ3htaYsD2KLmyDftIdo6HnsJq8FZ4wo0C1pFVRwJkjJnnAckuEm4NdvKx/ 0MPvA+m9U6RZv2kDP0NrTNg+RRe2QX/wjrGl57CafCvc4SHCo1piVBRweotJHrDcEuGmse3Hy/rf eZRSeu9jpEU/F9rAz9AaQ9s4XCjpaJv0le4YDT2Ffcn32CJnHBmVBJ7eYpIHLLdEuDnYduIfrKjf 5b1zpFHfaQM/Q2uMbcPD8aSzbdQPugQ29BxWk7fCtYaV61RLGhUFnN5ikgcst0S4Odh54B+soIch fOm9U6RZP2mXQUNrDG238DtZ0tE26TfNmjb0FPYlb4SwhM4qW9KqKOD0FpM8YLklws3Bnh3/YAU9 /GVJ7x0iLfpDO/cZWmNsG5ZsSTrbBv1a6E7f0HNYTb4T3txlS1oVBZzeYpIHLLdEuGlsX3nLgqAv a3nvGGnSV9q5z9AaE7ZH0YVt0He61TO0xoTtVXRhG/SDdrcz9BxWG26FZw9L96gzoVFJ4LkYpuGA 5TNBuDnYvfC366uvW3nvFGnWL7rnMrTGhO1VdGEbh4PS7naG1hjbhp8lks62UX/ovsTQGhO2W9GF bRwySTvAGXoOq+eZEY4tTosVJ2CrgiCmOZjzDLB8Ago3jR3bw99AYUTbU947RFr0Fe9LWlpjbLvv RWfbqO+0A5yhNca2YXR00tk26gdeu7e0xoTtU3RhG/SLNlcz9BxWzzMrXMfy1Akz/TNQK6sTLZ5P gOUTbXiyauXxVRtPI4RJbj95MK2KAk6uMccCmDrIVkXh5CV6g75cpU/Q/qLfeJ/R0hpj23ACJJ1t g/78aCM4Q89hOIMoTNsKg2xES1oVBZw/YJIHLLdEuGnsvU3G3w+D/tzlvUOkRV/wPqOlNYa2capn 0tE26SttBGdojbHtchadbaO+47V4S2tM2D5FF7ZBP2izNENPYd951mOrPgFbFQWcwWTOM8DyCSjc NHY8NNjdHEsrvN9j78WQOkijksAzQcyxACYO0qgknAfvDvDq8WYn9XU8Xap+0QW/oTXGtuFniaSz bdRv2uTO0FPYl3yPhdEl3BKjooAzQUzygOWWCDcHu3l3gKg/5b1zpK9+/X409dHQGmPbfS0620Z9 oY3gDD2H1eSNsC9XmEwoWtKqKOBMEJM8YLklwk1j17LiEOegP3t57xBp0Te6mTG0xoTtU3RhG/Sd NoIztMbQNjzlyTraJv2kiZ6GnsK+hlvhuMNjPHEmtCoJPAHFNBywfCYINwc7eX7nqz/Lr7x3ijTr F20EZ2iNCduj6MI26DfdIBh6CvuS77EwUlG1pFFRwAkoJnnAckuEm8bC0Hv88/zqcfzvzRvBFX35 0UZwhtaYsL2KLmyDvtANgqHnsJq8EY73z8MuW9KqKOBMEJM8YLklwk1jT1jTnSJ99X0p7x0iLfpG u9UZWmPC9iy6sA36jpeVLa0xtj2eorNt1E/a0c3Qc1htuBW2c69nwvDMxsqq47GxgOWOD89srDy+ auNphHP7xbldfDCtSgJPljHHApg6yFZFIVwYUfvjcZQ+QfuLftGNmqE1JmzPogvboD+0+5yh57Ca fC+EHyJFS1oVBZwsY5IHLLdEuDlYmF0tIn2O8t450qCvP7yZaWmNCdur6MI26Is6bys9h9XkjXCv 1yPnLxkVBZwsY5IHLLdEuEns/fvA2/m8+v27y3uHSIu+4c1MS2uMbcN1eNLZNuo7nrctPYV9yRvh ecLuBqolrYoCTpYxyQOWWyLcHGw/+OHJqz9nee8QadFPvKtoaY2h7RYeFycdbZN+4Xnb0hpj22Uv OttG/aEZlIaewr6GD9gpz4RWJYHnH5mGA5bPBOHmYNfOz2xePTxkTO+dIw162D8Zz9uP1piw3Ysu bIO+0gxKQ89hNfkirL/fX78wxn+llgwqCji3yiQPWG6JcNPYeys1PLMp+vmU9/5PrW/9CTTQGmPb ays620Z972dQDvQcVpPvhTBtYGzJoKIwTAQakgcst0S4Odi2DsPSiv6s5b1zpFE/1QlUaY0J26Po wjboVz8lbKDnsLuf7RSFLX3tipa0Kgnj5JohecByS4Sbg4XtZinSLf0dTe8dIi36gydQS2sMbePf 0aSjbdT3X7+h2EBPYV/yPRY28hUtaVUUhhlAQ/KA5ZYINwd7fsPQg6o/5b1zpFFfxQn00Rpj2zgc aR03FDP61s98Heg5rCZvhGNZH92SVkVhmDcyJA9Ybolw09i6X8OTgaxvYV5veu8QadEPPIFaWmPC 9iy6sA362U99HGiNse36FJ1to36LkD9aY2y7rUVn26g//Ty9gZ7CvvNswPQJ2KooDDPXhvMMsHwC CjcHW/qdvYZjMULYpfCRB9mqJIwzgIZjAUwdZKuicI07JBV9O0tf4XTJ+vFTtpXWGNvuv6KzbdTX fg7iQGuMbd+PU9bZNuobnkAtPYfVhg/YKc+EVkVhmHg0NBywfCYIN41tv3FjpqKfS3nvHGnUj34O 4kBrTNjuRRe2QT/Vu630HFaTN8J7p3bqlrQqCsPEoyF5wHJLhJuDbePGTEW/t/LeIdKiv1fj8FXQ 0hoTtnfRhW3QH/VuKz2H1eQ74eK5YINKwjjxaEgesNwS4eZg57gxU9XP8t4x0qi/l+IbfF+1tMaE 7VN0YRv0Vb7bQk9iSzdxKQlPHDyuWtKoKAzzlYbkAcstEW4O9owbMxV9u8t7p0izvvVzEAdaY2y7 b0Vn26gf6t1Weg6rybdCGMLwvpBoiVFRGOYrDckDllsi3DS2r+PGTEV/rxryex8jrfrZz0EcaI2x 7fErOttG/VbvttJzWE3eCMtyhBUpuCVGRWGYizUkD1huiXBzsGPcmKnoYbRHeu8QadGffjLgQGtM 2J5FF7ZnGKim3m2l57CavBHeu6iwJo5oSauSMM7FGpIHLLdEuDnYNW7MVPR7L+8dIi362u96NtAa E7ZP0YVt0Hf1biutMbS9f2vR0TbpRz8ZcKCnsK/hRtiWLcz1F2dCq6IwTG8bGg5YPhOEm8bCLs3Y yW3Zw7oL6b1DpEU/he1Ha0zY3kUXtkG/+53BBnoK+5I3wrHEPTJFS1oVhWHK2JA8YLklws3BtnGv q6KHwVnpvUOkRX+UbaU1JmzvogvbMEBy6ScPDvQcVpO3wnGEPZRES1qVhHES1ZA8YLklws3BnnGD 6qLvV3nvFGnWV2VbaY2x7bEUnW2jvveTBwdaY2wbHlgknW1PHEg70BoTtlfRhW3Qr35a1kDPYfU8 G7BHn4CNisIw1XE4zwDLJ6Bwc7BTRxp+d0/vnSP9dLKt6hxWIzDCeR1xhiNn06ooDDPVhggAy9kI N42997f4kDDo4UcLGWnRb+xkS2tM2F5FF7ZBf/ppCgM9h9XkjXAdZ/i2Fy1pVRBgptqQPGC5JcLN wY5xh/Oih7+j6b1DpFl/FmVbaY0J27vowjboaz9ncaDnsJq8Ee4tzJNRLWlVFIaZakPygOWWCDcH u8cdzoseJu+k9w6RFn1XtpXWmLC9iy5sg370cxYHeg6ryRvhOeJP1qIlrYrCMJ1uSB6w3BLhprH3 /hYfEgY9nKfpvUOkRb+UbaU1xrbh2zfpbBv1u588ONAaY9vwoC3pbPvq4Xdz+oPZ0nNYbXgrrOu1 36c6E4yKwjCLb2g4YPlMEG4Oto8bq2f9+G3lvY+RVn3pJw8OtMaE7VV0YRv0rd8ZbKCnsC95I2zL Ge71uSVGJWGcMjYkD1huiXDT2HtNgs8mgx6uldN7h0iLvveTBwdaY8L2KLqwDfrRbyg20Bpj2/fP d9bZNupXvzPYQGuMbY+l6Gwb9buftDbQc1g9zwZMn4CtisIw+3Q4zwDLJ6Bw01j43sVvoKBf5b2L SC830qJOYls3jTQJ7w0nzswdVBSGmXFDBIDlbISbxJ73+0+cpUeYCOBEmvTl12+2NtAaE7Z30YVt 0Jd+HuBAa4xt97XobBv1rd+QbKDnsNpwKzxruK9QZ0KjkjBOyBsaDlg+E4Sbg+3jbixFf5uQ3ztF mvW9nwc40BoTtk/RhW0c9txvSDbQc9jeT+iLwnuj8c0TNJOlR1lGv3fjjTKWo/+neNUsD6/aehrh PI57lQfTqigMkweHYwFMHWSronBt+JNK0J+79AnaX/Srn7M40BpD2zNcqyYdbZN+95unDfQU9iVv hTvsK6Za0qooXP2cwyF5wHJLhJvG3u9q/Ekl6OGOKr13ijTp66+fPDjQGhO2T9GFbRqhC484DT2H 1eSNcB1rmHEkWtKqJIxzDofkAcstEW4Oto1rPGc9fAfk9w6RFn2jyYOG1hjbhovQpLNt1Pd+P7mB 1hjbrmfR2TbqJ02wM/QU9jXcCM+yhzNLnAmtigJOdTQNByyfCcLNwc5xaemi73t57xBp0a9+h7aB 1piwvYsubIP+0AQ7Q89hNflWeP/h0C0xKgo41dEkD1huiXBzsHtcNrvoMfJn3Nit1bdfv0PbQGtM 2D5FF7ZBX2iCnaHnsJp8J1xh4QxuiVFRwKmOJnnAckuEm8bC1y59OF49bFWS3ztGmvSt3yxtoDUm bO+iC9ug7zTBztBT2Je8FZ4wtF+2pFFJ4AlyJnnAckuEm4Nd4+LMRb+28t4p0qyf/WZpA60xYXsX XdgG/aJpWYbWGNuG9UWSzrZRf/oNxQZaY8J2K7qwffX9RxPsDD2HHTTn8T3910ufgK1KAk8iM+cZ YPkEFG4aez+sHOmrf+8dIi362m8oNtAaE7Z30YVt0Dd6nGJojaFt/FEn6Wib9KPfdGugNSZst6IL 26CfdBtv6CnsO8+scMWNSPN0xP7Bh5XViRbPJ8DyiTY8TrHy+KqNpxHCiK9dHkyrooBzEM2xAKYO slVROMelpYt+LaVP0P6iX/0GYQOtMWF7FF3YBv2hRw6GnsNq8kY4wxhb2ZJWRQHnIJrkAcstEW4O 9oxLSxc9/JSY3jtEmvX3hITHsYbWGNs+v6KzbdRXeuRgaI2h7f3bi462Sd/6TbQGegr7Gm6E6728 XuWZ0Koo4NRH03DA8pkg3DT2/mXiz2T4weEu7x0iLfpB9/6G1hjbhr8USWfbqJ/9Tl8DPYV9yRvh vn/rT7akVUngCXMmecByS4Sbg13jRktF367y3iHSot9479/SGmPb8GNY0tk26k+/QdhAa4xtj6Po bBv084f3xy2tMWF7FV3YxiGU/U5fAz2H1fOsF059ArYqCjhl15xngOUTULg52EGDocyxtMK+nGuY psUHaVQUcOqjORbAxEEalYTwl4wutPYwQuZX+jqeLlXf6N7f0BoTtkfRhW3Qj37zs4Gewr7ke2y5 VUuMSgJPfTTJA5ZbItwcbBtX6y76upX3zpFG/aRpVobWmLA9iy5sg373O7QN9BxWkzfCmtb5Fi1p VRRwxqRJHrDcEuHmYOe4AnbR91957xBp0R96rmFojQnbo+jC9gjjNPtdzwZ6DqvJG2H/rXG7DW5J q6KAMyZN8oDllgg3B3vGFbCLHlaaSu8dIi36SrNkDK0xYfsUXdgGfes3SxvoOawm3wmbnsRqVBRw xqRJHrDcEuGmsfcvGS5TFPRtLe8dI036Qc9BDK0xtg2f2aSzbdTPfke3gdaYsD2LLmyDftOzAkPP YbXhRjjO33HLM6FVSeCJmqbhgOUzQbg52DEuvF308AwovXeItOhPv+vZQGuMbe9f0dk26PdCN+2G nsNq8kY4f+upW9KqKOAkVJM8YLklws3B7gV/yQn62/v83iHSoq/9rmcDrTFh+xRd2AZ9p5t2Q89h NXkjXOdv+8mWtCoKOGPSJA9Ybolw09j7B5S/5l59v8p7h0iLfvSbpQ20xtg2jJhPOttG/cJbvZae w2ryrRB2xgk7ynFLjEoCz7MzyQOWWyLcHOzkgfivHn9OSu99jLTqd79Z2kBrTNgeRRe2QX/ogYSh Nca2YVR50tk26M/Sbyg20Bpj220pOttGfaUbW0NPYd95NmByoqdRUcCZvuY8AyyfgMLNwTZaDN8c yyBczkF+KghiMqA5FsC8g7wc7P2TIj8c4QFp6iufLlHf+83SBlpjwvYourAN+kE37YbWmLC9ii5s g371u54NtMaE7VN0YRv0m25sDT2H1fPMCnscw5BOwOF3ciurEy2eT4DlE234ndzK46s2nkZYrvjd Lg6mVVHAaZrmWABTB9mqKBy8SHjQw+z71Cdof9Kf349m9BhaY2z7fmVnnW2jvtBNuKHnsJp8L4RR mKIlrYoCzu40yQOWWyLcHOze+Wvr1Y9fee8cadSHTf4GWmPCdiu6sA36TnfDhtaYsD2KLmyDPmyE N9BzWG24EbZzOS95JrQqCjhP1zQcsHwmCDeNPStPJQx6+L0hvXeItOgX3Q0beg6rEXTCvulsWhUF nPlqIgAsZyPcHOzinR+CHs/ia9wszejDJn8DPYdtNCs4YreTzaeSwBNmTQSA5WyEm8SW9+8m/ywe Cq765jnToC8/utU39BxWMzDCsca5PCKcVkUB59faDIAr6Qg/F9w3/M0oFIRfNtL7h1iLPuxiONAa E7ZP0YVt0De83W/pOaym3wt62rNRUcA5tjZ64EpThJ8LXiv+bhQLrvL+OdaoD1sKDrTG2DZcLCSd baN+4I1iS89hNX0jnOGaTbalVVHAuas2euBKU4SfB77/xxc7YQ7mVd4/xFp03FbQ0Bpj22MtOttG /cZHGi09h9X0jXCHhcVkW1qVBJ6/aqMHrjRF+Lng9sMfckLBdpX3D7FmfcWtBQ2tMbZ9T9yss23U F9rizdBzWE3fCvsafnYSbWlVFHDqq40euNIU4eeCx4M/5oSCZynvn2LNOm4vaGiNCduz6MI26Ds+ LmhpjaHt9hJZR9uk4xZ8hp7CvqZb4XrCIDF1NjQqCjjr1nYcuHIuCD8XvPnn8lCwXOX9U6xZv/CR QUtrjG3XtehsG3Xchs/Qc1hN3whP/MlHtaVVSeCZtzZ64EpThJ8Hhg8tfjbfgv0s7x9izfr2w/v3 ltYY215r0dk26riBm6HnsJp+K7zH6rTFqCjg7FsbPXClKcLPBXf+2TwUhKuk9P7HWKu+0U5xhtYY 24arpKSzbdRxq0FDz2E1fSOscUU+0RajooAzcG30wJWmCD8XvPin81Cw1/cPsRb9pN3iDK0xYXsW XdgGHffGM/QcVtO3wnvVu8q2tCoKOMPYRg9caYrw88D3SwkvR0LB/pT3T7Fm/b2VhS+hltYY24bn b0ln26DvuD+eoeewmr4R3ou4VU78NioJPMvYRg9caYrwc8GNhweEgnAHk94/xFr0lXaNM7TG2HZf i862Ucc98gw9h9X0jRDGFd6yLa2KAs6ittEDV5oi/Fzw5J/RQ0GYJ5reP8Ra9J12jjO0xoTtU3Rh G3TcJ8/Qc1hN3wjnHqeWiba0Kgo4O9lGD1xpivBzwYeHCYSCGPvJu8dV/aLd4wytMWF7F13YBh33 yjO0xtg2XPMmnW2DfvxohzVDz2G16VYIGwfIs6FVSeCJ0bbjwJVzQfh54PtdyFdB53uMZ3n/FGvW cb88Q2uMbcN0v6SzbdQ32mXN0FPYl74R3v/cfrItrYoCzuC20QNXmiL8XHDnX/5DQbiDSe8fYi06 7plnaI2x7bEUnW2jftJ2cIaew2r6RgjPshfZllZFAWdx2+iBK00Rfi543XwVdMdb8fz+Idai4wZ2 htYY24arpKSzbdQf2hLO0HNYTd8KdxzLLtrSqijgBHAbPXClKcLPA8N3IX7l3eHRSnn/FGvST9zE ztAaY9vlV3S2jfpK28IZegr70m+F6/dL8/qxLUYlgWeq2+iBK00Rfi648Y/koSBcJaX3P8ZaddzI ztAaE7Z30YVtmgADnxZDz2E1fSOE78RTtcWoKOCMbhs9cKUpws8FT/6RPBSsW3n/EGvRcS8yQ2tM 2F5FF7ZBv2mfNkPPYTV9K+zHtsm2tCoKOKvbRg9caYrwc8GHfyQPBcevvH+KNeu4WZ+hNSZs96IL 2zAP4Ud7tRl6DqvpW+H9UvzptjQqCTyz20YPXGmK8PPA92sCfyQPBWEJy/T+Kdas4+5yhtYY2m7v pznraJv0jfZrM7TG2HbZi862Uccd2Aw9hX1NN8J2PL9Tng2tigJOKrcdB66cC8LPBQ/+bT4UhG/i 9P4h1qKftGeboTUmbK+iC9ug4y5shp7DavpG2Pc1LHQm2tKqKOB8dBs9cKUpws8Fbx7D+xaEPyr5 /UOsRX9ouzdDa4xtw/SBpLNtnF6AW6IZegr70jfCccafkkRbWhUFnJNuoweuNEX4eeAVxsBSrG9B uDFM7x9iLfpKW74ZWmPC9iy6sA06botm6Dmspm+EsP7VJtvSqiTwvHQbPXClKcLPBbcbx4KHgv1X 3j/EWvSDtn0ztMaE7V50YRv0k6aDGHoOq+kb4VnDOlGqLa2KAs5Nt9EDV5oi/FzwvHAI+lsQL1fS +4dYi37TlBBDa0zYHkUXtkF/aNqEoaewL/0eCwu6i7a0Kgk8Y9tGD1xpivDzwPdLiS9HnjTyP71/ jjXoz0IzJwytMWF7FV3Yypk+htaYsH2KLmyDvtPMAkNrjG3DhMeks23UD9qrzNBzWD3XrHDGZzfq JGxUFHAetz3RgCunoPBzwWPni6+3IIzESO+fYs36RTMLDK0xYXsXXdgG/aY9wAw9h9X0W+EOz8bq PPhhLraVdfhH9wN+5kr4w2zsTu9f2NgaYVnDwpfieIyKAk6rtwcDnDxMI7MSNmOAsyAUhOXeU7vG s6DqD02EMLTG2PZeis624Z2EuWVwFWdwh2PjZ68F7JwKVposYPlJsLbeCFvYolKeE60Kgpgrb/sO XDkjhJ8Hvn+u8EI1FMSfnlIAEG0t2GkLM8s7oLA+a4GwjgUHjd63/CRYu2CF97+tsj2tigLOm7ct AK40R/i54M7jGULBfdcAKNpScNGea5Z3QLYO14G5gK1TwU2j+C0/CdYudEJ8jqLa06go4ER/2wLg SnOEnwtePK4hFCxrDQCjTQWhhK0/3gGF9V4LhHUsWGg0v+UnwdoFI+x3nP4k2tOqKODEeNsC4Epz hJ8LPjy+4S0ImxeXACDaWrDSXmyWd0C2Tm1feaezr2CnUf2WnwO/LhghPCI6ZXtalQSeem5bAFxp jvBzwCUsqIh/3MJzt60GANHWgoP2ZbO8AwrrqxYI61hw0eh+y0+CtQtGuH/r9cj2tCoKOAXdtgC4 0hzh54IHj3cIBc9ZA4Boa8FNW7tZ3gHResvT1Hh3t1qw/miUv+XnwK8LVtiP7ZTtaVUUcCq6bQFw pTnCzwVvHvcQCgKSA6BoS8FCe9FZ3gGF9VULhHUs2Gi0v+UdkK2vpRawdSrYabs3y0+C9QQYuE2f GY1KAs+Gt90HrpwXws8D37+4OPQiFjw1ABFtLDhp1L/lHZCt4710KmDrVHDR/nSWnwRrF4zw/um8 FtmeVkUBZ8XbFgBXmiP8XHDnIRih4L5qABBtLbhpGL7lHZCtn7UWsPWTJmPR/m+WnwRrF1rh+e1p LQlsj1FRwGn8tgXAleYIPw9cf7wJVyg49hrAGO1XsNBwfMs7oLC+a4GwTnOraAs5y0+CtQtWuMMP naI9RkUBFx+wLQCuNEf4ueDO38ChIK7BkwKgaEvBTsPyLT8J1iiMsLwv9JMZtSoKuFKCzQG4kpDw c8GbJ3WEgvhllQKAaGvBiV01/CRYo7DCm5pcTcKoJPAiCzYH4EpCws8D35MKn3OHgvOpAVC0peCi 6QeWnwRrFEZYwwpfMqNWRQFXhLA5AFcSEn4uePGGR6Fg3WsAEG0teGhrQMtPgjUKK+zvjZfMqFVR wMUkbA7AlYSEnwfuCz/qCAXrrwZA0eaC/UfTLCzvgMJ6rwXCOhYstAWi5SfB2gUrxNtr2Z5GRQEX 3bAtAK40R/i5oJicHQri0/YUAEVbCjaabmH5SbBGYYTzd783miqjVkUB1+uwOQBXEhJ+Hnj8TryR CAXxl+8UAERbC3baEtHyk2CNwgr7vcg1TYyKAi4uYnMAriQk/Fxw520rQsF61wAo2lJw0rQSy0+C NYpeCFsiqIwalQRe6cPmAFxJSPh54Lmd+BNQKNifGgBHmwou2v7R8g7I1uGCIRewdSp4aHqJ5SfB 2gUr3Hv4WUq1p1FRwDUQbAuAK80Rfh54H7yobyiIozhTABRtLng/jPBLjuUdUFjftUBYx4KV5ntY 3gHZOny8cwFbp4KNtk20vAMK670WCOtYsNO8CMs7oLA+a4GwTrPjaItBy0+C9bQ3wv1b0n7JcXGP fqCXleVZH89t4MpZPwwg6/ThhVvbT1j+Cot/hqdhdDydSgIv6mEPBjg+zF5m5abFn1NBvNNO/erP hLbgGqdz9LwDsnV84JgK2DoVPOMWjj0/CdYuWOH6hRG01J5ORQEW9+hbAFxpjvDzwGehRaBTQbjU zgFQtLng/I3TOnreAdn6+NUCtk4F67idY89PgrULnbA+t25Po6IAy0L0LQCuNEf4ueBJ39qxIOzU VgLAaHPBNk7v6HkHFNZPLRDWseAYt3bseQdk67i6XCpg61RwjtMget4BhfVeC4R1LLjHbRB73gGF 9VULhHUseMal9Xp+DvxOeyOs79sQy6R0Kgm0Hkd/zgNXPg3CzwUf8XfnLYi/nKYAINpScP3GO6ee d0C2TnNrfrSZYluwjtMien4SrF2wwh7m8Kr2tCoKsC5H3wLgSnOEnwOuv1X83QlPxpYaAEVbCrZx 68eed0BhfdYCYR0LjvEBUs/PgV8XrHBfV102pLua7mXVhBQ1cKUJ/xSvW/TxhRtbI+xLuMxQx9Oq KMByIv3BACcP08isHOLP5FsQV1tM/YIzoRac44aQPe+AbB1/jUwFbJ0K7nGmQs9PgrULVnjeHsj2 tCoJtKxI3wLgSnOEnwve4jLgLYi30ykAirYUPOMvKj3vgML6qQXCOhTcyzhToecnwdoFI5z3dYtV XzoVBViVpG8BcKU5ws8Dl4XWg44F6Ws9BQDR1oJ13CGy5x1QWJ+1QFjHgm38Ybnn58CvC0a41uv+ yfa0KgqwOknfAuBKc4SfC+60LnQqCN8nOQCIthYc4yaTPe+AaJ3bftA+k23BOc5U6Pk58OuCFc7r 2mV7WhUFWKWkbwFwpTnCzwUv+gkyFcTVP1IAFG0puMedI3veAYX1UQuEdSx4xpkKPT8J1i4Y4d6v 65DtaVUSaLWSvgXAleYIPw98/wcMzUoF8TFdCgCiLQXPMm602PMOKKzPWiCsY8E6zlToeQdE6zhG LxegdS7Yxw0Je34O/E6AVlh+v7j1D58ZRkUBFkzpuw9cOS+EnwtutGZ0KohPVVIAY7RfwTHOVOh5 BxTWTy0Q1rHgHDcm7PlJsHbBCsd7B6TaY1QUYOGUvgXAleYIPxc8aJhhLNjCmJccAEVbCu5xukDP O6CwvmuBsI4Fz7hBYc/PgV8XjLD+4t960Z5WJYEWUOlbAFxpjvBzwZvWkE4F6Xvyoa0Nv4Kw0R48 Uba8A6J1vJzKBWidC9Zxo8KenwO/Llhhv+5HtqdVUYCFYvoWAFeaI/w8cFtoLelYcIcnhTkAirYU 7ON0gZ53QLZefrWArVPBMe5z2PNz4NcFI+xhYJZsT6uiAAvG9C0ArjRH+LngzpcsoeB4agAQbS2A Dbx73gHZ+txrAVungnscTt/zk2DtghWOX1xUitvTqijASix9C4ArzRF+LniJS5a3YF9qABRtLnj/ 6sNzWcs7oLA+aoGwjgXLONy85yfB2gUr3PFuS7WnUUHgVWP6HhCYuyMMPXD/iWuWPezkWROgbEvB Oo4373kHFNZHLRDWsWAfB0X3/CT4tcEo4RnUqRtkZFZg5Zi+DQTmBilHD9zEdUt4uLfWECDeWnCM A6N73gGF9VULhHUsuMaBwz3vgGwdhv7nArZOBfc4JLLn58DmDDDKtZ77rc8NI7MCC9f0ZwCB+dxQ jh54isumKy32mUOAeEvB+z/oFsDwDsjWaWJVLGDrVLCMg2t7fhL82mCVK6zmKhtkZFRo8Zq+DQTm BilHD3zEpdNbcJw1BIq3FGzjJok974BsHS5qcwFbp4J9XBGv5yfBrw2tsi55DzNukJVZgQVs+jYQ mBukHB3wWPnyKRSE65AcwhjvV3CMGyb2vAMK67sWCOtYcI0L1PX8JPi1wSjrEk8S0SArswKL2PRt IDA3SDl64M5XUKEgXIfkECDeWnDTyGPLOyBbh0nquYCtY8H2Gxep6/lJ8GtDr5yXbpCRUaG1Uvo2 EJgbpBwd8PzRpJlUENepSCFwvKlgodHHlndAYX3WAmEdC7Zxobqed0BhfdcCYR0Ldhqda3kHZOvw +CsXsHUqOMeF3Hp+EvxOPqvEfQP1adnKrMAqMf3JR2A+LZWjB260ZHcqOO8aAsVbCq5xl8Sed0C2 vtZawNap4B4Xc+v5SfBrg1XO92NZGzSMuOt03Yetu9QqYO7DMOSu08cXbn2Nch3brhYe6mVWYG2b /oAIVIdqZFZOWoI7FcQ7jdQ2OCFKwXvTDRfZlndAto53GqmArVMBzMvu+Unwa4NV7l9adIsbZGRU Nlgaom8DgblBytEB3w8i//14C8IXUw6B4i0FGw1gtrwDsvWz1QK2TgX7uAxdzzsgWi9xPlsqQOtc 8N4VYuAN74DC+qkFwjoWXONaaT3vgGy9LLWArVPBQyNKLe+AwnqrBcI6zpb+jYvo9LwDCuujFgjr WLDQiEvLz4HNp30Ab+d7oJVZgQWy+k87gfl7QDk64PnQAvmpYF1rCBxvU0DWnzwJflkY5V6eOI9N pGRkVGi5jD4LAnNKytEB3yPBodGhIFx56nhrwTYu19bzDsjW8VotFbB1KthpUKvlHZCt4zSVVMDW qeActzXseQcU1lctENax4KJBn5afBL+Tzypn/CFVnZZGZgUW0uhPPgLzaakcPXCjFYxSwb3UECje UvCMWxz2vAMK66MWCOtQEG7W+F1//CT4tcEoz+8XxvDlBo13NVbXfdj6i68M5j6MdzVWH17Y+LbK Fm6eT3lEVmYFlv/oD4hAcahWZuXkq8BQEBdHS20bT4ivYB03aOx5BxTWVy0Q1rFgozGjlp8EvzZY Zbu3RTbIyqjQ2iF9GwjMDVKOHvjwlW4o2L8QKN5ScIybNfa8A7J1av1B2yC2BSeNG7X8JPi1wSrv 98TPaVArswLro/RtIDA3SDk64LPy1XwoWK4aAsVbCq5x48aed0C2jotspQK2TgUPjR21/CT4tcEo 7+kZt1sQDTIyK7joiG0DgblBytEDD77cfAvuMGA3hwDxloLrN27i2PMOyNZxja9UwNapYKXxo5af A5s2WOU+4orGokFGRoUXHrFtIDA3SDl64M2X1KEgPmhLIVC8pWAb94HseQcU1kctENax4KAxpJZ3 QLa+71rA1qngHDd27PlJ8DsDjBJ+aPnpc8PIrOC6J/YMIDCfG8pRg9tv4av5UBDvplIIEG8tuGkc qeUdkK3jML1UwNap4Bk3eez5SfBrg1Heb9u4DJtokJFZwbVdbBsIzA1Sjh64i2vjtyDM2c4hQLyl 4L39pOtGwzugsH5qgbCOBeu472LPT4JfG4xy5UFyokFGZgWXobFtIDA3SDl64CWuja88CjKFAPHW go0Gk1reAYX1VQuEdSw4xs0Xe34ObNpglHtdr1s3yMio8FI0tg0E5gYpRw98xLXxWxCHD6cQIN5a cNKITss7oLB+aoGwTsu8jRsw9vwk+LWhU9KWbKJBRmYFl6OxbSAwN0g5OuB7M8bXxqHgqiFgvLng oRGdlndAto7Dh1MBW8eCZxk3Yez5SfBrQ6vsvzXtyckNsjIruMaLbQOBuUHK0QMPvjZ+C7awW2oO YYz3K1hpRKflHVBYP7VAWMeCbdyIsefnwKYNVjnX+D3NDbIyKrzOi20DgblBytED7xPHTLwFW/xr mEKgeEvBQSM6Le+AwvqqBcI6FpzjZow974BsnT7UJ23G2BbcNNrR8nNgcwYYJWx3cOtzw8is4DIz 9gwgMJ8bytEB1/BDN8Ub5m3uNQSItxY844aMPe+AwvqpBcI6jJz5LeO+ij0/CX5tMMp+/uJq5qJB RmYFl5qxbSAwN0g5euBOe76ngvMLAeKtBeu4KWPPOyBbx1leqYCtU8FOIzotPwl+bTDK8V6U7bpB RmYFl5uxbSAwN0g5euBF+76ngvgLbwoB4q0Fx7h/ZM87oLA+aoGwjgUXjY+0/CT4taFXzls3yMio 8Komtg0E5gYpRwfcNtolPBWk0/uizSfbgnvcQ7LnHVBYX7VAWMeCh8ZHWt4BhfVTC4R1KAjDnrlT H++AbB2uCnIBW6eClUYdWX4S/E4+q+zxM1jWzOl/5O90efbFc4zAfPYNowc6fXzh1tco132cenkg K7OCK9DYAyJQHaqRWTloR/dUkJZpW2lLybZgH3eG7HkHFNZHLRDWseAYd07s+Unwa4NR7vdObNUN MjIpYhUa2wYCc4OUowfe4kbiLYjjsFMIEG8tuMbdE3veAdk6PBLKBWydCm4aOmr5SfBrQ6/EcYKi QUZmBVeisW0gMDdIOTrge47xjURYY22tIXC8sWD9jTsM9rwDCuujFgjrWLCMW/f1vAMK66sWCOtY sI478PX8JPidAa0SVu2IIx743LAyK7gQjj0DCMznhnL0wJ3vYUJBWDk6hzDG+xXsNH7T8g7I1vta C9g6FRzjLnU9Pwl+beiV45ANsjIqvBiObQOBuUHK0QMvvocJBeFaLYfA8aaCi0ZDWt4BhfVWC4R1 LLjHLeB6fhL82mCUsPvRpRtkZFZwPRzbBgJzg5SjAx4/vocJBccXAsRbCrYfjYa0vAMK67sWCOtY sIzbwPX8JPi1oVfiBGfRICOzguvh2DYQmBukHD1w4/u0I/xpXmsIGG8u2Gg0pOUdUFjftUBYx4J9 3Oqu5+fApg1G2fZt2XWDjMwKLt1j20BgbpBy9MCT73pCQRxumkKAeGvBQaMhLe+AwvqoBcI6Flzj rnw9Pwl+bbDKnQaUiAYZGRVeuse2gcDcIOXogQ/f9YSC86whULyl4KbRkJZ3QLaOI9BSAVvHgv1H W91ZfhL82mCUY48rpqsGGZkVXLrHtoHA3CDl6IDnync9b0HcLiGHAPHWgoWGJFreAdk6zEnNBWyd Cjba7s7yDsjWcVXCVMDWqWCn4XqWnwObM8AqR1oHVJwbRmYFVw2yZwCB+dxQjh64PzjiJxRcZw2B 4i0FJ+2VZ3kHZOv4rDYVsHUquGi4nuUnwa8NRrnXOGdXNcjIqPCqQbYNBOYGKUcPvG4c8RMK0vp8 F+8H+BU8tB+g5R2QrZ9fLWDrWBDWP+WcP34S/NrQKmfYVegnG2RlVnC5IdsGAnODlKMDXj/aVzwW xFGSOYQx3q9goT0BLe+AbB3GVuUCtk4FGw3Xs/wc2LTBKvcvPm3lBlmZFVwZybaBwNwg5eiBG+0t ngriyospBIq3FOy0L6DlHZCtj60WsHUqOGm4nuUnwa8NvXKeToNaGRVejca2gcDcIOXogc+Ow7VD QXymnULgeFPBRZvtWd4BhfVRC4R1LHhouJ7lHVBYX7VAWIeC80eb0VneAYX1UwuEdSxYaTyZ5SfB 7+TrlONYvNOykVnBZWzsyUdgPi2VowPeB1+Wh4LzriFgvLlgow3pLO+AbH1vtYCtU8FO48ks74DC +qwFwjoWnLRhm+UdUFg/tUBYx4KLxlpZfhL8Tj6jrOv9+9XTchgz0eny7IvnGIH57BvGTHT68MLG 1yjHk9a1EEdkZFR4SSV7QASqQzUyKzffPoWC565tgxOiFjy0zZzlHRCtl99WC9A6FbyXQPCM1fIO yNbLWQvYOhWstA2b5efA5gwwyrk+cZi8ODeMzAouN2TPAALzuaEcHfBZ+M4tFKxfCBBvLdhohw/L OyBbb79awNap4KAd4yw/CX5t6JU4x1E0yMis4MI7tg0E5gYpRw88xfX9W3B8IXC8qeCk8WSWd0Bh vdYCYR0LLto1zvIOKKyPWiCsY8FDY60s74DC+qoFwjoU3D/aVc3yk+B38lnljHvcytOylVHhxXvs yUdgPi2Vowc+4q7mPO+07smPt2T7ClYaa2V5BxTWRy0Q1mkBJtpZzfJzYNMGo9zrdevVlazMCi7e Y9tAYG6QctTg/lvFndtbEKaK5hAg3lpw0IAnyzsgWt+/vRagdS44aXc1y8+BTRuscqaRBqJBRmYF F++xbSAwN0g5euAh7tzeguMLgeItBTcNeLK8AwrrpxYI61jw0A5rlp8EvzYY5Xlz2mqDxtsnq+s+ HP1tbAZzH8bbJ6sPL2x8W+UKz2gPeURWRoWXG7IHRKA4VCuzcvP9dCgIDwFz28YTohaEay1+sx/v gML6rAXCOhastC+c5SfBrw29cvxkg6zMCi43ZNtAYG6QcnTAMIRKxRuvzFIIHG8q2GiIluUdUFjf tUBYx4KDtoazvAOy9fmrBWydCk4avmT5SfA7A4zy3t+nBbv43DAyK7gokz0DCMznhnL0wJ33YA8F cXJrCgHirQU37SlneQdk67gBTCpg61Tw0PAly0+CXxt6Ja7cKBpkZFZwUSbbBgJzg5SjB4af40S8 8R4yhcDxxsmmv7AJB1p/vAMK66MWCOtYsNLwJctPgl8bjHK+16mbbpCRUeFFmWwbCMwNUo4e+PDN fyhYfzUEiLcW7LSnnOUdUFjvtUBYx4KDxhBZfhL82mCV87r0qllWZgUXZbJtIDA3SDk64LreOOQ8 FDxnDYHiLQUn7SlneQdE6/SoIhWgdS64aQyR5efApg09uBxOg1oZFV66x7aBwNwg5eiB94kDk0NB +J7IIXC8qeChPeUs74BsHa/kUwFbx4I4AAytP94BhfVZC4R1LFhpvzXLOyBbh6u7XMDWqWCn8TWW nwS/k88o7zf9s+vT0sis4IJF9uQjMJ+WytEBt+XA4dhXuGP6QoB4a8FBe8pZ3gGF9VELhHUsuGh8 jeXnwKYNVrmv8BWUGzQ88uh02YeYNoG5D8Mjj04fX7j1NUpYMPDUR2RkVnBtJntABKpDNTIr+44D yENBvPdIbYMTohbctAue5R1QWF+1QFjHgod2ybC8A6L1GUaY5wK0TgVhD1X4ujH8HNicAQO463PD yKzgslD2DCAwnxvK0QMv8dwhFDw1BBFvLFhp1JPlHZCt17UWsHUq2Gm/NctPgl8brHKfcfCXalAr kyIWD7JtIDA3SDk64PtNwnenb8H9hUDxloKD9pywvAMK66sWCOtYEP4nW1feAdH6ikN5UgFa54Kb xhBZ3gGF9VYLhHUo2H60p5zl58Dm5GuV+7313Zulqfq/q50uz754jhGYz77hD3an9y9sfY0SlmFZ 5BFZmRVc5MkeEIHqUI3MyslPEUJBXO8ytW08Ib6ChYYeWd4B2Tr+RU8FbJ0KVtpRzvKT4NcGq5xx LWbVICOjwgtZ2TYQmBukHD3w5qcIb0FcYzuHQPGWgp2GHlneAYX1VQuEdSw4aCs6y8+BTRt6cP05 DWplVnDxINsGAnODlKMDHjvfT8eCs4bA8aaCi7ZxsLwDCuunFgjrWHDTrnmWd0C2DrO+cwFbx4Kw qDB2quEdUFhvtUBYx4KFdpSz/CT4nXxGOZbfpte0sjIqvGSSPfkIzKelcvTAi58ihIL4ACmFAPHW go2GHlneAdk6PkBKBWydCnban83yk+DXBqvsR/yBXTTIyKzg6k62DQTmBilHBzx/fE8eCuLpl0Kg eEvBSUOPLO+AwvqqBcI6Fly0P5vlHZCtr6UWsHUquGmQi+Unwe8MsMq9/75zY7zItro8BWKjCcyn wHiRbfXxhVtfo1x5KQhxREZmBZfCsgdEoDpUI7Oy7TjmLxTcW20bnBCl4PjRjnKWd0BhfdUCYR0L FhqWY/lJ8GuDUcKqipdukJFZwaWwbBsIzA1Sjh54bjjmLxScWw0B4q0FG+0oZ3kHFNZ3LRDWsWCn sTGWnwS/NljlPOLCPKJBRkaFl8KybSAwN0g5euCz4kOaUBB/y0shULyl4KSt6CzvgGwdB3WkArZO BReNjbH8JPi1wShP+i1BNcjIrOBSWLYNBOYGKUcHfP8XjqB7C+7YkRQCxFsLHtqKzvIOKKzvWiCs Q8H7R4bOZ8PPgU0bWuX5nXENAtEgK7OCS2HZNhCYG6QcPXB/cFj/WxAXGcohjPF+BQttRWd5B2Tr +ENNKmDrVLDR2BjLz4FNG4zyXrHHWwxukJVR4aWwbBsIzA1Sjh543TisPxTEG7kUAsRbC3bais7y DsjW8UYuFbB1KjhpbIzlJ8GvDUYJ/3TqBhmZFVxDy7aBwNwg5eiA948f64SC+CcphQDx1oKLtqKz vAMK66sWCOtY8NCOcpZ3QLaOG3WmAra+0tIwtE2b5SfB7wwwyrbHgbHq3DAyK7h8lz0DCMznhnL0 wO3E8fmhIP21+vFWdF/BSuN/LO+AbB13F0kFbJ0KNtqmzfKT4NcGo+xbXABDNcjIrODyXbYNBOYG KUcPPA8cJB8K0pXPxlvRfQU7jaaxvAOy9bnWArZOBSdt02b5SfBrg1GOZ437P4gGGRkVXr7LtoHA 3CDl6IEPPzV7C7b8p5m3ovsKLhrSYnkHFNZnLRDWafkb2lHO8nNg0wajnG/9rRtkZFZw+S7bBgJz g5SjAz4rP4N6C7Y4li+FAPGWgrDgEpxUhndAto6j6FMBW6eClXaUs/wc2LTBKFeYNqwbZGRWcPku 2wYCc4OUowce/AzqLdh+XwgQby3YaLF/yzugsD5qgbCOBQftKGf5ObBpg1WeX9z/QTTIyKjwEmW2 DQTmBilHD7z5GVQoCLOdcwgUbyk4aRCM5R1QWD+1QFinxWdoRznLT4JfG4zyvJegj26QkVnBJcps GwjMDVKOGjx+Cz+DegvSo4wUAsRbCx4aBGN5B2TrOJ48FbB1LHh+tBWd5R2QrdetFrB1KlhpgIjl 58DmDLDKe/n80+eGkVnBxefsGUBgPjeUowceGw5JCQXrVUOgeEvBRrvmWX4S/LL4lPWv329Lm5lS Sr3MCi5WZ7MgMKekHD3wpqUQU0G8ZUgh9PG2Bce42H/POyBbxzVqUwFbp4Jz3IOu5yfBrw1GeYMK LcMG9TIqtGZc3wYCc4OUowMuCy2xlwqOvYYA8daCexzo0/MOKKzvWiCsY8Ez7kHX85Pg1wajbGmp TtUgI7MCa8b1bSAwN0g5euBO69ylgiYEiDcX7O/X7fDIuucdkK3PrRawdSpYx83ren4S/NpglStd W4kGGZkVWDOubwOBuUHK0QNPWqE8FYRPVg6B4i0F2zh2pecdUFg/tUBYx4Jj3Lyu5yfBrw1GCXug n7pBRmYF1sXr20BgbpBy9MCHVjBMBedaQ4B4a8E5jl3peQcU1lctENax4B43r+v5SfBrg1HOJX+a uUFGRoXWxevbQGBukHJ0wHWltfxSwfGFAPHWgmccu9LzDsjW4Zo2F7B1LAjbP8H5bHgHZOuwenou YOtUsI7jOnp+EvzOAKu8n0u1ZmIvswJL8vVnAIH53FCOHnjQMoKpIDwVzCFQvKVgHzev63kHZOt7 rQVsnQqOcVxHz0+CXxus8qy316BWZgWW5OvbQGBukHL0wJuWEUwFcfRKCoHiLQXnuHldzzsgWm+/ tRagdS64x3EdPT8HNm0wynXlTzM3yMio0AJ3fRsIzA1Sjg64LbQoXyqIX9cpBIi3Fjzj5nU974Bs Ha8BUgFbx4J1wQcIhp8EvzYY5bl+h1qBsJdZgQXu+jYQmBukHD1wp0X5UsH51BAg3lqwjpvX9bwD svW11wK2TgU7PkAw/CT4taFVlnDvplYg7GVWYC2+vg0E5gYpRw+8aGW8VJBO75026GsLjnGfvZ53 QGF91gJhHQsueoBg+Unwa4NVjl9a/BMbZGVWYC2+vg0E5gYpRwd877HxKzEUhD2jcggUbym4x332 et4B2To8tsoFbB0Lth89QLD8JPi1wSh7WPRON8jIpOBafH0bCMwNUo4euNLKeLEgbraWQ4B4a8Ey 7rPX8w4orM9aIKxjwUoPECzvgGwdrvdyAVungn3cg67n58DmDLBK/uYR54aRWYFlAPszgMB8bihH DzxoUb5UEO9NUggUbyk46AGC5R1QWF+1QFjHgmvcg67nJ8GvDZ3ybF6DWhkVWmWubwOBuUHK0QHf WznxmT3iQqY5BIw3F9x0F295BxTWZy0Q1nGO/2/cvK7nHZCt44VlKmDrVLDQHa7lHZCtw55+uYCt U8E27kHX85Pgd/JZ5TnCn2x5WrYyK7AMYH/yEZhPS+XogTstypcKzr2GQPGWgp3ucC3vgML6qQXC OhYc9Mu45SfBrw1GOfK1aGpQN/140HUf9qP72s5g7sM/1QtnfXhh42uUM2j6iIzMCixc2B8QgepQ jczKRYvypYJ7r22DE6IWXHRPbnkHFNZ3LRDWseCm3/ItPwl+bTDKtV3PqhtkZFZg/cC+DQTmBilH Bzx/tDJeLLh/XwgQbyk4fnhPbngHZOtwx5UL2DoVLPRbvuXnwKYNRgnjEB7dICOjQusH9m0gMDdI OXrgRivyp4KwunoOAeKtBRvekxveAdn6/NUCtk4FO/2Wb/lJ8GuDUZ77F/fxFA0yMiuwfmDfBgJz g5SjB54L/hwYCuLPsSkEiLcWnHhPbngHZOt4ZZYK2DoVXPRbvuUdkK3jvINUwNap4MabRsNPgt8Z 0CrrbznjTDk+N6zMCizP2J8BBOZzQzl64EPL+KWCeA+ZQhjjrQXnj37Lt7wDsnX4dswFbJ0KFrpp tPwk+LXBKO/3zqMbZGVUaLHDvg0E5gYpRwe8FlrGLxbcab2ahTYhbAs2+kHd8g7I1mGkay5g61Sw j3sJ9vwc2LTBKOsat/FSDTIyK7DYYd8GAnODlKMH7rQZQCo4vxAg3lpw0g/qlndAYb3XAmEdCy66 Mbb8JPi1wSrvbc2hG2RkVmCxw74NBOYGKUcPvGiBxlQQHzmlECjeUvDQD+qWd0BhfdYCYR2n6v/o NtPyk+DXBqO858jx6AYZGRVa0LFvA4G5QcrRAd8vRv5j9xZcXwgQby1Y6Qd1yzsgW9+/WsDWqWCj 20zLT4JfG6xypIVgRYOMzAos6Ni3gcDcIOXogRstVZgKwgI6OQSKtxTs9IO65R2QrcMMolzA1qng pNtMy0+CXxsGUK242cuswAqFfRsIzA1Sjh740BptqWBfawgcbyq46Ad1yzugsD5qgbCOBQ/dZlre AYX1VQuEdSh4PyvwANryDsjWcfPEVMDWqWDF+yDDO6CwXmuBsE5rVtCvoZafBL/z3irPvt7OJ6KV UaEFFvvznsD8iVCODvisq/gb9OxhF/YcAsVbCg68DzK8AwrrpxYI61hw0q+hlp8EvzYYJawh8i3+ OPyq0emyDzFtAnMfhl81On14YeNrlPs44q4Y4oiMzAosCdkfEIHqUI3MykHL+KWC52sbnBC14MI7 N8M7IFqfcT/CVIDWueAZ99nr+TmwaYNRni1dUIoGGZkVWBKybwOBuUHK0QMvWsYvFcSfGVMIEG8p CFOv4QvO8A7I1nG4ZSpg61Sw0m/Ulp8Evza0yhZWaH1kg6yMCi0J2beBwNwg5ajB8/ejZfxSQfzt IYUwxvsVbHTnZnkHZOv4TCQVsHUqOOgXX8tPgl8brHIf+ykbZGVWYEnIvg0E5gYpRw/caBm/VHBu NQSKtxScdOdmeQcU1lctENax4KZffC0/CX5tMMq63PHXZ9EgI7MCS0L2bSAwN0g5euBJa+mlgrT6 zE1b+rUFD925Wd4BhfVdC4R1uIT6/egXX8tPgl8bjLKH9eN1g4zMCqwl2beBwNwg5eiBD62llwrC 48UcAsRbC9Zx3fSed0C2DuPucwFbp4KNfvG1vAOydZi5mAvYOhUcdPtk+UnwOwOMcvyuuP6fODeM jMoFy1j2ZwCB+dxQjg64rLSMXyq47hoCxFsLTvrZ1fIOyNbh+yQXsHUquOlmxPKT4NeGXol7fYsG GZkVWMaybwOBuUHK0QMPWsYvFsSRyzkEjDcXPPSzq+UdUFjvtUBYh4JloZsRy8+BTRuMcr7feT/d ICOzAstY9m0gMDdIOXrgTcv4pYKwxlIOAeKtBSv97Gp5B2TrbakFbJ0KNrwZMfwk+LXBKNeWNjYR DTIyKrSMZd8GAnODlKMDrgst4xcLznR6b7QJYFtw0M+ulndAYf3UAmEdC068GTH8HNi0wSrXGd+F aJCRWYFlLPs2EJgbpBw9cKdl/GLBFZchSyFQvKXgpp9dLe+AwnqvBcI6Fjx4M2L4ObBpg1GeKw47 UA0yMiuwjGXfBgJzg5SjB560lUQquJcaAsRbCtaFfna1vAMK66MWCOtYsOLNiOEnwa8NrfLeIB+7 bpCVWYFlLPs2EJgbpBw98KGtJFLBudQQxni/gp1+drW8AwrroxYI61hw0B2B5R2QreN1eypg61Rw jZsA9vwk+J0BVjn2uO87nxtWRoUW++zPAALzuaEcHXBbaReLVBCHwaQQKN5ScNMdgeUdkK33Xy1g 61Tw0G+flp8EvzZY5UkDzFSDWpkVWGe0bwOBuUHK0QOvBf/OhoLzC4HizQXbQncElp8EvyyMEp51 XzolI7OCC5TaLAjMKSlHB9xDABTvkq9gUwgQby1Y6ddSy8+BTRZWue511ykZmRVcS9VmQWBOSTl6 4MFjX0JBWgJmpa0R24Kd7nosPwl+WRhlff9e6BVnrcwKLsJqsyAwp6QcHfD48dJuoSDcc+QQIN5a cNAvwpafBL8srPLE1RFUSkZmBdeLtVkQmFNSjh6485zJUBBHNKQQKN5ScNGdneUnwS8Lo4TRdnpV XSuTIhaatVkQmFNSjh5482qXoWA7aggQby246VdvyzsgW8dLi1TA1rFg/9GdneUnwa8NRtm3tL+p aJCRWcGFZm0bCMwNUo4OeC682mUoCD/X5hAg3lqw0K/elndAYX3XAmEdC1a8szP8JPi1wShHWGFL N8jIrOBCs7YNBOYGKUcPDPN1KN5j2eJjtxQCxFsLdvrV2/IOyNbxuVAqYOtUcODtleHnwKYNRgnL vu66QUZmBReatW0gMDdIOXrgJa6Ew2KuSw0B4q0FF/3qbXkHFNZHLRDWseDG2yvDT4JfG6zyxCV+ VYOMjAqviWvbQGBukHJ0wOu343i2/UxjfHMIFG8ueC+R6ALV8A7I1vExcipg61SwjDtV9vwc2LTB KHf+NIsGGZkVXBPXtoHA3CDl6IEb7bgSC9oQIN5asNFPz5Z3QGG91wJhHQv2cafKnp8DmzZY5Ynb hakGGZkVXMf3k/vVXj8lLsb6v/7r3/7tP53+bt2SogXP/VW+HrjzWqShYP3VDKk7peCgX64t74Bs ve21gK1TwTVudNnzk+DXRaM8+dIsL7fcD6Xv9OGFqzz0vyhptVjV/7ZZhOc2DkP8Ox2yfvLVcEoE sq4FN/2MbflJ8EvMKlc8P3TWRh9fuMhj1llJy+OKrE1ihOusjU5Zvx/Dux44ZV0KcGVty0+CK57X 7x/FLc7sE1l3ev/Cn9xnXZW0Vq7Kuk2McJV1p+vjGt9wWE7Ge8NGH1+4yOMbzkpaoZffsD1swvUb Nvp4coWC9NV20+azTcH5G/eQ7flJcMEP8pEfuMmsrT68cJWHrIuSlutVWbeJES6ztro+rvENvzcu 3qfJ6uMLF3l8w1lJiwSLN2wOm3D9ho0OJ9dbEH/oSacAnFy1YKEhMZafBHf+IAdw97NudDyiXWUd lbRisMq6TYxwL+tG18dFb/h6/Dfc6PTCSaY3HJW0TrF+w99hE+694Ubnk+ve6ynAJ1cq2MY9knt+ EvwSM8r2y3swiKytPrxwlYesi5IWZtZZf4kRLrO2uj6u8Q1v/le11ccX3tRXdVHSUsniDZvDJly/ YaPDybWlMXX5FICTqxbsNOTL8pOg+CuxXWkhB5m10ccXLvKYdVbS2tAq6039lci4ztro+riGN3xs 9+adXFYfXrjKwxsuSlqtWb3h9rAJl2/Y6nByvQX7dwrAyVULznEP8J6fBDc+uY4rLS0vszb6+MJF HrPOSlqeWmRtEiNcZ210fVz0hrfFf8ONTi+cZHrDUUmLYqs33B424d4bbnQ6ua74FDyfAnRylYKL hjRafhL8EuuVw7u+tTq98MHXt0VJq4DrrL/ECPeyPpy7RXPYRgmrA3vfXFYfXrjKwxsuSlqXW7/h gy8yMy7fsNXh5DrDvOt6CsDJVQuecY/7np8Eb/7mOp979f4sWn184SKPWWclLUQusjaJEa6zNro+ ruENX+e9rs4btvrwwkUeltP+lLjatXjD9dWHvCru5tW+a8JlXlaHc/MtiOMf0hkE52YpuH407Nby k+AXuFWutOqCbJXRxxfOMrSqKHHlbNWq8upjqwrutcoETrhuldH1cQ153W/G3r2q1YcXLvKYV1HS ct/iDddXH/KqL+zm1b5rwmVeVodT+y14zn/oPRW+AtwawfKToLjVvY+0lolsldHHFz6avRxQSUuH q1aVVx9bVV7Ya5UJnHDdKqPr4xryejb/ksDqwwsXecyrKGm9c/GG66sPedUXdvNq3zXhMi+rw6n9 FsS/++m7FU7tWrA8MB7U8pOguKJ43gtG7ymO1ccXzjK0Kitp7XTVqvLqY6vKC3utMoETrltldH1c fV7nb7m9H946vX/hKg95VSUt+M5v+Hv1Pq/vhd282ndNuMqr08dTOxRs3wk4ntpfwUazRSw/CfLv dufvSNu4yVYZfXzhLEOrspIWyFetKq8+tqq8sNMqGzjhulVG18c15vUcl/NYpNPHF84y5JWVtOK9 esPl1ce8ygu7ebXvmnCdl9Hp1H6OZ68nIJ3apWCnmTqWnwQvfKBzLpt7rd3pwwsXeWxVUdIOASLr +upDq+oLu61qAydctsrq+rjGvK64RpzOy+jjC2d5WNj/U+K6+yqvXARxF9yNuxzcGHd5YS9uExrh Om6jwycjzA5a6/kLn4xacNIkK8tPgl+/jLKm9TRlp60+vHCRx05XJW4BILIuRWOnK+51uh7c0On6 wm6n234RLjttdX1cQ9z7c2/eF5HVhxcu8hh3VeK2B+INl6Ix7op7cdeDG+KuL+zFbUIjXMZtdfhg hZVsfuXw6YNVC3C/FstPght/hYafLZwncZ0+vHCRx05XJe7AILIuRWOnK+51uh7c0On6wl6nTb8I l522uj4uinv3LsasTi+841Y0nxJ3ndB57XwtV/E/xL3ztVx9YS9uExrhXty7ey0XppId9e8KfLBq wUXzVi0/Ce58LRdA55l+p+MRxS0P+m0uPiXuQqGzjkV4oiTlDydKLMITJeF/40ThTp/OLwqdLo8L 4t6Xn/s9ZvTxhbMMcRcl7kqh3nAugriL4sadiyDugv8h7hN/kCi4jtvo9MHalzhgPZ3+9MEqBQ/N WLb8JPgTX6Ev6F2bWB2PaFedTkrcBES3auVLm6r8odMrX9pU3O102y/CvU6v7rXJW7D//qG3PaoF vHuR5SfBVVybXIc3FK3TxxfOMnS6KHE/EpV1LoJOF8XtdC6CThf8D51exbVJwnWnjU6dvo44rS99 8qjTueD+0TR5y0+CPAbvPMMTQqfTVh9euMhjp6sSt38RWZeisdNV8TpdisZOV9ztdNsvwmWnrS6P C+J+Hb0/llYfXzjLEHdR4pY3Kq9cBHEXxY07F0HcBffiNqERruM2Onyw3oK4BWI6/eGDVQtWWqXA 8pPgxX8szz/cyJ/+jXyRodNZSTsMqazlc4CquJ2WzwHOv/McwPSLcN1po8vjGuO+dv97zOrDCxd5 jLsoaVcl8YZL0Rh3Vby4S9EYd8XduOXddMZl3FaHD9ZbENeaT6c/fLBqwbbD7HrLT4LiK/S63CFb nT6+cJah01lJGzypVuUi6HRR3E7nIuh0wb1Om34Rrjt9eQPGbGhGuQ//e8zqwwsXeYy7KGlTK/GG S9EYd1W8uEvRGHfF3bgvMd6s4DJuq8MH6y2IG22n0x8+WLVgp9VXLD8Jiq/Q+4mfSN1po48vnGXo dFbSblWqVbkIOl0Ut9O5CDpdcK/Tpl+E604bXR7XGPezuSMxO3144SKPcRcl7dAl3nApGuOuihd3 KRrjrrgbdxsa4TJuq8MH6y2IOzyl0x8+WLXg3GDVEMtPgjyQ8/3ftzffudPHF84ydDorabMw1apc BJ0uitvpXASdLrjXadMvwnWnjS6Pa4j7CiM9nEvBTu9fuMpD3FVJG6TxG65FQ9yf4sRdi4a4P9yN uw2NcBV3p48frFDQnP7jB+sruGhVKctPgiteCr4duhdnQFKnjy+c5WFHtk+JG6apVuUiOFEK7p4o uQhOlKL8jROFOp1w3Wmjy+Ma414293us04cXLvIYd1XiBmriDZeiMe6Ke3GXojHuqrhxt6ERLuO2 Onyw3oI4QSCd/vDBqgVhqSZ8Zx8/CYqv0OUOYyadTht9fOEsQ6eLEverU63KRdDpgrudzkXQ6aJ4 nTb9Ilx32ujU6fsXHibJHTq/Atxo0/KT4MWdDus3eJ22+vDCRR47XZW4dZ7IuhSNna641+lSNHa6 Km6n234RLjttdej0W/B8nzzodCl4frRQn+UnQdXpMJvc67TRxxfOMnS6KHGnQtWqXASdLrjb6VwE nS6K12nTL8J1p40ujwvifvxrE6uPL/yoa5Os5J0L1Rt+1LVJfWE37kddm1TFjbsNjXAdt9Hpg/Xc 21lPf/pglYKVltW2/CQoLou2LW5mLztt9eGFizx2Oit5o0iRdcHHTtcX9jpdisZOV8Xt9KMuizIu O211eVxj3Ht46OXEbfXhhYs8xp2VvDmmeMMFH+OuL+zFXYrGuKvixW1CI1zGbXX4YL15xX0M0+kP H6xasNECpJafA5t+WeUPt3e7f3u3y9u7rOR9OlWr5O3d/ndu73Z5e7f/nds70y/CdaePP3yFvgVx /k/qB3W6FBw/WETR8pOg+Ap97/xOZ7xJp48vnGXodFLytqgq64xDp8sLu53ORdDporidlneWGded Njp1+jniUlSpH9TpUnDS0rOWnwS/fhnl+MMzhMN/hnDIZwhZyTu0iqwP+Qzh+DvPEA75DOH4O88Q TL8Il50+/vQM4ch3+qkf0OlacKlcP34SFM8QwsopzsTOTh9fOMvQ6aTkDXFVqzIOnS4v7HY6F0Gn i+J1+pDPEDKuO335yz+FgrhIU+oHdboUPLQsq+UnQV7+6XpD8tYW6/ThhYs8djoreW9ekXXBx07X F/Y6XYrGTlfF7fQlFp8quOy01aHTb0G6IYn9gE7ngvP3u+mhj+EnQV5U7ToPd9pfp48vnGXodFLy VsiqVRmHTpcXdjt9iEmHn+J12vSLcN3pw5/2Fwriwp6pH9TpUrDSiuuWnwR52t/1+CucdfrwwkUe O52VvCuzyLrgY6frC3udLkVjp6vidvoQ0/4KLjttdej0W7DftR/Q6Vqw4W2x4SdBXl/t/q0/b9hH p/cvXOWh00XJm2Bz1hUfOv29sNPpWjR0+lO8Tpt+Ea463eljp9+C5XfWfoyd/gqOFdYss/wc+OMR JwFcnCuyTqcjWvCKrCh5P27ZqoRTp/ML+51ORdTprDidtv0i3Ol0q3On168f3OlUcJ4wRdTyk+CC V2QR9D/TizNGssrY6TV+puP257pVPMTye+E/dJqHWH6K3+mmX4R7nV7/9JnettoP7nQquBdYNcjy kyAPz3yV43F+1el0eOEkU6ejkrdDl1knnDqdX9jvdCqiTmflD53m4ZkFdzrd6tjpuEFi7gd2Ohe8 9/TjhZXl58CmXz24OANxO52OKMrU6agcy/vX0Mk64dTp/MJ+p1MRdTorfqebfhHudLrV5XFh3N5i R51OL7ziw+eiHOt6ytGwFce41z89fK5FGPf6p4fPNjTCvbhX7+FzKAhbnObTnz9YseD9EoclfCw/ CfIyTXcY2uP+sTy8xxdVhk4n5Vj3RQ7ErTh0+vjz44taBJ0+/vz4wvaLcN3pw398EQqaflCnS8G6 w5I0lp8E+fHF/fN/k+/08YXVb/JFOdbjkANxKw6d/hu/ydci6PTf+E3e9otw3ek//CYfCuIqeKkf 1OlSsD2wlIPlJ0H+Qen+w1DF2x+qeMuhikU51uunWyWHKt5/Z6jiLYcq3n9nqKLtF+Gy038aqnjn AYW5H9DpWnBsMOPc8pMg/8xwL5f/mbb6+MKX+kxn5VjvXa4fWXHo9PU3PtOlCDp9/Y3PtByqWHDd 6esPn+m3ID4iTv2gTpeC84YZ55afBMVnej3ccTadPrxwlo/1eeyjs6psyyaHH9dXH0+U+sLeiVLw 8USpL/w3ThTodMZlp60OnS67SqV+QKdrwb3CFGjLT4I8xOcOQ7G8B1VWH184yce23gu+8LHtqxyU WovgRCm4e6I84ofL74X/xolCnX7cnw47nTr9xEfEyR87XQrCO8d39vGTIP90eG+bf+1t9eGFswyd rspxyUGptWjsdMW9TpeDGztdX9jt9CN+Oiy47LTVodNvQbpCjp886HQteE6YfW35SVBce2+Xu/JF p48vnGTqdFGuRY6HrUXQ6YK7nc4HB50uL+x12vSLcN3py1/5IhSEAeLp8LHTpSAEh+/s4ydBXvni DvvpOD8ddvrwwlmGTlflPuV42Fo0drriXqfLwY2dri/sdvoSK18UXHba6tDpMIzyqZ886HQpWJcF Jn5bfg5s+mWVw53C3OnjCyeZOp2VPe7Rp1qVi6DT5YXdTueDg06XF/Y6bfpFuO704U9hDgXb1w/q dClYD5iJbPlJkGcz3Mfyu5yBH50+vHCWodNF2cNoXJV1KRo7XV/Y63Q5uLHT9YXdTh9iCnPBZaet Dp1+C+Jz7dQP6HQt2H8wNdbyk+DXL6Oc9+YN8en04YWzDJ0uyr4+cihuLRo7XV/Y63Q5uLHT9YW9 Tpt+ES47bXXo9FsQ74VSP6DTteDYYa6m5SdBHuJzv//prXnf6cMLZxk6XZQ9bGOosi5FY6frC3ud Lgc3drq+sNdp0y/CZaetDp1+/zN98g7ebukrOGnXJMtPgrxafwS9JydWxyM6Vaejsl+rHKBZi7DT zx8fvJSDw04/f3zwYvpFuNfpx31ycr1/YL9+YKdzwb3BlDLLz4FNvzplc3+1tDq8cJSx00nZw8Io OutURJ3OL+x3ehO/mdYX/kOnH35yknGn05uzw4sNzSrn6s2e7vTxhZNMcWdlvy85HrYWQdzlhd24 88FB3OWF/bg38dNhxnXcRqcP1rk+3+lPH6xS8NwwpczykyDPnr7v3+Ytg9bpwwtnGTpdlOO3yPGw tWjsdH1hr9Pl4MZO1xd2O932i3DZaatDp9+C4+sHdLoUbMsKU8osPwnyMmj3e73v7drU6eMLJ5k6 nZVjOfV42FIEnS4v7HY6Hxx0uryw12nTL8J1p3d/06dQEG5Rcj+o06VgvWBKmeUnQd706Q7bn3o/ M1h9fOEkU6ezcmw/PR62FEGnywu7nc4HB50uL+x2ehd7RhVcd9ro1On3huSq/aBOl4J9Ebl+/CQo fmZ43otA72cGqw8vnGXodFHe6yI9HrYUjZ2uL+x1uhzc2On6wm6n234RLjttdej0k6+4Uj+g07Xg OGFKmeUnwQt/ZniW1X1Q1en9Cxd57HRVjuORoyRr0dDp74WdTteDGzr9vbDXadMvwlWnO33sdCiI 102pH2Onv4LrB1PKLD8J8oOq5w8DPx5/4EeRqdNZOa5djnyuRdDp8sJup9Wwk+fvDDux/SJcd/oP Az9CQRxylfpBnS4F9wG/9Vp+EuSBH89yx+nnutNGH184ydTprBzvl6S6IqtF0Onywm6n88FBp8sL u51WAz8KrjttdOp0GClW+0GdLgXPA7fFlp8Eb/xB6VWWn3M/3enwwlHGTifl/G1yKG4tok7nF/Y7 nQ6OOp1f2O102y/CnU63OnZ6afZQxk4v3zbI+M54S+C/Af7wfjqCzv10p+MR4f10Vc73kkJdkdUi 7PT6p/vpenDY6fVP99O2X4R7nXb3EgoF8WIvffK407FgX3b4Vd/ykyDvJfSs++YN2+v04YWzDJ0u SlhsTF6RlaKx0/WFvU6Xgxs7XV/4D53mvYQKLjttdej0WxB/9kn9gE7XgpU2prT8JMjD9p71/oV/ 0Z02+vjCSaZOZ+XcT511KYJOlxd2O50PDjpdXtjrtOkX4brTRqdOv39N99oP6nQp2DeYPGj5SfDr l1G2P9xlbf5d1ibvsopynotceLkWjZ3e/s5d1ibvsra/cZdl+0W47PT2p7usLd8LpX5Ap2vBccHk QctPguIuazv9b2+rjy98qm/vopzX4bTqVN/e9YXdTp/q27u+sNfpTd5lZVx3+vzDt/dbsO+1H9Tp UvD+T7iENvwkKL699/fS2Lsis/rwwlmGThflfH5yzedaNHa6vrDX6XJwY6frC7udPtW3d8Zlp60O nX4L9rX2AzpdC95vZ8714ydBcUW27z9vBc1OH184ydTprFy/XQ6vr0XQ6fLCbqfzwUGnywt7nTb9 Ilx32ujU6X35/Wo/qNO54PgtMJvN8nPgj1fQfPZ786bBdfr4wllOm0ujErepUFmnIjpRsuKfKLkI TpTywn/jRKFOJ1x32ujU6XsLg7ByP6jTpWChjVctPwnyNLjnWLfNuyKz+vDCWYZWFeVaHjmRor76 eKJUxTtRisfY6XpcbqfbfhEuO2116PRbEKZr5X5Ap2vB9oPZbJafBDe+Ijtvd2WuTh9eOMvQ6aJc 2yYnUtRXHztdFa/TxWPsdD0ur9OmX4TLTlsdOv0WxPWzUj+g07XgfetwYWX4SZBX5nqu9906w+s7 fXjhLEOni3Ltt5xIUV997HRVvE4Xj7HT9bi8Tpt+ES47bXXo9FsQJjXlfkCna8Fxwxwny0+CX796 5fD+TludXvjgP7RFef9FTqSor46dPv74Z754YKePP/6dNv0i3Ov04f6dfgvOrx/c6VRwbTDzxfKT 4MF/p1/FmwbX6fTCzUbLqMSp5DprnkVXlT+dKJf8Srj+zlfCwX+nM+512p0GFwuu2g/udCq4L5j5 YvlZUHymz+Xwfp+2+vjCSaZWZeW6Ljllpr46nChFcU+UXASdLsofOs3T4AquO2106vS5NP2gTueC 87fCzBfLT4Jfv4xy7+7ook4fXjjL0OmiXM8ip8zUVx87XRWv06Vo7HRV3E63/SJcdtrq0Om3II4B Sv2ATteC5YSZL5afBMXoojCWyu200ccXznJa1IOUtDyEalUqohMlK/6JUtzHE6Uof+NEoU4nXHfa 6NTpezu+flCnS8F7JcG5fvwkuHGnw1gq79vb6sMLZxlaVZT7d8rJUfXVxxOlKO6JUvGh01VxO932 i3DZaatDp8O4vrv2AzpdC/YDZr5YfhK8+Nv7ef/oO6OAO3184SRTp7Nyrz85Zaa+OnQ6K36nCz52 uihep02/CNedNjp1OvyFrf2gTpeC8wdTMSw/CV4wWGX76/fbnd+nB92+8Cf3nW6UtBk7Zd28etfp RtGdbnHb6VZxO932i3Du9KD3nU4F8Vfk1I++023BtQ9TMXp+EqTfp4Nyh4H3TqeNPr5wkqnTWUm7 g6tW5VeHTmfF73TBx04XRXa67xfhutNGp07faeXx1A/qdCm4n2EqRs/PgU2/jLKsm15AaNCHF84y dLooabtqkXV59bHTRXE7XfGh01VxO932i3DZaatDp5f8oDX1AzpdCq7fJnL9+EmQFhAKird/6aCP L5xk6nRW0v7JqlVmm1FS/E4XfOy02dnUP1Go097+pYNOnT63uCRI6gd1uhQs9zDEs+cnQVps5FXW 30/PwBv04YWzDJ0uStpVV2RdXn3sdFHcTld86HRV3E7z1qkfLjttdej0WxDnyaV+QKdrwTZuIt3z kyDNwAvKva3y2nvQxxfOcrcfdqvEUQKqVamITpSs+CdK9oATJSt/50ShTidcd9ro1OlyAxf7QZ3+ 7vCGqRg9PwnSQPFXCWOpvM+01YcXzjK0qihpQ1+RdXn18USpineilKKx00XxO932i3DZaavL44K4 3+9e+SPxoI8vnGSKOytpm1eVV351iLsobty5COLOihu3CY1wHbfR5XGNce9h5y0nbqsPL5xliLso aa9V8YbLq49xV8WLuxSNcRfFj7sNjXAZt9XlcUHce/x7o+M2+vjCSaa4s5I2PFV55VeHuIvixp2L IO6suHGb0AjXcRtdHtcYd7gv9668rT68cJYh7qKkXUfFGy6vPsZdFS/uUjTGXRQ/7jY0wmXcVpfH BXHv/kWR1ccX3tVVTVHS1p8qr11dU1XFjXtXF0VFceM2oRGu4za6PC6K+9BzGQYdXviguQyNkvbf lHmlV6e4j2aawh9wijspfty7ujLJuBN3q8vjwrgf/+xudXrhR53dUcmbYOq8HnV2Z+UPcT/q7E7K H+I+aEJBc/BO3I97djehWeV2VrMZ9PGFb1zN5lPyTpTqDedXh7jv48/X3aUI4s7Kn+J+xNl9O6vZ DLo8rjHuy1toZNCHF754oZFPydtBijdcXn2Muype3KVojLsoftw3LinTHLyK2+ryuCDu0xn1POjj C5846vlT8p6MKq/86hB3Udy4cxHEnRU3bhMaHryM2+jyuMa4791/BGv14YWzDHFnJW+MKN5wefUx 7qp4cZeiMe6i+HGfOPS4OXgVt9XlcUHc3vpUgz6+MK9P9Sl5d0KVV1lgaozbLD31BxzizoobtwkN D17GbXR5XGPczxr2NNVxW3144SxD3FnJe9aJN1xefYy7Kl7cpWiMuyh+3LxIVHPwKm6ry+OCuE9n vuGgjy984nzDT8kbx6m88qtD3Gc7lfAPOMSdFTduExoevIzb6PK4hrjfLLbFObs7vX/hIo9xFyXv 3sZvuL76EPenOHHXoiHuqvhxnzjprzl4EXeny+OCuN/vLzduo48vnGSKOyl5CzWVV351iLsobty5 COLOihe3DQ0PXsZtdHlcY9zL6sdt9eGFswxxZyXvYybecHn1Me6qeHGXojHuovhxt6Hhwau4rS6P C+K+3O/uTh9f+BLf3UXJm4mpvC7x3f0pbtyX+O6uihu3CQ0PXsZ9ed/dNjSjrD/3iWCnDy+cZYg7 K3mfJ/GGy6uPcVfFi7sUjXEXxY/7Ut/d5eBV3FaXxwVxb862NoM+vvDWbh+DSpwppfLacFecT/lD t/LBQbe2+493STY0dJdxG10eF8R9O2vWD/r4wjeuWf8peccj9Ybvdml5VNxu5YODuO92NXu/WxT3 7axZP+jyuMa4w8+j3p9Kqw8vnOV+w7BP8eMu+Bh3Vby4y8GNcVfFjfvGNeubg1dxW10e1xj3fv9u 77vb6sMLZxnizkre5Um84YKPcVfFi7sc3Bh3Vby4TWh48Cpuq8vjGuM+/AewnT688GEWZAYlb7Uk 3nDBx7ir4sV9qOe3n+LFbULDg1dxH+4DWBtar3i/xHc6vfCzqbifb78jndezqbif7W/EzT/kf4oX 96EewNaDd+J2fom3oXVKnAzhxN3q8MJRxrijkjcdkm844RR3Vvy408FR3Fn5Q9z8S3w9eB13q8vj grjP3+WMour08YWTTHEnJe/8o95wxiHuorhx54ODuIvix92Ehgcv4za6PK4x7vBrtHdXafXhhbMM cWcl7wcj3nDBx7ir4sVdDm6Muypu3G1oePAqbqvL44K4759eimDQxxdOMsWdlLwpi8or4xB3Udy4 88FB3EXx4jah4cHLuI0uj2uM+/K22xv04YUvsyseKHlnFPGGCz7GXRUv7nJwY9xVceNuQ8ODV3Fb XR4XxH36tzlWH1/4VLc5Wcnbk6i8TnWbUxU37lPd5lTFi9uEhgcv4z7d2xwTmlHun/8A1urDC2cZ 4s5K3iNEvOGCj3FXxYu7HNwYd1XcuE91m1MOXsVtdXlcEPcf/lTe/p/KW/6pzEreqEPlJf9U3n/n T+Ut/1Tef+dPpQkND17G7f+pvOWfSnc1gEEfXriuBjDEXSZgp90yxBsu+Bh3Vby4y8GNcVfFjVv+ qXRXAxh0eVwQ9+lO3+308YXPH+1p/yl5ywqVV8Yh7qK4ceeDg7iL4sUtpuQ3By/jNro8riHu9ef/ vNDp/QsXeYy7KHk3AX7DFR/i/hQn7npwQ9yf4sZ9ijm09eBF3J0ujwvidpcZWOWs9qLgtir9ASGo DlXNGC/KdcdlqseZZm/BUkZFwR4ybcG5sHXDO6CwfmqBsI4FYWEntq78HNi0wSjLej2PbpCRUaEt F/o2EJgbpBw1+Px+YbFiiDfcTJw1BIi3Fjw/OmbDOyBbr0stYOtYcP+OYd+CnndAto4bYKYCtk4F 7zcHBt7wc2BzBhhlW98/wfrcMDIr7rmRzgAC87mhHD1wC6vlQrzbuv6WGgLEWwu2fVi9vucdUFif tUBYx4L95nfd8A7I1nEPr1TA1qng3Ib1vXt+DmzOAKscT/hrqc4NI7MCi873ZwCB+dxQjh54huVa Kd7jievgpxAo3lJwXcL64x1QWF+1QFjHgveyjnP+eAdk6/NXC9g6FoTg6KPU8pPgdwZY5YmLfchz o5VRoVXP+zOAwHxuKEcPfMJ6oRTv8+xnDYHiLQXrb1jrt+cdkK2PpRawdSrYjmHx2Z53QLY+91rA 1qlgf4bVUHt+EvzOAKMcyyNXxO9lVmDZ7f4MIDCfG8rRAZc1LFgJ8b4Fx11DgHhrwXvCwteF4R2Q rc+tFrB1KrjuYU3MnndAto7zglIBW6eCZxsWaez5SfA7A6zyEoc+N4zMCqz73J8BBOZzQzl64HtB iV8XR/lQxxAo3lRw/X7XsDJizzugsD5rgbCOBes6LNXX8w7I1uEeKhewdSrYTlg7zvKT4HcGGOV6 0tWCODeMjAotPNyfAQTmc0M5euD943jfguMLAeKtBccCC7ZZ3gHZOvylyAVsnQreKPldf7wDsnW8 z04FbJ0K7h8saWX5SfA7A4xyb084P9W5YWRWYOXb/gwgMJ8bytEBw1Zz2Nm34PjVECDeWvBe+7L1 xzugsD5qgbAOBct78JzzxzsgW593LWDrVBD2FEDrj58EvzPAKvcSFwMV54aRWYGlV/szgMB8bihH D9zComUU772E9VByCBRvKdhueppneAdk67CpYi5g61RwrPToxvAOiNbr76gFaJ0LzosekRl+DmzO AKO8X+txaTBxbhiZFVz7054BBOZzQzl64HnxZ/YtOL4QIN5acC/0/MTwDiisn1ogrGPBe5cOcRne Adn6WmsBW8eCdfnRDb7hJ8HvDGiV7f0T7pwbVkaFF5+0ZwCB+dxQjh74nPh1EQpi61MIY7xfwXrA 0zzLOyBbh0c6uYCtU8H712z88Fp+EvzaYJXrOA7ZICuzgksQ2jYQmBukHB1wW/lXg1CQTu8YAsVb Co4dHgNa3gGF9VULhHUsOG+41bX8JPi1wSjrK1y6QUZmBX93s20gMDdIOXrgwb8ahIIwkiqHAPHW gnuFx4CWd0Bh/dQCYR0LngvuNy0/CX5tMMq2vRf9ukFGRoV/sLNtIDA3SDl64L3xV+JbsP5qCBBv KdiWBZ5YWt4BhfVeC4R1LFhPuOmz/CT4tcEo53GcToOMzAr+YGfbQGBukHJ0wH3hX0ZCQTy9UwgQ by3Yf/Co0/IOyNb3XgvYOhUcB9x5Wd4B2Tp8zHMBW6eC84HHgJafBL8zwCrPGYcyiXPDyKzgz5r2 DCAwnxvK0QN3/lEmFDxHDYHiLQX3Drc/lndAtL5+v1qA1rngueGJpeXnwKYNPbhsToNaGRX+1cy2 gcDcIOXogQ//PBELnhoCxxsL9mWjexDDOyBbh9m/uYCtU8H7D/yuP94BhfVeC4R1LNhXuj43vAMK 67MWCOtYcJzwGNDyk+B38hnl/Wz8Vn1aGpkV/CnWnnwE5tNSOTrgsa83/vl7C9JZF0OAeGvBtdD1 ueEnwS8Lq6RbCZWSkVnBX41tFgTmlJSjB978E3koCBddOQSKtxTcBzyVtfwk+GVhlHvdtlOnZGRW 8OdmmwWBOSXl6IDne5eO30tvwbHWECDeUnD8fnQPYvhJ8MvCKulOTaVkZFbwJ3WbBYE5JeXogZf4 i/MWPEsNgeItBcsOj6wtPwl+WVjliae9TKmVWcFf/20WBOaUlKMDXmFBfoz3OZdfDYHiLQXrQ/dZ hp8DmyyM8mxnCp5TMjIpYtiAzYLAnJJy9MDjwfEGoSCdYzEEiLcW7Bs8lre8AwrrsxYI61hw3HSz Y/hJ8GuDVd5/aIZn9BMUOl334ejvSDKY+zDMfOj08YVb31bZf+cZLyD4iKzMCo4jsQdEoDhUK6Py XmDgqNNQsH1tG0+Ir+Ba4TcPy0+CXxZWeeIVm0jJyqzgkBebBYE5JeXogfuJ49VCQfi6zyFQvKXg vuAW1PKT4JeFUZYt/qylUjIyKzhWxmZBYE5JOXrgw+N7QkG4d8ohQLyl4Pwt8LuO5SfBLwur3Mvi pGRkVnA8kM2CwJyScnTAZ+Nn96Fg+0KgeEvBcsKDKstPgl8WRlmXO/5QJ1IyMis4dMlmQWBOSTl6 4HXiI5tQEH+aSiFAvLVg+9H3kuEnwRNHIO3rcS67TsnIrOCYJ5sFgTkl5SjB9fdbf/gEIRSEHZ1y CBRvKdh37GzLT4JfFkbZ9nM5dEpGRoXHddksACwpCUcXPHlqQSgIe9zkECDeWnA8cHdt+Unwy8Iq 1x1HRoqUjMwKDkGzWQBYUhKOHriE/f4w3is+h80hULyl4Nrg/sTyk+CXhVHeL8n70CkZmRUcu2az ALCkJBxdMNzhU7z78vzWGgLEWwvumy5aDO+AwvqqBcI6FLyXuPSVaPg5sGmDVY47fqGJBhmZFRwa aNsAYGmQcHTBZ8OHF6Fgv2sIFG8pWPikavlJ8MvCKs9zb05KrcwKjmK0WQBYUhKOHrhuPFlifxsS f2xLIUC8tWBb6F7V8DOgycKC23PqsZ5WZgWHP9osACwpCUcXvH98P/4W3GsNgeItBe8fSX6zHz8J flkY5XwvJhedkpFZwSGeNgsAS0rC0QO3leePhYI4GDqFAPHWghOvlww/CX5ZWOU80vB3TsnIqPBo VJsFgCUl4eiC5833429BHN6RQqB4S0F4eInWHz8JfllY5Tnic0mVUiuzgsNYbRYAlpSEowfuC4/e eAvO8A2WQ6B4S8FNa7JYfg5ssjDKteXxf5ySkVnBEbc2CwBLSsLRBcPisBTvWxCfnqcQIN5S8H7v 0N2x4R1QWJ+1QFjHgvdTDXEZfhL82mCV98X0kGgrs4KjhG0bACwNEo4u+PACB6EgXLjmECjeUrBt dOdo+Enwy8Io70ttTkpGZgUHNNssACwpCUcPPPaFHwW8BftZQ4B4awGu3GT5SfDLolWOX9iwVqZk ZVZwJLTNAsCSknB0wZvHRL4F5/KFMMb7FZwr3L5Zfg5ssrDKe+dxy5SszAoO2rZZAFhSEo4eeL6X i3RNGAritJMUAsVbCq4Tbt8sPwl+WQygHtpuZVR45LTNAsCSknD0wPfuFW8YQ8H1hcDxpoJngds3 yzugsL5rgbAOBc/vgFsby0+CXxus8uxxbJ9qUCuzgkOubRsALA0Sjh54/3gdkFCw7zUEircUrD+4 tbG8AwrrpxYI61iw7XDZb3kHZOtzrQVsnQr2By6JLT8JfmeAUZbtWfVwfCuzgmPi7RkAYDk3hKML 7jzHLxQEJIcA8daCc4PLGMtPgl8WVrmO+MBcpGRkVnAwvc0CwJKScHTB+8ZbyFDw3DUEircUXPiH wPCT4JeFUda0VKxKycis4Lh/mwWAJSXh6IHPtuItZCiId1spBIi3Fjw01MTyk+CXhVWOHDynZGRU eMKAzQLAkpJwdMGLF14MBekciyFQvKngvQU6sbMtPwl+WVjlSfNLVUqtzMpKkyJsFgCWlISjAy6/ 5cH7uGNNgyFzCBRvKVjxHsfwk+CXhVG27YjDnERKRmYFJ37YLAAsKQlHFzw3vo/btjOssJlDgHhr wUZDTi0/BzZZGGVPQ0dUSkZmBeeo2CwALCkJRw98Jb6P28OWkjUEiLcWHD+6aDG8A7J1mKeUC9g6 FZz0aMvyk+DXBqscx37pBhmZFZweY9sAYGmQcHTBOPGD4j2OMCQhh0DxloKLZhpYfhL8srDKE398 lym1Mis4PcZmAWBJSTi64LPyHc1bcNw1BIq3FDwbXQAbfhL8sjDK8X5/3DolI6PC02NsFgCWlISj B67biT/pvgXnb68hQLylYPnRD0aWnwObLKySL8ZFSkZmBafH2CwALCkJRxe8xXfvWxAuNnIIFG8p WGkSneUnwS8Lo4StjW+dkpFZwekxNgsAS0rC0QO3lReYCAX7XkOAeGvBdtEFsOEnwS8Lq7xBnDWl YcZIp8sw4lsGsIQxzBjp9PGFW1+jXO/nQk97sjIrOBPIHhCA8lCNzMp58hOE8IPiVdsGJ0QteO/A 4cvF8JPgl4VVrjTySqRkZFZw0pLNAsCSknD0wH3htTdCQRhklkOgeEvBedIlu+EdkK3D1NJcwNap 4P1TT6dxy0+CXxuMcr/36odukJFZwdlHtg0AlgYJRxc8Nn54cYcvwRoCxFsLnoOuKQ0/BzZZWOW4 959Oycis4OwjmwWAJSXh6ILxJzGK9/2/s4ZA8eaC8CCNOtvyk+CXhVXSUw+ZUiujwrOPbBYAlpSE owceu/jFJc/czSFQvKVg3ema0vBzYJOFUd7r4Xj7IFIyMis4+8hmAWBJSTi64M0L4IWCeKeUQoB4 a8FG++dYfhL8srDKlZaJEikZmRWcfWSzALCkJBw98P0HfoIQpsaeNQSKtxSE/d/Q+uMnwS+LVjl/ 7x+tS6ZkZVZw9pHNAsCSknB0weuHTxDegnQjmkIY4/0KTtqox/JzYJOFUZbrjr+WckpWZgVnH9ks ACwpCUcPvBbeGigU7FsNAeKtBeHrFa0/3gGF9VULhHUseGi3HMtPgl8bjLKGewfdICOzghOfbBsA LA0Sji548FygULD9aggQbynYlgUuISw/CX5ZWGX93atOycis4IwpmwWAJSXh6IH3b8GHF6EgDGDL IVC8pWCl39IsPwl+WRglrG1565SMjApP7rJZAFhSEo4uGL9CId63IHzEcggQby3YaZaX5SfBL4te iVsoiJSMzApO7rJZAFhSEo4uePOupKHgPGsIHG8qOPB7yfCT4IFztM73Pvu8dEpGZgUnd9ksACwp CUcPfLYF78dDQZhSkkOAeGvBScNELD8JflkM4K1TMjIrOLnLZgFgSUk4uuDFK8y9BcvvCwHjzQU3 zZ22vAMK67sWCOtY8OCVsOHnwKYNPRgXvpINamRWcOKTbQOApUHC0QHDYF+8V40FRw2B440F+0Kj Ay3vgML6rgXCOhastJyE5WfB2gajhH2XN90gI6PCs4lsGwAsDRKOHriILV7fgis+ikkhQLy1YF/o +9/wDiis91ogrGPBQeOYLT8HNm2wynHEocCiQUZmBScF2TYAWBokHD1w3Xhvh1AQ/+KnECjeUnDR KkKWd0C2DlNfcwFbp4L3/yiulp8EvzZY5ckbiscGDb8gdrrsQ0wbwNKH4RfETh9fuPU1yr2k22Fx REZmBaf42AMCUB6qkVHZVl5WKhTEhw6pbXBC1IKHtsuxvAMK67sWCOtQEPYahLgMPwl+beiVc9EN MjIrODfOtgHA0iDh6IHrRRMU7AFZ5Yg3ePJQW5kVnEFlDwhAfaitjMp2HnxX9haEg8yNplOoFKy0 JZDlJ8EvC6M8793colMyMis49cpmAWBJSTh64P57+K7sLQix5BAg3lqwr/BbsuUdkK3DQ5tcwNap 4KAtgSw/CX5t6JVHz42zMio8Qc22AcDSIOHogoe4K3vuK1yP5hAw3lxwLfQtYfg5sMliAHcvpUZm BaeX2SwALCkJRw88dl7RKhY8NQQRbyy4adsjyzsgWy9LLWDrWHD+fvwF1fCT4NeGVnnPhyf+veUG WZkVnCVm2wBgaZBw9MBzPfGuLBTEq5oUwhjvV7DQpZrlHVBY37VAWMeCsN8cW1d+EvzaYJXzlyZo xgYN1+6dLvsQ0waw9GG4du/08YVbX6Msexywo47IyKzglDp7QADKQzUyKxevTxUKnl9tG5wQtWCn 3ZIsPwl+WVjlTr+1iJSMzApOqbNZAFhSEo4eeC0bf97CKO+nhkDxloKDnhBYfhL8sjDKmvZ3UCkZ mRQxpc5mAWBJSTi64HHh74Gh4NhqCBBvLbho2KzlJ8EvC6uc26onHlqZFZxSZ7MAsKQkHD3wPRi8 sQ8FcUR3CoHiLQU3LUFj+Unwy8Io2+93rTolI7OCU+psFgCWlISjC4rNG0LBfdcQIN5ScP3owbDl HZCt4/zNVMDWqWCh+R2WnwS/Nlhl/8VPnGiQkVnBaYC2DQCWBglHF7x5fapQEO/8UwgUbynY+KRq +Unwy8Iq97buTkqtzArOWLRZAFhSEo4e+Gw/vD8JBWGEbg6B4i0FO/1WZvlJ8MvCKPv5e/S8Tiuz gjMWbRYAlpSEowtevLvwW7DE+8MUAsRbCw6aumj5ObDJwijHLwfPKRmZFZyxaLMAsKQkHB3wjZ3X pwoF4SOWQ4B4a8FF63lafhL8srDKvq2bTsnIqPCMRZsFgCUl4eiCZ7h5pnj3/BGOIVC8peCmnb0s Pwl+WVjlTpczKqVWZgVnLNosACwpCUcPXH68XFIoiCO5UggUby54/1LjR7XlJ8EvC6Oca7raESkZ mRWcsWizALCkJBxdcL/5fvxc46i9HALEWwsWWqra8nNgk4VVznxec0pGZgXn/9ksACwpCUcXFCvI hYL4EU4hULylYKPNqizvgML6qAXCOhbstJGT5SfBrw1Gufb1uXWDjMwKzlm0bQCwNEg4euB7W86P Aq59W74QIN5acNJGTpafA5ssrPJ+oW06JSOzgtMrbRYAlpSEowte4Qddivfezl8NgeItBRdt5GT5 SfDLwij3+rtOnZKRWcHplTYLAEtKwtEDt3XhRwFhNsVWQ4B4a8FDGzlZfhL8srDKme7URUpGRoWn V9osACwpCUcXPHmdsVAQLjZyCBRvLnh+tJGT5SfBLwujPL90OSNSMjIrOL3SZgFgSUk4euD+u/l+ /C2If4BSCBBvLVhoIyfLT4JfFlbZ4/WPSsnIrOD0SpsFgCUl4eiCB8/ZCgXHXkOgeEvBRhs5WX4S /LJolfv3foh3mZKVWcHplTYLAEtKwtEFH15nLBSExfxzCGO8X8FOnbW8AwrroxYI61hw0k5Dlp8E vzZY5dziiHhukJVZwZmdtg0AlgYJRw884klI8Z7pgUcKgeItBRftNGT5SfDLwijLL+6EolIyMis4 JdRmAWBJSTi64M3rjIWCeOWbQoB4a8FDf9AtPwl+WRjlDSHNn+SUjMwKzl61WQBYUhKOHvhe/K/4 vfQWxAm1KQSINxc8vx/tNGT5SZAnoQbl3HRKRkaFZ6/aLAAsKQlHFzxpiSZ7QINyuYf6yazggCF7 QAC6h3q54BUGmopT6Nlro/kUSgUrzXG3vAOidRyJmwvQOhfgvarlHVBYP7VAWMeCncZEWn4ObM4A q+y/uC5lOjeGQU6dLk+B6+jWR8xgOQWGQU6dPr5w62uUsCjNoo/IyKzgZEl7QADKQzUyKvfOKzWF gudrG5wQteCkhUos74BoHde7yAVonQsuetZpeQdk6+WqBWydCh6aN2D5ObA5A3pw/elzw8io8AxE ewYAWM4N4eiBjxhKGQvOGgLHGwuWH63dZHkHFNZPLRDWsSDM9GXryjsgW4e9nHMBW6eCjTZEsfwk +J0BA7h750Yjo8Kz5u0ZAGA5N4SjB17Pg88BY8FdQxDx3n68VZ4FcfL7G8J6XzolI6Pi9iVnAWBJ STh6oOiLOSCjXHu6nROHamRWcP6sPSAA5aEamZWdR2+EgnCQ+hSqBQetiGh5BxTWRy0Q1rHgpI1t LD8Jfm2wyh2HHqoGGZkVnD9r2wBgaZBwdMGLl+4NBetaQ6B4S8FFG9tY3gGF9VkLhHUseGjTF8tP gl8bjPLW//QEZyuzgrNRbRsALA0Sjg74XirzcMxQkPKPIUC8pSD8ZA5fUIZ3QGF91QJhHQtW2hDF 8pPg14ZeiT+liwYZGRWecGnbAGBpkHB0wY2HUMeCs4bA8aaCjTZEsbwDCuunFgjrWHDQZiGWd0C2 PpZawNap4KTdLCw/CX5nQKu817pL2FxQnBtWZgXnetozAMBybghHFzx4/4xQ8HwhjPF+BTftZmF5 BxTWZy0Q1rHgobt4y0+CXxs6ZU3TGbFBVmYFJ1DaNgBYGiQcXTAOnsN41zDWJIeA8aaCbaFRv5Z3 QGF91wJhHQtW2gXB8pPg1war3GkpEtWgVkaFJ1DaNgBYGiQcPXCJA8so3vcw1xoCxVsKNnoKbHkH FNZXLRDWseCgiRCWnwS/NhhlPdf486RokJFZwatr2wYAS4OEowvGgWUQ73puYU5zDgHirQUnLXpv eQcU1mctENaxAH+dsvwc2LTBKOd6HItukJFZwatr2wYAS4OEowvGQVcQ71twXjUEiLcWPDT1zvIO yNbXWgvYOha8Zyw82LS8A7L1fdYCtk4FK/1gb/lJ8DsDrPJeqDz63DAyKjzhxJ4BAJZzQzh6YJyM jfGmPURyCBRvKdhpNrLlHRCt47oauQCtc8FBa59a3gHZOizalgvYOhWctAq05R1QWF+1QFjHgptW SLa8AwrrpxYI61jw0OrBlndAtl6XWsDWseBYaGVdy8+BzUduAHfnw9jKrODtuf3IAVg+jMLRBeOI RhHvXUMQ8d5+vFWeBWsWRrmWX3ggoFIyMit80WuyALCkJBxd8OHx0KEgbJ2u460FKy1cbHkHFNZX LRDWsWCnRX0tPwl+bbDKfhzfxLNh9ECn6z70A4EyWPowjB7o9PGFW99P2f/6vW/wUadUL6PCs5Ts AQHIh9rLqGw4kiUWnOEmJLetPyHagmNcC7jnHVBY37VAWMeC6zdc+/b8HNi0wSjrmh7bUoN6mRW4 TO/bAGBpkHB0wZ3WpksF61ZDgHhrwT2uBdzzDiisr1ogrGPB8wwXoD3vgGwdf8ZLBWwdC85lXCe3 5yfB7wwYwF2fG0ZGhaZf9GcAgOXcEI4euOPgjFzw1BBEvLFgvcUxf7wDsnXYli8XsHUq2MdVZ3ve AYX1UQuEdSw4xrlTPe+AwvqqBcI6Flzjiqw9Pwl+J59VziXOqlKnZSuzAhes/ckHYDkthaMLxh+V Kd4zjtTJIVC8peAeVyvteQcU1nctENah4L35HB4j9rwDovUaH72lArTOBcu41GTPO6Cw3muBsI4F 27hrXc/Pgc3JZ5TtF1fezqdldwE66PrsswMPKljOvn+KFy768MLG1yr3tq/6iIzMCl9HmgMCUB9q K7MSf/yHE+ItOJ7aNjghasE+LkfQ8w7I1udeC9g6FRzjusw9Pwl+bTDKfm6L0yAjk4Jj3fs2AFga JBw98Ig//kO8b0EcbplCgHhrwTUOX+15B2Trba8FbJ0K7nGFlp6fBL82GOW9lt0P3SAjs8IXc6YN AJYGCUcXxBEQqeBcaggQbym4f+MyjD3vgML6rAXCOhYs4xKFPe+AbB2e/eUCtk4F27h8X89Pgt8Z 0CrL+ybCp1KcG1ZmBQbm92cAgOXcEI4uiIMvUkF43pJDGOP9CvZxDb2ed0BhvdcCYR0LznF9uZ6f BL82WOU64tU5N8jKqNDA/L4NAJYGCUcPPHHwRSq4vhAo3lJwjevL9bwDCuu7FgjrWHCPa6/1/CT4 taFXntVpUCuzgtdgtg0AlgYJRxfEn+hzwVVD4HhjwfMb117reQdE6/P3qwVonQuWcV2ynndAYb3W AmEdC7Zxza6ed0BhvdcCYR0L9nE9q56fA5uTzyjLcsSvOHFaGhkVGkLbn3wAltNSOHrgtdJqCang +tUQIN5acI6LSvW8AwrroxYI61hwjQsu9bwDsnVYHS0XsHUqeMbFiHreAdk6DslMBWz9Fqy/32+c It3zDiist1ogrGPBMi5i0/OT4HfeW+XYt2889fAkotPliX/ZwRMVLCf+8CSi08cXbn2Nsm5bmE2v jsjIrPB1pDkgAOWhGpkVHMWRCsIvibltcELUgm1cdqfnHZCtj6UWsHUq2Md1Lnp+EvzaYJQtjHXV DTIyK3wdadoAYGmQcHRBHKmSCtazhgDx1oJzXBem5x2QrbelFrB1KrjGNVN6fhL82mCUfUsD1USD jIwKDc/u2wBgaZBw9MA7jpSAeN9vifeCqYQA8daCZ1wzpecdUFhftUBYh4LlN64n0vNzYNMGoxxL HizNDTIyKzA8u28DgKVBwtEF47gDiPctCOtA5hAg3lqwjkuZ9LwDovX522oBWueCbVxsrucdkK2X sxawdSo4xpUren4ObM4Aqzzxp1p1bhiZFb5MN2cAgOXcEI4uGIc8ULzPHh6D5xAo3lJwjvPBe94B hfVZC4R1LLjG5SN6fhL82mCUsKvNphtkZFZgZHjfBgBLg4SjC4pxH6FgeWoIEG8teMa97HreAdk6 DCHMBWwdC9bfuA97z0+CXxuM8jx3vJkXDTIyKjSIvW8DgKVBwtEDHzHuIxSElSpyCBBvLVjH9Q16 3gGF9VELhHUs2MZ92Ht+Evza0Crrb7t/apZBL7PCV9emDQCWBglHFxRjW0JBWEk7hzDG+xWE7WfR +uMdUFjftUBYx4Jz3Ie95x2QrfdfLWDrVHCPc/97fhL8zoAB3OS5YWVUaDh3fwYAWM4N4eiAx08M MIkFdw1BxBsLnnEf9p53QLaO99qpgK1jwfYb5/73vAMK670WCOtYsI47fve8AwrrsxYI61iwjZPT e34S/E4+q1znvdfTcniO1unq7EvnGIDl7Bueo3X6+MKtr1HCtfCjj8jIrOC1sj0gAOWhGpkVMawm FOxf2+CEqAXHuCl2zzsgW4cR9LmArVPBOU6n7/lJ8GuDUdYrzvtTDTIyK3itbNsAYGmQcHRBMawm FJx3DQHirQX3uLd1zzsgW4eV33MBW6eCZ5xO3/OT4NcGo2zHFVcJFQ0yMit4rWzbAGBpkHD0wEUM qwlL+C6/GgLEWwr2ZdxzqecdUFgftUBYx4J1nE7f8w7I1vFaLRWwdSrYxsXaen4ObM4Ao+zvteyq zw0jo8ID7+0ZAGA5N4SjC8YBOxDvW/A8NQSItxYc43T6nndAtL7ig7ZUgNa54Bx3GO75ObBpg1He /zxu3SAjs8LXyqYNAJYGCUcXjAN2IN73P6+jhgDx1oJ7nNPe8w4orJ9aIKxjwTPuzNnzk+DXBqvE rzjZICOzgpMLbBsALA0Sji4YB+xQvO8X11VDoHhzwXspSg8gDO+AbL2ttYCtU8E67r7b85Pg14Ze iSMvVYNaGRUetG7bAGBpkHD0wDUOXeF44z1kCoHjTQX7uKRXzzugsN5rgbCOBce4M23PO6CwPmuB sI4F5zhvv+cdUFjftUBYx4J73NG05x2Qrc9fLWDrVPDQFGbLT4LfeW+V91Ny1U/EeE9udXnir/3I qgyWE3+8J7f6+MKtr1HC8Dw98cTKrPBlujkgAOWhGpmVi4d4rXHtqNo2OCFKwbmM+5P2vAOy9bnU ArZOBStNurb8JPi1wSpPnFmlGmRkVHheg20DgKVBwtEDNzGMLRScRw2B4i0F+7jpZ887IFtfv1rA 1qngoJnPlp8Evza0yhYGQe+yQVZmha+VTRsALA0Sji4oBoWFgmupIYzxfgXXuHdnzzugsD5qgbCO Bfe4glTPT4JfG4zyfhzTUHFskJVZwWtl2wYAS4OEowuKQWFbmAO01xAg3lJw/cZ9LXveAYX1XQuE dSxYaHa35R2QreNVeCpg61Swjvsh9vwc2JwBRnmvo+O+AeLcMDIreJluzwAAy7khHF1QjEcLBfFS OIUA8daCfdwPsecdUFg/tUBYx4Jj3GSw5yfBrw1WObf4C7pokJFR4Wkjtg0AlgYJRw/cxXi0ULAu NQSKtxRcNB/c8g4orM9aIKxjwT3uFdjzk+DXhl6Jl3WqQa3MCl6D2TYAWBokHF0wDkrieMNdTQ6B 440F94/mg1veAYX1VQuEdSxYxn30et4BhfVTC4R1LNhorrTlHZCt46OKVMDWqWAfN27r+UnwO/ms 8qTVUtVp2cqgqKkx9uQjMJ+WwtEDjzgUi+J9jvBzcw6B4i0FB01YtrwDCuunFgjrWHCN26D1vAOi dRoqngrQOhfcNJnX8nNgcwYY5f0crN+5MTxt6XR5Chz9mLkC5lNgeNrS6cMLG1+jvJfh96qPyMis 8GW6OSAC1aEamZU4bg1OiLcg/jyV2gYnRCl4fuMecz3vgGgdpnGWArTOBQtNP7b8HNi0wSj3Fu+w VIOMzApfK5s2EJgbpBw9UAzeCwXxwUQKAeKtBdu4OV3PO6CwPmqBsI4F+7gJWs9Pgl8bjPIsx6Gn TVmZFb5WNm0gMDdIOXqgGLwXCuIwkBQCxFsLznFnsZ53QGF91QJhHQsummJt+Unwa0Or7L84f0Q1 yMqo8Kwc2wYCc4OUowOeYoBiKEifrIt2FmsL7nFnsZ53QGF91AJh/RYsvx+tvmT5SfDAKUhh3fpd T5uyMis4gci2gcDcIOXogWK4Xyg4vxAg3lqwjDuL9bwDsnVofS5g61Sw0cxoyzsgW99bLWDrVLCP u271/CT4nQFWeeIwU3VuGJkVvBWxZwCB+dxQjh4oRhruYVnDXw2B4i0FJ82MtrwDCuujFgjrWHCN G4T1/BzYtMEo7zXWsukGGRkVnrtk20BgbpBydMBLjDQMBduvhgDx1oKHZkZb3gGF9VELhHUoWH7j BmE9Pwl+bTDK+d5KLbpBRmaF/1KbNhCYG6QcPTAOSoJ434IwfDiHAPHWgpVmRlveAdn62moBW6eC bdwgrOcdkK3DtOxcwNapYKepu5Z3QGH91AJhHQvOcfOsnndAtg4Lu+QCtk4FF01rtbwDCuutFgjr WPCMG0v1/CTIM4MieOkPo5FZwXtk+5EjMH8YlaMHbrQ/eCxYlqeGgPG2BWDdyHNgk4VVtjs+gFMp tTIqPN/KZkFgTkk5OuAdx/dRvNv9h3hzQfh1l76pWt4B2TpMZM4FbJ0K1nHDr553QLZ+79pKAVun go1m1Fp+EvzOAKs8YaniOqWuf4ba6fIUuPuBmAXMp8DwcLbTxxdufY1yhQtpfURGZoUv080BEagO 1cisiBGhoeB8atvghKgFx7hFWc87IFvHv+ipgK1TwUkTcS0/CX5tMMp93auei2dlVvgy3bSBwNwg 5eiBYtRrKNi/ECDeWnCN27D1vAMK66sWCOtY8NASSJafBL82tMqxLPezywZZGRWe6mXbQGBukHJ0 wEeMIX0LnjBePocwxlsLtt+41VzPO6CwPmqBsI4FK03dtfwc2LTBKscdn+pyg6zMCl5b2DYQmBuk HD1QjCENBcEzh0DxloJt3Aut5x1QWN+1QFjHgoOm7lreAdH6CYu25wK0zgUn7bpl+TmwOQMGcHfO jVZmBSfE2TOAwHxuKEcPFMNXY8FTQxDxxoKbpu5a3gHZel1rAVungod23bL8JPi1wSjb/cQxdKJB RmYF7/RsGwjMDVKOGnzvjnj4aiiIP3ukECDeUhBmCvGb/XgHZOv7VwvYOhWstEGY5SfBrw1G2bcw h1E2yMio8IQ42wYCc4OUowfG0akQ71sQhiLmECDeWrDR/FnLO6CwPmuBsI4FB+0sZvlJ8GtDr4TB W6pBRmYFr65tGwjMDVKOHhhHp3K8YV+vHALHmwpOmj9reQcU1lctENax4KZN0Cw/CX5tMEqYbr3q BhmZFb66Nm0gMDdIOXpgHJ0K8b4FYZWDHALEWwsemj9reQdk67CPRS5g61jwXtXCs2/LOyBbh1Vo cgFbp4KVltax/CT4nQFGuY7wL/LcMDIqPO3PngEE5nNDOTrgIkYHh4Kwj0UOAeKtBTtt9GZ5B2Tr c60FbJ0KDpoSavlJ8GuDVZ64GIxqkJFZ4atr0wYCc4OUowfGwb8U7xMX+ckhULyl4KRt0yzvgGwd n4+lArZOBTdNCbX8JPi1oVfu02lQK7PCV9emDQTmBilHDxQjoENB/OUshcDxpoKHtk2zvAMK670W COtQcC40JdTyk+DXBqM8T/qeFg0yMio87c+2gcDcIOXogKsYT3zEnWJqCBBvLVhpvzXLOyBbxz/E qYCtU8FOU0ItPwl+bWiVM+yQ+ZMNsjIrfHVt2kBgbpBy9EAxnjgUhDH+OYQx3q/goP3WLO+AbB3m H+cCtk4FF83LtLwDsvV91AK2TgU37UVm+UnwOwOscoWHeOrcsDIreGFvzwAC87mhHD1QDGV+C8La OyUEircUPDQv0/IOKKzPWiCsQ8F7RQqPcy0/BzZtMMob3++nG2RkVvDq2raBwNwg5eiBYihzKFi+ ECDeWrDSvEzLOyBbxwc4qYCtU8FO+61ZfhL82mCU9UpPbkSDjIwKz6q0bSAwN0g5OuAmhjKHgvhg OYUA8daCg5alsbwDCuuzFgjrWHDRfmuWnwS/Nhhl37b4HF00yMis4NW1bQOBuUHK0QPjSGWId097 LeUQIN5acNPcU8s7oLA+aoGwDgX3j/aUs7wDsnUYNJ4L2DoVLDTV0PKT4HcGWOUN8NbnhpFZwQt7 ewYQmM8N5eiBcZA0xXst8bYohUDxloKVtr+zvAMK66cWCOtYsNNUQ8tPgl8bjHK8Hdt0g4yMCk8B tW0gMDdIOTrgHgdJQ7xvwfmFAPHWgoM2k7O8A7L1tdcCtk4FF001tPwk+LXBKOd7F7PqBhmZFb66 Nm0gMDdIOXqgGCkeCq6nhgDx1oKbNpOzvAOydZxTlArYOha8QdIfXMNPgl8bjPJeBYbredUgI7PC V9emDQTmBilHDxSj4UNBvMRKIUC8tWChzeQs74DC+qoFwjoWbDTV0PKT4NcGq1xbmqPODTIyK3x1 bdpAYG6QcvTAOBqb4n2vYH81BIq3FOy0C53lHVBYH7VAWMeCk+b7Wd4B2Tr8jJkL2DoVXLRDm+Un we8MMMqzLPelzw0jkyJmn9ozgMB8bihHBzzEaPi3YA2eOQSItxbcNN/P8g4orO9aIKzfgrgSBObc 8HNg04ZWud6QwvBz0SArs8JX16YNBOYGKUcPFGPLQ0G44c0hjPF+BQvN97O8A7J1uBnMBWydCjba oc3yk+DXBqs8axyByQ2yMio8ndK2gcDcIOXogKcYgXyFb/CjhkDxloKdJilZ3gGF9VMLhHUsOBd4 nGt5B2Tr8BtNLmDrVHDRUiCWd0BhfdQCYR0LHtpozfJzYHPyDeDlnJatjApP/LYnH4H5tFSODniI uRKhIAw9yCFwvE0BWX/yJPhlYZTwcG7TKRkZFZ7ca7MgMKekHB3wFMPaQ0H6ZKl4S8H77Ud/9Qzv gGwdJuPlArZOBQttgGf5SfBrg1HyCCbVICOzghf2tg0E5gYpRw+Mo9Yh3jwoLocA8daCjabpWd4B 2Tp+Z6YCtk4FO+3VZ3kHZOswKC4XsHUqOGkKm+Unwe8MsEpYBVafG0ZmBS/s7RlAYD43lKMHxgHz FO+xhl+ccggUbym4aOc7yzugsN5rgbCOBQ9NYbP8HNi0wSrP9ludBrUyKjyB2baBwNwg5eiAVxww T/HmS6wUAsWbC8I1Er/Zj3dAto5f16mArVPBSlPYLD8Jfm0wyhmWC9QNMjIrfGFv2kBgbpBy9MA4 YB7ifZXrCwHirQUbbZlneQcU1k8tENaxYKd5ZJafBL82GOXewkNp2SAjs8LXYKYNBOYGKUcPjAPm Id47rslVQoB4a8FJW+ZZ3gHZettrAVungovmkVl+EvzaYJX3IuvWDTIyKjwd2LaBwNwg5eiAt5g1 EArWLwSKtxQ8tGWe5R1QWD+1QFiHgrAZBnxdGN4B2XpfawFbp4KVtpOz/CT4nQFGefZwtshzw8is 8IW9OQMIzOeGcvRAMWEhFJxfCBBvLdhoHpnlHVBYX7VAWMeCg7aTs/wk+LWhVe4w7vSUDbIyK3x1 bdpAYG6QcvRAMWEhFNxrDWGM9ys4aR6Z5R1QWF+1QFjHgou2zLP8JPi1wSjbcZyPbJCVWcGra9sG AnODlKMHigkLoSCM4s8hQLy14KHJXJZ3QLYOkylyAVvHgv1Hu/tZfhL82mCV93p+0w0yMio8adq2 gcDcIOXogI+YsBAKwi+MOQSKtxSsNJnL8g7I1mEmbC5g61Sw0V55lp8Evzb0SpxtpxrUyqzgNZht A4G5QcrRA+OodY733GoIHG8qOGgyl+UdUFiftUBYx4KT9sqzvAMK67sWCOtYcNNEJ8s7IFuHRZBz AVungof2kbO8AwrrrRYI61AQtkTnE/vjJ8HvvDfKHsb+1k/EsGBcp+sTv59UUcB84g8LxnX68MLG 1yhhcZCfPiIjo8LTtu0BEagO1cikXL84sQFOiLCN9lXbBidELVhpyzzLOyBbhwfCuYCtU8FGc4cs Pwc2bbDK80szmblBRmaFr5VNGwjMDVKOHhgnNlC8Txy8mEOgeEvBQVvmWd4B2Tqsf50L2DoVnDR3 yPKTIM9Rv89ri0uhiQYZmRW+VjZtIDA3SDl6YJzYAPGeafpHDgHirQU3bZlneQdk622pBWydCh6a O2T5SfBrg1Gu+OBGNsjIrPC1smkDgblBytEBFzG7IxSsXwgQbykIKxTAMRveAYX1WQuEdSxYae6Q 5SfBrw1Gua/8aeYGGRkVnrZt20BgbpBy9EAxuyMUhCkPOQSItxbstC2g5R2QrcPPc7mArVPBQRN4 LO+AbP2ctYCtU8FJW+ZZfhL8zgCjPMdy7/rcMDIrOGPcngEE5nNDOXqgmFjyFqQfoVMIEG8tuGkC j+UdUFgftUBYx4KHdvez/BzYtKFVnjDfdZUNsjIrfHVt2kBgbpBy9EAxsSQUxGciKYQx3loQTpvx NLa8A7J1fCaSCtg6Fay0V57lJ8GvDUZ5b+6XRTbIyqjw5HbbBgJzg5SjA65iYkkoiKORUggQby3Y aQKP5R2QreNopFTA1qngoL3yLD8Jfm3olV2vPmBlVvDq2raBwNwg5eiBYmJJKAhrE+UQON5UcNEE Hss7oLDea4GwjgU37ZVn+Unwa4NR9js9FRcNMjIreHVt20BgbpBy9MA4bwTi3e/020MKAeKtBQ/N orG8A7J1eHKQC9g6FtwL7ZVneQdE6zOMAs0FaJ0LVpphYvk5sDkDjHKs+77qc8PIqPCEfHsGEJjP DeXogFucsgLxvgVhHdocAsRbC3baZM/yDsjW8bl8KmDrVHDQDBPLT4JfG3olrKStGmRkVvDq2raB wNwg5eiBccoKxxt/hE4hcLyp4KJN9izvgML6qAXCOhbcNBnA8pPg1wajnL80tk00yMis8NW1aQOB uUHK0QPFvJ1QcH0hQLyl4PnRJnuWd0Bh/dQCYR0LFppFY/lJ8GuDUa7VbZCRWeGra9MGAnODlKMH xnkjEO9bEMeGphAg3lqw0SZ7lndAYf3UAmEdC3aa5mH5SfBrg1Heq6y4apVokJFR4Qn5tg0E5gYp Rwfc47wRiDfenNQQIN5acNBGgpZ3QGF91QJhHQsummtheQdk63jLkArYOhXctJGg5SfB7wywyrlc lz43jMwKX9ibM4DAfG4oRw8U83ZCwbPXECjeVLCFxTL5zX68AwrruxYI61iw0E53lp8EvzZ8yvHX 7/fLPYcG9TIrfHVt2kBgbpBy9MCL5u2kgvChziH08bYF2zjXoucdUFhftUBYx4J93JSv5yfBrw1W ueMkamxQL5OCyxb0bSAwN0g5OuCB83ZSQfiFMYdA8ZaCc5xr0fMOKKzPWiCsY8E1bnHX85Pg1waj vN+y5083yMiswNV13wYCc4OUowfivJ1UcF01BIi3FtzjXIued0C2vpdawNaxYPmNW9z1/CT4tcEo 733jceoGGZkVuLru20BgbpBy9ECct5MKrrWGAPHWgmWc8NDzDiisr1ogrGPBNm5x1/OT4NcGo+x7 +hFfNMjIrMDVdd8GAnODlKMH4rydVLDdNQSItxbs44SHnndAtt7XWsDWqeAc98br+Unwa4NV3g6s ukFGRoXWDujbQGBukHJ0wDNOy6F408PUHALFWwquccJDzzsgW4d77VzA1qngGffG63kHZOv7qgVs HQvCxlbUqZafBL8zwCjvp3K79blhZFb46tqcAQTmc0M5emCcEQTxvgXHUUOAeGvBMu6N1/MOKKyf WiCsY8E2Tgbo+Unwa4NRXiGOrRUNMjIrfHVt2kBgbpBy9MA4IwjifQvCDM8cAsRbC/Zxb7yed0Bh fdcCYR0LznEudM9Pgl8bjPJ+8cShy6JBRkaF1jvo20BgbpBydMArzgiCeN+CJgSItxZc4954Pe+A bB3vtVMBW6eCZxzD3/OT4NcGo9x7XBFRNcjIrPDVtWkDgblBytED44wgiDf88PerIUC8pSBMQYQv KMM7oLA+aoGwjgXrOIa/5yfBrw1GedYjzukVDTIyK3x1bdpAYG6QcvRAnBaVCsJgtxwCxFsLtnEb v553QGF91wJhHQuOcQx/z0+CXxtaZfn90q0YN8jKrPDVtWkDgblBytEDcepXKog3vCmEMd6v4By3 8et5BxTWVy0Q1rHgGsfw9/wk+LXBKMua/gJzg6yMCi3N0LeBwNwg5eiAN06kSgVh0mgOAeKtBc+4 jV/PO6CwvmuBsA4F+28cw9/zDsjWYT3EXMDWqWAdt7jr+UnwOwOMsu9x30l1bhiZFby6tmcAgfnc UI4eiHO4UkGYV5lDgHhrwTYOpO95B2TrMJQ+F7B1KjjGLe56fhL82mCV+/6dukFGRoVmmPdtIDA3 SDk64IPzQVJB/FCnECjeUnCOA+l73gGF9VULhHUsuMe98XreAdk6fahv2huvLXjGQeY974DCeqsF wjoUvGcPPOq0vAMK66MWCOtYsI4DsHveAYX1XQuEdSzYxj3Ven4S/D5yvXL8nA9jK6NCa7v0HzkC 84dROTrgjTMxc8FRQ+B4mwK0rvIsWLMwyrHecal6kZKRUaFVHvosCMwpKUcHfOLMKYj3LVjdeGvB MY5v73kHZOuwLnwuYOtUcI5b1vX8JPi1wSpnXAeyrKZhl1IYdNmHx84z+8Dch3+qF876+MKtr1HO O/yFkEdkZFb4Mt0cEIHqUI3MSpzrBSfEeZ/L1zY4IWrBPQ6L73kHFNZHLRDWseAZN9nr+TmwaYNR rjPebaoGGRkVWsmibwOBuUHKUYP3L871gnjfgvupIUC8peBtEx2z4R2QreM4s1TA1qlgHfcD7PlJ 8GuDUd4LinPRDTIyK3ytbNpAYG6QcvTAONcL4n0L4oOJFALEWwu2cVh8zzsgW4dJArmArVPBMe4H 2POT4NeGVll/vzRYhRtkZVb4D7xpA4G5QcrRA+NcrzHetTxySiGM8X4F5zgsvucdkK3jkKBUwNap 4B73A+x5B2Tr56gFbJ0KnnHIeM9Pgt8ZYJU73a3zuWFlVGgRjf4MIDCfG8rRAReca5cKwsD4HALF mwuuZdwPsOcdkK3jM5FUwNapYB3Hbff8JPi1wSjLelxOg4zMCt5u2TYQmBukHD0Q59qlgjh6I4UA 8daCfdwPsOcdkK2ftRawdSo4aNy25SfBrw1Gee+t48+jokFGZgWvrm0bCMwNUo4eiHPtUkFYHzqH APHWgmvcSLDnHZCt44/QqYCtU8FN47YtPwl+bTBKGKW06wYZmRW8urZtIDA3SDk64Ipz7WLBGVY/ ySFAvLXgGTcS7HkHFNZHLRDWoeBeaNy25efApg1GOc73Ikk3yMio0HoffRsIzA1Sjh6Ic+1SQbzO SSFAvLVgHTcS7HkHFNZnLRDWsWCncduWnwS/NnTKnZbt4AYZmRW+ujZtIDA3SDl6IM61SwX7U0PA eHPBMW4k2PMOyNZhjYxcwNap4FroutHwk+DXBqOEG5tLN8jIqNByEn0bCMwNUo4OuMUJVxDvW3B/ IUC8teAeN0vseQcU1nctENah4PnRuG3LOyBah1lGpQCtc8Ey7nTX8w4orPdaIKxjwUoDiy3vgML6 rAXCOhbs4y5wPT8HNuf9AD76E2FkVGjpnP68JzB/IpSjA64wNbc/IKM871WWc6hGRoXWKOkPiEB1 qEZGZYuz+OAUeguOr9FwCtWCgwZPW94B2To8OcgFbJ0KrnFTvp6fBL829EpcfUA0yMis8NW1aQOB uUHK0QPjLD6ONyxnkEPgeFPBTYOnLe+AbB2ffKYCtg4F+3s/RU84DT8Jfm1olfeuKKzeqxpkZVRo jZK+DQTmBilHB9zjLL4x3lAQNtHKIYzxfgULDZ62vAMK67sWCOtYsI2b8vX8JPi1oVfijB5ukJVZ watr2wYCc4OUowfGWXwcbxjslUPgeFPBToOnLe+AbB2+M3MBW6eCY9yUr+cnwa8NRtneC+hTN8jI rODVtW0DgblBytED4yw+iHdbj/TFddBufm3BRYOnLe+AwvqqBcI6Ftzjpnw9Pwl+bbBKvskWDTIy K3ghZNtAYG6QcvRAMZUxFIRHGTkEijcXLD8aPG15BxTWRy0Q1rFgGXfz63kHZOuw+kkuYOtUsNHo XstPgt8ZYJSweN2lzw0jk4IrufRnAIH53FCODniIWZRbXhkwhwDx1oJ93M2v5x1QWN+1QFjHgpNG 91p+EvzaYJTrF/dTVA0yMit4dW3bQGBukHL0QDGLMhSsRw0B4q0F17ibX887oLB+aoGwjgU3DUm0 /CT4taFX4hIAokFGZoWvrk0bCMwNUo4eKGZRxoK7hsDxxoL1N+7m1/MOyNZhlbFcwNapYKHJjZaf BL82DODmNuiTUeGVXGwbCMwNUo4OeIpZlLHgqiGIeGPBNu7m1/MOyNbx4jkVsHUq2GmUtuUnwa8N RrnPbXcaZGRW+OratIHA3CDl6IFiFmUoaEKAeGvBOe7m1/MOKKyPWiCsY8FFg3ItPwl+beiV69YN MjIrfHVt2kBgbpBy9EAxizIUhF8rcggcbyp4xh0Le94BhfVZC4R1KNh+NCjX8pPg14ZW2cP2tD/Z ICuzwpe4pg0E5gYpRw8UsyhDQRj4l0MY4/0K1nFzxZ53QLaO99qpgK1TwUaDci3vgGwdBv7lArZO Bfu4jV/PT4LfGTCAlzw3rIwKrz5jzwAC87mhHB3wivMzMd4nLLKfQ8B4c8FJg3It74DC+qwFwjoW XOM2fj0/BzZtMMr2W+OPnqJBRmYFr8FsGwjMDVKOHiimMoaC5a4hQLy14KGRsZZ3QLZet1rA1rFg /43b+PW8A7J1WOkyF7B1Klhp1KjlHVBY37VAWMeCbdzirucnwe/ks0rYLFaflkZGhdfvsCcfgfm0 VI4OeMepdBRv+AqvIVC8peCgUaOWd0Bh/dQCYR0LznFvvJ53QLYOz+xzAVungotGVFreAYX1XguE dSx4xn3jen4S/E4+q9ztaTnMMOx0efbd/XTLAuazb5hh2OnjC9/qiPdziZ9NcURGZoWvI80BEagO 1cisxAmEcEK8BfF7P7UNTohScPxoDKjlHZCtwx5suYCtU8E67nTX85Pg1wajHGkJY9UgI7PCF3Om DQTmBilHD4wTCCHeIy1NnUOAeGvBRmNALe+AwvqsBcI6FhzjTnc9Pwl+bTDK+f6B0AvhWBkVXhLG toHA3CDl6IBPnEAI8Z7vJ+tXQ4B4a8FJY0At74DC+qgFwjoW3ONOdz0/BzZtMMqVF/0VDTIyK7gk jG0DgblBytED4wRCiPctOL4QIN5a8NBwPcs7IFvHZ3ypgK1jwRsLPXYxvAOydRh3lAvYOhWsNBDT 8pPgdwa0yvudF6/hxLlhZVb4WtmcAQTmc0M5eqCYwBkKwuDFHMIY71ewjZvy9bwDsnWYpZsL2DoV HDRI0fKT4NcGq5zp9ztukJVR4SU0bBsIzA1Sjhp8fmIyWCiIv5KmECjeUnCOm/L1vAOy9b7UArZO BTcNUrS8AwrrvRYI61jwjBvW9bwDCuuzFgjrUHAtNIDP8g4orO9aIKxjwTpu5tbzDsjWYRWeXMDW qWCnwW2WnwS/j9wAbs6HsZVZwQW37EeOwPxhVI4eKKZhx4KrhiDivfx4qzwL1iyMsv1+YeyZSsnI qPAKIDYLAnNKytEBFzH7LhTcmxdvLTjGvfJ63gGF9V0LhHUsOGnsoOUdEK3jHWcuQOtccI8b0PW8 AwrrvRYI61jw0OA2y8+BzclnlX1bHn1aGpkVviozJx+B+bRUjh4o5hyGgu2qIVC8ueBexg3oet4B 2Tr+aU4FbJ0KVhrcZvlJ8GuDVdJe1rlBw9PDTtd96CdgFjD3YXh62OnjC7e+RjnCfAF9REZmha8j zQERqA7VyKyIWZKhIPxkntsGJ0Qt2GnLPMs7IFvHL99UwNap4KDheJafBL82GOVe45eyapCRUeEl XmwbCMwNUo4OuIqZoG9BWPmjhADx1oKLtsyzvAOydXwIlQrYOhXcNBzP8g7I1vGnyFTA1qngoe3k LD8HNmeAVd7/tutzw8is4Ooy9gwgMJ8bytED4/xLivd8z8UaAsWbC95rDvqraXgHFNZXLRDWsWCl 7eQsPwl+beiULS7BqBrUyqzgGiS2DQTmBilHB9ziLD2MN+7qmUPAeHPBTsPxLO+AwvqpBcI6Fhy0 nZzlHZCt16UWsHUquGiomuUdUFjvtUBYx4Kbtlqz/P9f2ZkkS27DQHTvwzg0Dyfy0ivf3+JQlJJ6 iWh50ZuH/MgAaBZLRYofhffgE3IO+ZGcG5aCkfCbV3TwkbAOS5cxEuaziVDeKyAvP0oRoLw1YB0G 2i+m+kDIqdPyowZw6hIw0q1wqv8ovNugZMmbcH9vuHmthZX7PvQnOX/C2of3Ilv5+w8/8z7JNmz5 wb9xpJgJr5XFEAmNVcVM8mnK94BIAemzrbbtPSDugIl2uKk+EJrUWwswqXPAQvfYqf6j8G6DkLFs 7DENUswE18raBhLWBrmMkTCfpoTyXgHr2IoA5W0BKx3wUX0gNKm3FmBS54Cd7rFT/Ufh3QYh01Ye 35gGCUbC78PRNpCwNshlDISLOVKaAspUu/MFeHfAQbv4VB8ITeqjBZjUKWAc6B471X8U3m0QslxL iqBBgpngglXbQMLaIJcxEpojpSkgnf+oRYDytoCRDvioPhCa1EcLMKlzwEz32Kk+EHLq9BFeAzh1 CVhoT5zqPwrvESAkzXqDHxuCmeAbdXQEkLCODZcxEprTrCkg/VBTiwDlbQEb3WOn+kDIqdOremsA py4BO+2JU/1H4d2Gnuyrb5BgIuaNOtoGEtYGuYyBcDWnWVPAMbYicHlLwEH32Kk+EJrUcwswqVPA NNCeONV/FN5tELJNZVuBaZBgJry6ljaQsDbIZYyE5jRrCkiHd2sRoLwtYKQL8FQfCE3qvQWY1Dlg pj1xqv8ovNsgZD/m9L431yDBTHh1LW0gYW2QyxgJzWnWFJA+AWoRoLwtYKEL8FQfCDl1uqenBnDq ErDRxjTVfxTebRByXP8GDRLMhFfX0gYS1ga5jJHQnGZNAfvWigDlbQE7XYCn+kDIqfN0XQI4dQk4 aWOa6j8K7zYIOYehzNPcIMFI+FU82gYS1ga5jIFwM6dZU8A5tSJAeX8B80CX/Kk+EJrUewswqXPA SLtpVP9ReLdByTGkpZdrkGAmvMSVNpCwNshljIT5sCqV9xjSGxprEai8v4CZLjJUfSDk1Ol0fA3g 1CVgoXM5qg+EnLq0fuFb6O6AjW6hU/1H4T0CnmQfznP3r2lSzIRX1zICSFjHhssYCfM52Xd5U0Da LFGL8C7vHbDTBkPVB0KTem0BJnUOOOlON9V/FN5tELJsdSLBBilGwm8B0jaQsDbIZQyEuzksnALK dH3yvXUtYBnoXI7qA6FJvbcAkzoHTHSnm+o/Cu82CFmH/NuZa5BgJri61jaQsDbIZYyE+SwwlPcK mO4iQHlbwEy7/FQfCDn1PLUATl0CFrrTTfUfhXcberKsvkGCmeAaTNtAwtoglzES5jOmXN78a0Up Ape3BGy0Z071gdCkXlqASZ0DdrrTTfWB0KTeWoBJnQNO2k+m+kBoUh8twKROAetAV7Op/qPwHnxK lvzV2A7LJ0bCb8jRwUfCOixdxkB45JO1VN6lPMkvRaDy/gIm2tSl+kBoUh8twKTOATNdzab6j8K7 DUquZfYQNOiJmfDyT9pAwtoglzES5pO1VN5r3b63IlB5fwErbepSfSDk1Hn5UQI4dQnY6Go21X8U 3m0QsqffJ32DBDPh5Z+0gYS1QS5jJMwna6G8V0Bet5ciQHlbwEEHgFQfCE3qtQWY1DngpKvZVP9R eLdByVkeGpkGCUbCbwHSNpCwNshlDISnOV6cAvKjuVIEKm8N2AbauKb6QMip86O5EsCpS8BEV7Op PhBy6nQXcw3g1CVgpi1Sqv8ovEeAkGM684d/fdFTv9ur43YInP0x75+wDoHXNrKOv/6w5H2SY7z+ W6wjxUx4rSyGSGisKmZizmKngHlsbXsPiDtgpcvkVB8ITeqtBZjUOWCjTV2q/yi826BkHfKrw7lB ipnga6G0DSSsDXIZI6E5i50CjqEVgcr7CzhG+K6o+kBoUq8twKTOASdt6lL9R+Hdhp7kd+67Bj0x En5rkLaBhLVBLqMVzsNgTl5fAfnAYy0ClrcE7CPdQqf6QGhSHy3ApM4BE23qUn0g5NTpEUQN4NQl YKZb6FQfCE3qqQWY1DlgpV1Hqv8mfAw+JeWTvg7L16dmx80frmMMhL/R9/rU7Pj7Dz/zCpnHvOp0 jgQzwdW9GgKhtSqYiTnCfQU82wYDogVsdKec6gOhSb23AJM6Bxy0T0r134SPNghZz3zfrGuQYCa4 utc2gPDXIJMxFJpj6lfAlt5lW4sA5W0BJ90pp/pAaFIfLcCkTgHXcoLGs+i/CR9tELLN+Tm0a5Bg JPxaKG0DCH8NMhkj4WiOqaeAdG1vLQKUtwVMdKec6gMhp84PfUsApy4BC+2TUv1H4d2GnqTbRl2D BDPhBau0AYS/BpmModAc+k4B6fFBLQKXtwSsdKec6gOhSb21AJM6B2y0T0r1H4V3G4Rc3wKP0zdI MBNesEobQPhrkMkYCs2h7ytgHO4iQHlbwEF3yqk+EHLqvCgsAZy6BJy0T0r1gZBTT0sL4NQ54Bzp vjXVfxM+RsCTnMM85o8IHhuKmeBbt3QEgPA3NkzGUJiPk7/LewVM+YO4FOFd3jtgon1Sqg+EJvXR AkzqHLBMw8Spm/6b8NGGXpjPFHODFCPhFyRpG0D4a5DJGAknPLKthpTsw3YEVp8YCb80Rw2B0Ft9 YiQznsZVQ0LGsbwqrr6mp//e1nHraO6Pg1bhz9HrC2HHX39Y8gpZ5uE8vSPBTPDzRg2B0FoVzATP paohJXt5i56xKhgJvz9CDYHQW31iJAseE1NDPckP3ZzVJ0bCL4tRQyCMrN4YyZwPYMIEfQWk3xjr NAoTtAZQ6ht/FN61EJJeZH74KglGEval1gKEvyqZjJHQ9EUMKTmH8qIWtiqYCc+zYgiE3uoTM8Ez d2pISHqcMXurgpngqzfUEAitVcFM8PSZGlKyr+fmrQomYg7+qyEQeqtPjGTF0zpqqCNbXr47q0/M hD99xBAIA6sPzMQcGcsBezTdaQCm3nG6+wNhq4WQ9O1o9VUSzIRnLakFCH9VMhlDIR4LUkM32f4e pr1s3CWrPUbCZ+3VEAjZao+RbHBApjckZL5WKJux2mMmMDP3hkBorQpmAkdFekMdGcfRWxXMBGat 3hAIA6sPzAROAfSGlBzHep8X7r5XvLh3pBvnm/Dn6D/zh73jZ14h12d2/ipsHAlGQkdze0MgtFYF I9lhB39vSMi6hlYFM4HPkt4QCK1VwUxgL3tvSEg6Cbp6q4KZ8GQnhkBorQpmAtvBe0NK9msC9FYF I6GDi70hEHqrT4zkgD3cvaGeTENg9YmZwJm03hAII6s3ZgJ7XntDQtIj3aVZfc+Syr0j3SbahD9H 71lS+esPS94nSVuk8hkIdqSYCU92YgiEzqpiJrBftTekZM1fVIxVxUjoZFVvCITe6hMjOWHLZ29I yFx/yDBWBTPByU4NgdBaFcwEthL2hoQsdXVirApmgpOdGgKhtSqYCWyq6w31ZDq9VcFI6ARGbwiE kdUbE7nGx3ujVW9IyV6PFGSrr1my485RyQvCn6PXLNnx9x9+5hWS1gqDdySYCU92YgiE1qpgJrDl qDckZNvL9xtjVTATnuzEEAitVcFMYPNNb0jIvubrKZxVwUhoK35vCITWqmAkI2xD6Q0JOfNL1a1V wUx4shNDILRWBTOBDRm9ISXnmv9PNVYFM+HJTgyB0Ft9YiawNaE39CTTMG+D25fdYyS07bc3BEJn VTGSCfYT9IaEXPVKv5gZq4qZ4PSohkBorQpmci2h3kNODQmZLi+TtyqYCU6PagiE1qpgJunhWmC1 n5AvsI2LtyqYCU6PagiE1qpgJucJX7XVkJJzy+tSY1UwEtpQ2BsCobf6xEjmdIOst3r0E3L6dB9n b1UwE5we1RAIrVXBTNYdHoGqISVn3SvJVgUz4elRDIHQW31iJscGX87VkJBtX8/DWxWMhHaG9YZA aK0KRrKMK3w5V0NCjjm0KpgJ/CbVGwKhtSqYybLsS2BVfz5LZN/zjFusvr4pddw7SnlB+HP0+qbU 8f4nwxIw+R0Sr4C3tScOhP/8+9f/WMtl8nIaBwA= ------- =_aaaaaaaaaa0-- From bob.briscoe@bt.com Tue Aug 13 15:32:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FDF21E8188 for ; Tue, 13 Aug 2013 15:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0skMCr+4WRdA for ; Tue, 13 Aug 2013 15:32:03 -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 921C721E818E for ; Tue, 13 Aug 2013 15:32:02 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 13 Aug 2013 23:31:57 +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; Tue, 13 Aug 2013 23:32:00 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Tue, 13 Aug 2013 23:31:59 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.50.99]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r7DMVvHl014620; Tue, 13 Aug 2013 23:31:58 +0100 Message-ID: <201308132231.r7DMVvHl014620@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Aug 2013 23:31:56 +0100 To: From: Bob Briscoe In-Reply-To: <2E8DA3CF-454C-488C-87D9-6BEE3AF83643@ifi.uio.no> References: <655C07320163294895BBADA28372AF5D07F2E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201308061526.r76FQgqQ015337@bagheera.jungle.bt.co.uk> <2E8DA3CF-454C-488C-87D9-6BEE3AF83643@ifi.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tcpm IETF list Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 Aug 2013 22:32:08 -0000 Richard, Mirja, As promised, my detailed review of draft-ietf-tcpm-accecn-reqs-03 is here: I have written my suggested changes as mods to the XML source of the draft merely for convenience. Pls feel free to copy & paste from my XML, to accept or reject each change. I have provided a diff against the original draft-03, which will be the best way to read the suggestions. Most of the changes are editorial - you've often tended to use a German-like sentence structure. It's understandable to an English eye, but it doesn't really flow in English. In a number of places, I've also tried to explain what I think you were meaning a little better. Superficially it looks like a total re-write, but it's not really. Unfortunately, the large number of editorial suggestions have caused the more significant (e.g. technical) changes to become swamped. So I have tried to list the main changes I have suggested here: * Suggested 'fine-grained' would be a better term than 'more accurate' throughout. * Suggested to add paras introducing ConEx & DCTCP to the Intro * Suggested adding more motivation to Intro, esp interoperation between DCTCP implementations. * Suggested adding explanation of why it's not so bad to re-use the nonce bits (in IP & TCP headers) * Suggested shifting certain requirement sentences that I thought were not under the most appropriate requirement bullet * Suggested adding more specific requirements relating to delayed acks * Suggested adding requirements on backward & forward compatibility (including shifting some sentences that were under other headings into this one). __________________ Finally, there were a couple of sentences I thought were incorrect, so I suggested deleting or altering them. If you intended them to be this way, pls explain: "While classic ECN provides a reliable (inaccurate) feedback of a maximum of one congestion signal per RTT, the proposed schemes do not implement any acknowledgement mechanism." [They do.] "Providing wrong feedback information could otherwise lead to throttling of certain connections." [I would have thought certain connections would go faster than intended, not be throttled?] Bob At 08:15 07/08/2013, Michael Welzl wrote: >Hi all, > >I second what Bob says below. Let's avoid having various proprietary >signaling methods for the same thing deployed and instead >standardize a single one. > >Cheers, >Michael (W) > > >On 6. aug. 2013, at 17:26, Bob Briscoe wrote: > > > Michael, > > > > I plan to do this in the next few days. > > I will produce a rev of the xml, so the authors can use any text > directly (or not). > > > > The main things I plan to add, other than editorial stuff, is to > motivate standardisation for interoperation: > > * Although DCTCP was presented at the IETF, a protocol spec has > not being offered for standardisation so far > > * DCTCP is becoming widely deployed and it uses a non-standard > TCP wire protocol for feedback > > * The way the Windows 8 DCTCP negotiates use of this non-standard > TCP feedback protocol is proprietary and unspecified > > * We do not want widespread deployment of a proprietary TCP > feedback negotiation protocol to burn up the few remaining flags or > options so that de facto they become unavailable for use in standards. > > * The feedback protocol used in the Windows 8 DCTCP assumes no > losses and quickly gets very confused about ECN feedback if there > are losses as well > > * Other implementations of DCTCP (Linux, FreeBSD) seem to be > inventing their own different feedback protocols > > * These different wire protocols have not been specified to > interwork with each other - they all seem to assume that the other > end is using the same implementation > > > > > > However, I want to properly investigate the ground truth under as > many of these statements as I can first (I've done most of them). > > > > > > > > Bob > > > > At 15:40 06/08/2013, Scharf, Michael (Michael) wrote: > >> Hi all, > >> > >> According to our minutes, you volunteered in the TCPM meeting to > review draft-ietf-tcpm-accecn-reqs-02. The TCPM chairs appreciate > this a lot, since this document didn't get a lot of feedback recently. > >> > >> It would really help if you could have a look at the document > and post your thoughts to the TCPM mailing list. We are > specifically interested whether the problem statement and the > requirements are complete. It would also be of interest if the > survey of the design approaches misses something. > >> > >> Again, thanks a lot for volunteering! > >> > >> Michael > > > > ________________________________________________________________ > > Bob Briscoe, BT ________________________________________________________________ Bob Briscoe, BT From apopov@palermo.edu Wed Aug 14 01:06:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6911E813A for ; Wed, 14 Aug 2013 01:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji4kTp8kLQwl for ; Wed, 14 Aug 2013 01:06:55 -0700 (PDT) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id 602CC11E812A for ; Wed, 14 Aug 2013 01:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1376467584; bh=dprjEmI3MlT1Dj2aADuR9d76Y8JKfPYyywJFhi44+8g=; h=Date:From:To:CC:References:In-Reply-To:Subject; b=nSz/hI+bZORac5VXRl3bngaX8csfta23AL85IpudK0pOYT21x+v8puOFvnDsTbjVg q+yyrD3FHhf/gTl7CtktTpVX5FEZ0P8vdvBqbOKAUNbudBBNLE0PUSmer7njcCvjP8 lTVdeuEbnKgMKaDzpijEHAsjFUwf+RxqzuWauzTA= Received: from maxwell.palermo.edu (localhost.localdomain [127.0.0.1]) by maxwell.palermo.edu (8.13.8/8.13.8) with ESMTP id r7E86MhF008734; Wed, 14 Aug 2013 05:06:22 -0300 Received: from [192.168.2.159] (www.solbel.com.ar [200.49.156.98]) by maxwell.palermo.edu with ESMTP id 9Q6WGFPW.144886.0 Message-ID: <520B3A78.5070802@palermo.edu> Date: Wed, 14 Aug 2013 05:06:16 -0300 From: Alejandro Popovsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: tcpm , Tim Shepard References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authorization-Id: who=apopov X-Host: 200.49.156.98 www.solbel.com.ar Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Aug 2013 08:06:59 -0000 Hi Tim You are right. "Thanks" to buffer-bloating, throughput at the receiver side never went down even when the sender stalled. It looks like "loss-based congestion detection" at the sender combined with receivers with "big RWIN" or "auto-tuning RWIN" avoid interruption of data flow at the receiver during "fast recovery RWIN limitations" because of large buffer accumulation (although this may not be desirable). "Delay based congestion detection" would not have this large buffer accumulations when fast recovery happens but might be further away from the RWIN limit. Best regards, Alejandro. P.S. A receiver with auto tuning, detecting that RTT is growing too much because of the sender just "trying to fill the pipe", could decrease RWIN (but not during fast recovery) without noticeable decrease in throughput. On 12/08/13 13:59, Tim Shepard wrote: > >http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap > I took a look at that trace. > Note that in this trace that there was apparently no delay at all in > delivering the whole transfer of data to the receiver. This can be > seen by plotting the acknowledgement numbers returned as a function of > the time the acknowledgement numbers were recevied by the sender > (which can serve as a fairly good proxy for the time the data was > received by the receiver). > If you look at the acknowledgement numbers vs time before and after > the loss and recovery episode you can see that they are colinear, > which indicates that the loss and recovery event never let the queue > at the bottleneck go empty, so there was always useful data to be sent > through the bottleneck, so it never went idle. And apparently the > SACK blocks got enough information to the sender so that the recovery >episode wasted no time sending duplicate data through the bottleneck. > The end-to-end flow control window appears to be much larger than it > needs to be to enable the sender to saturate the bottleneck link on > the path. > This example does show significant queue bloat at the bottleneck. It > would be nice to see this same demo with codel or fq_codel managing > the queue length at the bottleneck. > A few pictures attached below. ( Also the .xplot.gz file for those of > you with a working copy of my xplot program. ) > -Tim Shepard > shep at alum.mit.edu On 13/08/13 12:56 PM, Yuchung Cheng wrote: > On Mon, Aug 12, 2013 at 10:39 PM, Yoshifumi Nishida > wrote: >> Hi Alejandro, >> >> Thanks for the dump file. >> Please correct me if I miss something. >> >> During the first retransmit and fast recovery, the sender can transmit >> 2/sender's cwnd - MSS bytes of new data. (because 1MSS is consumed by >> retransmission) >> This means in the worst case, you will need to have 3/2 sender's cwnd >> receiver buffer to keep all data transmitted during this period. >> But, the worst case can only happen when the retransmit segment by >> fast retransmit arrives after all new data has arrived. >> (Another example will be a case where the receiver's application >> becomes slow to read data all of sudden during loss recovery.) >> >> You're right that if we want to prepare the worst case, the receiver >> will need 1.5 times larger size of buffer than the sender's buffer. >> But, I'm not sure this is a problem. Because I'm not very sure TCP >> needs to guarantee full performance when sender's buffer size equals >> receiver's buffer size. > It's not about sender's buffer size. > > It'll be easier to explain with time sequence graph, but I doubt this > list allows binary attachment so > try this > tcptrace -CSzxy && xplot.org b2a_tsg.xpl > > During the recovery, the rwin remains stale and the yellow line is horizontal. > > The fundamental problem is that the receiver (likely a Linux box) does > not account for OOO packets received to adjust RWIN. > But congestion control, or cwin, does account for SACKed packets and > retransmits. > > When the receiver have too many OOO packets it unintentionally thwart > the sender, creating a bubble in the data pipeline at 5s. > > Due to bufferbloat, by the time the loss happens, the network has > buffered a ton. By the time the fast retransmit finally arrives to > repair the losses, the rwin opens up the flood gate, hence the big > jump of the yellow line. Interesting the sender is probably > application-limited so it didn't send out a burst. > > So the receiver is unintentionally throttling the sender to make > forward progress during recovery. Not a good idea unless the receiver > really can't afford the extra 100KB. > > >> In your tcpdump, the first retransmit segment by fast retransmit seems >> to be lost, hence you got extra dup acks. >> But, I think this is not a situation that fast retransmit logic expects. >> >> Thanks, >> -- >> Yoshifumi >> >> >> On Sun, Aug 11, 2013 at 11:07 PM, Alejandro Popovsky wrote: >>> Hi Christoph, >>> >>> I left another example where the receiver is tuning its receive window, but >>> not >>> as dynamically as to prevent a sender stall during fast recovery: >>> >>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery2.pdf >>> >>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap >>> >>> Best regards, Alejandro. >>> >>> >>> >>> On 11/08/13 04:05 PM, Christoph Paasch wrote: >>>> Hello, >>>> >>>> On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: >>>>> I have just left an example connection in: >>>>> >>>>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap >>>> the trace looks rather like the receiver has its window capped at 64K. >>>> E.g., >>>> through a socket-option. Because from the beginning on, the announced >>>> window >>>> is at 64K and it never changes. >>>> >>>> If the client would not cap the window, the autotuning should do its job >>>> to >>>> adjust the window at 2*BDP, and thus allow full speed - even during >>>> recovery. >>>> >>>> >>>> Cheers, >>>> Christoph >>>> >>>>> I am leaving also an analysis of the connection showing the flow >>>>> control limitation reached during fast recovery, here: >>>>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf >>>>> >>>>> Let me know if you want some other examples. >>>>> >>>>> Best regards, Alejandro. >>>>> >>>>> >>>>> >>>>> On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: >>>>>> Hi Alejandro, >>>>>> Is it possible to see tcpdump files for this? It might be better if we >>>>>> can discuss with real data. >>>>>> -- >>>>>> Yoshifumi >>>>>> >>>>>> On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have been observing that many connections become limited >>>>>>> by the receiver window during fast recovery, even when this window >>>>>>> is above RTT*maximumPathRate (and using windows scaling). >>>>>>> >>>>>>> This is because during fast recovery the congestion window is >>>>>>> artificially inflated on each duplicate ack (after the third). And the >>>>>>> number of unacked bytes may come up to double RTT*maximumPathRate. >>>>>>> >>>>>>> For this to be prevented, the receiver may grow its reception window >>>>>>> up to double its size when generating duplicate acks. >>>>>>> >>>>>>> >>>>>>> I observed this at the traffic of service providers that were having an >>>>>>> important percentage of their traffic limited by flow control (most of >>>>>>> the >>>>>>> traffic is generally limited by the network, or by the data generation >>>>>>> rate >>>>>>> at the source). >>>>>>> >>>>>>> >>>>>>> Best regards, Alejandro Popovsky. >>>>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nishida@sfc.wide.ad.jp Wed Aug 14 01:19:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E301621F96EF for ; Wed, 14 Aug 2013 01:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urcWN8v4XEYZ for ; Wed, 14 Aug 2013 01:19:12 -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 B670F21F8C93 for ; Wed, 14 Aug 2013 01:19:11 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3B3352780C3 for ; Wed, 14 Aug 2013 17:19:07 +0900 (JST) Received: by mail-la0-f47.google.com with SMTP id eo20so6460877lab.6 for ; Wed, 14 Aug 2013 01:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CdG+vfzDhIBM30YrrlJywrTpfo07mQgkRGvtOwpQJ3M=; b=MEIIYa78BnoV4eH+55r1WeUitUhqKFjYXhSIDavwJKIPjMc4EZBhhpEkUUAVMoMJjN qxOqa+rs0VPQGWSfkEo6ajdOVpe7wwLDq6qlYT6EPaMzLshqYqfXvPa9SwCKO43pQdTM gvSrdk/AjASwS/esXk1rWbUway5q81HAEiIQlbXgAPkcd8ez3bgRBP0No8O6WACPL/91 nYRDhTLQwvkcjQOK73mvXpkwdL/m7Q2IsfC0s2AFv2xRHoPhG79KlVkkPKme8lj0NVKj s1Ln6vRqlUUR33DBL5vrrPL68TDKiOW/yY485MXuinYrnzhRyESc7FWBDjuAqdvRa5Pv zueQ== MIME-Version: 1.0 X-Received: by 10.112.172.137 with SMTP id bc9mr1663854lbc.21.1376468345341; Wed, 14 Aug 2013 01:19:05 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Wed, 14 Aug 2013 01:19:05 -0700 (PDT) In-Reply-To: References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> Date: Wed, 14 Aug 2013 01:19:05 -0700 Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Aug 2013 08:19:13 -0000 Hi Yuchung, I tried to mention how much buffer size will be required to guarantee fast retransmit and fast recovery works propoerly. But, I'm not very sure if this plot is a proper example for detailed discussions on standards. Because the behavior of the sender is a bit strange to me. It seems that it tries to do rate halving (or PRR) at the beginning of recovery, but it speeds up after a while even though it stills in recovery phase. This aggressive increase will require more buffer space at the receiver, but I think it's not a standard behavior. Thanks, -- Yoshifumi On Tue, Aug 13, 2013 at 8:56 AM, Yuchung Cheng wrote: > On Mon, Aug 12, 2013 at 10:39 PM, Yoshifumi Nishida > wrote: >> Hi Alejandro, >> >> Thanks for the dump file. >> Please correct me if I miss something. >> >> During the first retransmit and fast recovery, the sender can transmit >> 2/sender's cwnd - MSS bytes of new data. (because 1MSS is consumed by >> retransmission) >> This means in the worst case, you will need to have 3/2 sender's cwnd >> receiver buffer to keep all data transmitted during this period. >> But, the worst case can only happen when the retransmit segment by >> fast retransmit arrives after all new data has arrived. >> (Another example will be a case where the receiver's application >> becomes slow to read data all of sudden during loss recovery.) >> >> You're right that if we want to prepare the worst case, the receiver >> will need 1.5 times larger size of buffer than the sender's buffer. >> But, I'm not sure this is a problem. Because I'm not very sure TCP >> needs to guarantee full performance when sender's buffer size equals >> receiver's buffer size. > It's not about sender's buffer size. > > It'll be easier to explain with time sequence graph, but I doubt this > list allows binary attachment so > try this > tcptrace -CSzxy && xplot.org b2a_tsg.xpl > > During the recovery, the rwin remains stale and the yellow line is horizontal. > > The fundamental problem is that the receiver (likely a Linux box) does > not account for OOO packets received to adjust RWIN. > But congestion control, or cwin, does account for SACKed packets and > retransmits. > > When the receiver have too many OOO packets it unintentionally thwart > the sender, creating a bubble in the data pipeline at 5s. > > Due to bufferbloat, by the time the loss happens, the network has > buffered a ton. By the time the fast retransmit finally arrives to > repair the losses, the rwin opens up the flood gate, hence the big > jump of the yellow line. Interesting the sender is probably > application-limited so it didn't send out a burst. > > So the receiver is unintentionally throttling the sender to make > forward progress during recovery. Not a good idea unless the receiver > really can't afford the extra 100KB. > > >> >> In your tcpdump, the first retransmit segment by fast retransmit seems >> to be lost, hence you got extra dup acks. >> But, I think this is not a situation that fast retransmit logic expects. >> >> Thanks, >> -- >> Yoshifumi >> >> >> On Sun, Aug 11, 2013 at 11:07 PM, Alejandro Popovsky wrote: >>> Hi Christoph, >>> >>> I left another example where the receiver is tuning its receive window, but >>> not >>> as dynamically as to prevent a sender stall during fast recovery: >>> >>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery2.pdf >>> >>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap >>> >>> Best regards, Alejandro. >>> >>> >>> >>> On 11/08/13 04:05 PM, Christoph Paasch wrote: >>>> >>>> Hello, >>>> >>>> On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: >>>>> >>>>> I have just left an example connection in: >>>>> >>>>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap >>>> >>>> the trace looks rather like the receiver has its window capped at 64K. >>>> E.g., >>>> through a socket-option. Because from the beginning on, the announced >>>> window >>>> is at 64K and it never changes. >>>> >>>> If the client would not cap the window, the autotuning should do its job >>>> to >>>> adjust the window at 2*BDP, and thus allow full speed - even during >>>> recovery. >>>> >>>> >>>> Cheers, >>>> Christoph >>>> >>>>> I am leaving also an analysis of the connection showing the flow >>>>> control limitation reached during fast recovery, here: >>>>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf >>>>> >>>>> Let me know if you want some other examples. >>>>> >>>>> Best regards, Alejandro. >>>>> >>>>> >>>>> >>>>> On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: >>>>>> >>>>>> Hi Alejandro, >>>>>> Is it possible to see tcpdump files for this? It might be better if we >>>>>> can discuss with real data. >>>>>> -- >>>>>> Yoshifumi >>>>>> >>>>>> On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have been observing that many connections become limited >>>>>>> by the receiver window during fast recovery, even when this window >>>>>>> is above RTT*maximumPathRate (and using windows scaling). >>>>>>> >>>>>>> This is because during fast recovery the congestion window is >>>>>>> artificially inflated on each duplicate ack (after the third). And the >>>>>>> number of unacked bytes may come up to double RTT*maximumPathRate. >>>>>>> >>>>>>> For this to be prevented, the receiver may grow its reception window >>>>>>> up to double its size when generating duplicate acks. >>>>>>> >>>>>>> >>>>>>> I observed this at the traffic of service providers that were having an >>>>>>> important percentage of their traffic limited by flow control (most of >>>>>>> the >>>>>>> traffic is generally limited by the network, or by the data generation >>>>>>> rate >>>>>>> at the source). >>>>>>> >>>>>>> >>>>>>> Best regards, Alejandro Popovsky. >>>>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Wed Aug 14 08:36:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0F521E80AB for ; Wed, 14 Aug 2013 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw-RJR5jKTmQ for ; Wed, 14 Aug 2013 08:36:35 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1B121F9E37 for ; Wed, 14 Aug 2013 08:36:35 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so12218615obb.30 for ; Wed, 14 Aug 2013 08:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O27bPgk38mPFA02zr0FOzra+16bRXdt+v2B5G845qek=; b=flOlqgc2u5PjybK/JMbLBKDQendJSt0a6kDl3ueaY8PV+cVKGAJk4CQvW6z7u2Yc7g ZdLT7GuM/gfZnOHYHaFmZYvdk3jYnZSfO8s/jMZDfcdiytrtMaQvBQ3zEN3G+BVMOJQs qLG6IAXbLPqNPZmhF4TBtC/+OMytG35TjdGHCiwi1wwabVP5RY6DvrVZ77UbsXf4tKbw BICzB06+zgJQ7Jf8Lf3bdu5ILkRFBpJ51NBeQ4/I80kzfQq/8HUHVegEWZAIDwh+GYnE jqsYXSd/y27t4HjpZFhZVLx4rNn8kNat9LsqlqAo1KreMMfULtWcIAG9LgZSVnJyKuCS pOCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=O27bPgk38mPFA02zr0FOzra+16bRXdt+v2B5G845qek=; b=WURHSUprnm6anjWw3389oyQOCxGStiNGWVy3ZeKppJ1kv8g0GFFmUZmxz/gHoZuB/3 /rBvyFMQcSTOgDzCIfn0anNntInU9rTvZK6BDW+TWWgmAF4bysTHzdoQa+AvjDMib+bc Q16u/ZwS88UfFLvqwYcB0gJK1UGyxqlBb0Xu1DxXpUS9an0ggWG7c5PN5U5ZDAvSDj1Y pxfSIUNlp+gGQTTeAp2my8U7wYyke0T8BCgTcNSg6s/nqacHCyBoNY5d/rLD0X0QVyiV WTGVlHioNnZwBlHxMBPrS9dSejOGpX4vxMUUqzea9RfwZ6w1ifMZgWhjkkstngG/yQzI yKGg== X-Gm-Message-State: ALoCoQna5Jbv5bmzPKJh2Y+J2+A0hQdWxBs8JWSja7kQjp2V9F0CEWjK+Eun6CiUQYt1FTvdGqGlJbIqlJA7I/Ufz6IAjMxaa+Kzdhg1lE4Jl3qp9lKe8c0yiHQQmk53aqWbcx4NZ05sH+cyTZ4Kg51Gqea1b5FV5/dK7oOHABKAg1y7m6hSh2rukIEGvNkhCuaqyOLnfkxF X-Received: by 10.182.101.198 with SMTP id fi6mr566536obb.79.1376494593466; Wed, 14 Aug 2013 08:36:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.81.163 with HTTP; Wed, 14 Aug 2013 08:36:13 -0700 (PDT) In-Reply-To: References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> From: Yuchung Cheng Date: Wed, 14 Aug 2013 08:36:13 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Aug 2013 15:36:36 -0000 On Wed, Aug 14, 2013 at 1:19 AM, Yoshifumi Nishida wrote: > Hi Yuchung, > > I tried to mention how much buffer size will be required to guarantee > fast retransmit and fast recovery works propoerly. > But, I'm not very sure if this plot is a proper example for detailed > discussions on standards. Because the behavior of the sender is a bit > strange to me. > It seems that it tries to do rate halving (or PRR) at the beginning of > recovery, but it speeds up after a while even though it stills in > recovery phase. I am pretty sure it's doing PRR as specified in the RFC http://tools.ietf.org/html/rfc6937#section-3 Note once the pipe is below ssthresh PRR will do slow-start, just like normal CC. > This aggressive increase will require more buffer space at the > receiver, but I think it's not a standard behavior. > Thanks, > -- > Yoshifumi > > > On Tue, Aug 13, 2013 at 8:56 AM, Yuchung Cheng wrote: >> On Mon, Aug 12, 2013 at 10:39 PM, Yoshifumi Nishida >> wrote: >>> Hi Alejandro, >>> >>> Thanks for the dump file. >>> Please correct me if I miss something. >>> >>> During the first retransmit and fast recovery, the sender can transmit >>> 2/sender's cwnd - MSS bytes of new data. (because 1MSS is consumed by >>> retransmission) >>> This means in the worst case, you will need to have 3/2 sender's cwnd >>> receiver buffer to keep all data transmitted during this period. >>> But, the worst case can only happen when the retransmit segment by >>> fast retransmit arrives after all new data has arrived. >>> (Another example will be a case where the receiver's application >>> becomes slow to read data all of sudden during loss recovery.) >>> >>> You're right that if we want to prepare the worst case, the receiver >>> will need 1.5 times larger size of buffer than the sender's buffer. >>> But, I'm not sure this is a problem. Because I'm not very sure TCP >>> needs to guarantee full performance when sender's buffer size equals >>> receiver's buffer size. >> It's not about sender's buffer size. >> >> It'll be easier to explain with time sequence graph, but I doubt this >> list allows binary attachment so >> try this >> tcptrace -CSzxy && xplot.org b2a_tsg.xpl >> >> During the recovery, the rwin remains stale and the yellow line is horizontal. >> >> The fundamental problem is that the receiver (likely a Linux box) does >> not account for OOO packets received to adjust RWIN. >> But congestion control, or cwin, does account for SACKed packets and >> retransmits. >> >> When the receiver have too many OOO packets it unintentionally thwart >> the sender, creating a bubble in the data pipeline at 5s. >> >> Due to bufferbloat, by the time the loss happens, the network has >> buffered a ton. By the time the fast retransmit finally arrives to >> repair the losses, the rwin opens up the flood gate, hence the big >> jump of the yellow line. Interesting the sender is probably >> application-limited so it didn't send out a burst. >> >> So the receiver is unintentionally throttling the sender to make >> forward progress during recovery. Not a good idea unless the receiver >> really can't afford the extra 100KB. >> >> >>> >>> In your tcpdump, the first retransmit segment by fast retransmit seems >>> to be lost, hence you got extra dup acks. >>> But, I think this is not a situation that fast retransmit logic expects. >>> >>> Thanks, >>> -- >>> Yoshifumi >>> >>> >>> On Sun, Aug 11, 2013 at 11:07 PM, Alejandro Popovsky wrote: >>>> Hi Christoph, >>>> >>>> I left another example where the receiver is tuning its receive window, but >>>> not >>>> as dynamically as to prevent a sender stall during fast recovery: >>>> >>>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery2.pdf >>>> >>>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery2.pcap >>>> >>>> Best regards, Alejandro. >>>> >>>> >>>> >>>> On 11/08/13 04:05 PM, Christoph Paasch wrote: >>>>> >>>>> Hello, >>>>> >>>>> On 11/08/13 - 14:19:50, apopov@palermo.edu wrote: >>>>>> >>>>>> I have just left an example connection in: >>>>>> >>>>>> http://www.palermo.edu/ingenieria/comm/exampleDumpFlowCtrlFastRecovery.pcap >>>>> >>>>> the trace looks rather like the receiver has its window capped at 64K. >>>>> E.g., >>>>> through a socket-option. Because from the beginning on, the announced >>>>> window >>>>> is at 64K and it never changes. >>>>> >>>>> If the client would not cap the window, the autotuning should do its job >>>>> to >>>>> adjust the window at 2*BDP, and thus allow full speed - even during >>>>> recovery. >>>>> >>>>> >>>>> Cheers, >>>>> Christoph >>>>> >>>>>> I am leaving also an analysis of the connection showing the flow >>>>>> control limitation reached during fast recovery, here: >>>>>> http://www.palermo.edu/ingenieria/comm/flowCtrlFastRecovery.pdf >>>>>> >>>>>> Let me know if you want some other examples. >>>>>> >>>>>> Best regards, Alejandro. >>>>>> >>>>>> >>>>>> >>>>>> On 11/08/13 05:44 AM, Yoshifumi Nishida wrote: >>>>>>> >>>>>>> Hi Alejandro, >>>>>>> Is it possible to see tcpdump files for this? It might be better if we >>>>>>> can discuss with real data. >>>>>>> -- >>>>>>> Yoshifumi >>>>>>> >>>>>>> On Fri, Aug 9, 2013 at 1:43 PM, Alejandro Popovsky wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have been observing that many connections become limited >>>>>>>> by the receiver window during fast recovery, even when this window >>>>>>>> is above RTT*maximumPathRate (and using windows scaling). >>>>>>>> >>>>>>>> This is because during fast recovery the congestion window is >>>>>>>> artificially inflated on each duplicate ack (after the third). And the >>>>>>>> number of unacked bytes may come up to double RTT*maximumPathRate. >>>>>>>> >>>>>>>> For this to be prevented, the receiver may grow its reception window >>>>>>>> up to double its size when generating duplicate acks. >>>>>>>> >>>>>>>> >>>>>>>> I observed this at the traffic of service providers that were having an >>>>>>>> important percentage of their traffic limited by flow control (most of >>>>>>>> the >>>>>>>> traffic is generally limited by the network, or by the data generation >>>>>>>> rate >>>>>>>> at the source). >>>>>>>> >>>>>>>> >>>>>>>> Best regards, Alejandro Popovsky. >>>>>>>> >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nishida@sfc.wide.ad.jp Wed Aug 14 22:13:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3011E8125 for ; Wed, 14 Aug 2013 22:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdQkGtGyTatN for ; Wed, 14 Aug 2013 22:13:36 -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 B2D3D11E8108 for ; Wed, 14 Aug 2013 22:13:34 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A7B4F2780CD for ; Thu, 15 Aug 2013 14:13:31 +0900 (JST) Received: by mail-lb0-f177.google.com with SMTP id n6so321673lbi.22 for ; Wed, 14 Aug 2013 22:13:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k4ob4s3xbs869YgcJ5IXOMP/GBWeAJvtHV70k1Es2Ys=; b=MaEAlWsUA+BZom1rI3IgABo5tfXD1Hh5NRXHLLMBD2KmkRBHlQLHoV4zmRcmRQDBLq gzgVAoY2XL10Oh+K/peh5/eQGmyLuVDeZEq2Xi1oS4cGvOI6X1QzxQD4lm0fO1uG3xp8 a7AbJhV/K+zGz1M6s197CoRq8xxDtYix+BOMlhBTqpzhxzPLgyr/D55mM9052SwOTv8M g5Wq6xi5L1v0/FQRI1OZ7RFJmHeUaO2BYgEDs/m9R2MT8y1n3FQum8G5akkqmKwK2o86 90m7HBtKCvUyKZYQel3b9JFaSAUHSDcPIFPEMhZlk+R7G+K2Svlr0jJaAsHHfeAMUoi+ 7CkA== MIME-Version: 1.0 X-Received: by 10.112.42.68 with SMTP id m4mr11159181lbl.4.1376543608761; Wed, 14 Aug 2013 22:13:28 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Wed, 14 Aug 2013 22:13:28 -0700 (PDT) In-Reply-To: References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> Date: Wed, 14 Aug 2013 22:13:28 -0700 Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Aug 2013 05:13:36 -0000 Hi Yuchung, On Wed, Aug 14, 2013 at 8:36 AM, Yuchung Cheng wrote: > On Wed, Aug 14, 2013 at 1:19 AM, Yoshifumi Nishida > wrote: >> Hi Yuchung, >> >> I tried to mention how much buffer size will be required to guarantee >> fast retransmit and fast recovery works propoerly. >> But, I'm not very sure if this plot is a proper example for detailed >> discussions on standards. Because the behavior of the sender is a bit >> strange to me. >> It seems that it tries to do rate halving (or PRR) at the beginning of >> recovery, but it speeds up after a while even though it stills in >> recovery phase. > I am pretty sure it's doing PRR as specified in the RFC > http://tools.ietf.org/html/rfc6937#section-3 > > Note once the pipe is below ssthresh PRR will do slow-start, just like > normal CC. Oh. I see. Thanks for pointing out. Then, I think at least we should avoid slow-start increase when TCP retransmits retransmited packets, although I don't have a clear idea for the best behavior in this kind of situation, yet. Because this is basically an indication of packet loss during recovery phase. (or, spurious RTO caused by bufferbloat, but even so, I think we'll still need to slow down) -- Yoshifumi From rs@netapp.com Tue Aug 20 00:01:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8934B21F99E8 for ; Tue, 20 Aug 2013 00:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuSV4zYFsmeP for ; Tue, 20 Aug 2013 00:01:29 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5B89E11E81DE for ; Tue, 20 Aug 2013 00:01:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,918,1367996400"; d="scan'208";a="42719026" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 20 Aug 2013 00:01:23 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.122]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 20 Aug 2013 00:01:22 -0700 From: "Scheffenegger, Richard" To: Yoshifumi Nishida , Yuchung Cheng Thread-Topic: [tcpm] flow control and fast recovery Thread-Index: AQHOlyPNgsJoqGMh40+oTzEhNOXFf5mTFhwAgACsbICAARJqgIAAeiKAgADkVwCABvrFQA== Date: Tue, 20 Aug 2013 07:01:22 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25CD0059@SACEXCMBX02-PRD.hq.netapp.com> References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Aug 2013 07:01:44 -0000 HI Yoshifumi, > > Note once the pipe is below ssthresh PRR will do slow-start, just like > > normal CC. >=20 > Oh. I see. Thanks for pointing out. > Then, I think at least we should avoid slow-start increase when TCP > retransmits retransmited packets, although I don't have a clear idea for > the best behavior in this kind of situation, yet. > Because this is basically an indication of packet loss during recovery > phase. So far, lost retransmission detection, or fast recovery of a lost retransmi= ssion, has not been mentioned in any RFC; the default behavior of stack com= pliant with the RFCs is to run into a RTO - which is a pretty hefty reactio= n to continued loss (congestion indication) during recovery. OTOH, one part= icular OS has demonstrated, that by simply ignoring the congestion signal d= ue to lost retransmissions also doesn't lead to an instant network meltdown= . Once I've finished what I'm currently focused on, I would like to submit a = paper to sketch out lost retransmission detection and recovery (with SACK).= I think such a draft would be the proper place to mention the expected beh= avior. Best regards, Richard Scheffenegger From nishida@sfc.wide.ad.jp Thu Aug 22 08:36:48 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9511E81CB for ; Thu, 22 Aug 2013 08:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS6DIEGVQeaB for ; Thu, 22 Aug 2013 08:36:48 -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 5290611E80D9 for ; Thu, 22 Aug 2013 08:36:47 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BD2DA2780FD for ; Fri, 23 Aug 2013 00:36:41 +0900 (JST) Received: by mail-la0-f46.google.com with SMTP id eh20so1548341lab.19 for ; Thu, 22 Aug 2013 08:36:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CBA2EFpQ2EBjyirLHf11KxslxtarXtcwiqYnnihRBd0=; b=EyCIz2Nyw3/QcwwmT99LYRC/hsmDg6dGQ/5jyhC7KJPeFr4Ipc726sHCabxKV+ItZv vak8PQFY1Shp7p8nzRy+QKG7eubDRRcJNHRxTeH2CNS0EvROEolyDWlHwKPUl6KoePPO IRStZubfij4gxIqrDrJTkbKOpSdlV4uVDaFWkg2cX7dFJMB28VGEsImlZvkOdVGxFRUJ UPS59P6RVRw8HznyOCGaxTBpyOOcWf8BP0nXtnAokCErc7JS6b+d5h62G8SdCxh4inMf IZPkO2tqt/LoRG9nJzanFVj3wD//R1u7rkn2gn7pdp92vM7QLJ3Ua84Srf1/w7YM5fb+ VJ8w== MIME-Version: 1.0 X-Received: by 10.152.9.37 with SMTP id w5mr11159949laa.23.1377185799155; Thu, 22 Aug 2013 08:36:39 -0700 (PDT) Received: by 10.114.1.115 with HTTP; Thu, 22 Aug 2013 08:36:39 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25CD0059@SACEXCMBX02-PRD.hq.netapp.com> References: <5205547D.90608@palermo.edu> <5207C7B6.7020700@palermo.edu> <20130811190504.GA11031@cpaasch-mac> <52087B8B.1060204@palermo.edu> <012C3117EDDB3C4781FD802A8C27DD4F25CD0059@SACEXCMBX02-PRD.hq.netapp.com> Date: Thu, 22 Aug 2013 08:36:39 -0700 Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm Subject: Re: [tcpm] flow control and fast recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Aug 2013 15:36:49 -0000 Hi Richard, On Tue, Aug 20, 2013 at 12:01 AM, Scheffenegger, Richard wr= ote: > HI Yoshifumi, > >> > Note once the pipe is below ssthresh PRR will do slow-start, just like >> > normal CC. >> >> Oh. I see. Thanks for pointing out. >> Then, I think at least we should avoid slow-start increase when TCP >> retransmits retransmited packets, although I don't have a clear idea for >> the best behavior in this kind of situation, yet. >> Because this is basically an indication of packet loss during recovery >> phase. > > > So far, lost retransmission detection, or fast recovery of a lost retrans= mission, has not been mentioned in any RFC; the default behavior of stack c= ompliant with the RFCs is to run into a RTO - which is a pretty hefty react= ion to continued loss (congestion indication) during recovery. OTOH, one pa= rticular OS has demonstrated, that by simply ignoring the congestion signal= due to lost retransmissions also doesn't lead to an instant network meltdo= wn. I agree that this is an interesting and an important point. As bufferbloat tends to increase cwnd, we might run into situations where we see congestion indications during recovery while ACK clocking is still working more often. -- Yoshifumi From ietf-secretariat-reply@ietf.org Wed Aug 21 12:39:45 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341C211E812E for ; Wed, 21 Aug 2013 12:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNJwXK92y-uF for ; Wed, 21 Aug 2013 12:39:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFB311E8131 for ; Wed, 21 Aug 2013 12:39:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130821193941.23809.53246.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 12:39:41 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 22 Aug 2013 08:37:32 -0700 Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Aug 2013 19:39:45 -0000 URL: http://datatracker.ietf.org/wg/tcpm/charter/ From Alexander.Zimmermann@netapp.com Fri Aug 23 05:59:07 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C892311E81B0 for ; Fri, 23 Aug 2013 05:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqHg9IrP0vXe for ; Fri, 23 Aug 2013 05:59:02 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id B0C6911E80FF for ; Fri, 23 Aug 2013 05:59:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,941,1367996400"; d="asc'?txt'?scan'208";a="43651326" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 23 Aug 2013 05:58:55 -0700 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.213]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 23 Aug 2013 05:58:54 -0700 From: "Zimmermann, Alexander" To: " Extensions" Thread-Topic: New Version Notification for draft-ietf-tcpm-tcp-rfc4614bis-00.txt Thread-Index: AQHOlQLuFACvQF3RkEGBancmssUYfA== Date: Fri, 23 Aug 2013 12:58:53 +0000 Message-ID: References: <52166910.8080005@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.104.60.117] Content-Type: multipart/signed; boundary="Apple-Mail=_6969B0E8-4B4C-42F4-92C0-7E40691771C8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Bob Braden Subject: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-tcp-rfc4614bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Aug 2013 12:59:07 -0000 --Apple-Mail=_6969B0E8-4B4C-42F4-92C0-7E40691771C8 Content-Type: multipart/mixed; boundary="Apple-Mail=_AF67436C-8CC2-443E-ADA5-CB45B71AD4FA" --Apple-Mail=_AF67436C-8CC2-443E-ADA5-CB45B71AD4FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI. A review from Bob. I will incorporate Bob's feedback. Alex Anfang der weitergeleiteten Nachricht: > Von: Bob Braden > Betreff: Aw: New Version Notification for = draft-ietf-tcpm-tcp-rfc4614bis-00.txt > Datum: 22. August 2013 21:40:00 MESZ > An: "Zimmermann, Alexander" > Kopie: Martin Duke , "Wesley M. Eddy" = , Ethan Blanton , "ted faber = braden@isi.edu" >=20 > I promised Alex I would give 4614bis a read through. This message=20 > contains my comments but does > not include the typos that I saw. Another day. >=20 > Nothing I have to say should be taken as disapproval of the document = as=20 > a whole. The authors did a really good job disentangling what has = become=20 > a muddy maze of RFCs! =46rom 30,000 feet, it may reflects a defect in = the=20 > IETF processes, resulting in conflict and fragmentation of protocol=20 > specs. It would seem to be a daunting task for a TCP implementer to=20 > figure out what to implement, even with your excellent document. >=20 > Bob Braden >=20 >=20 [siehe angeh=E4ngte Datei: roadmapAtt.txt] --Apple-Mail=_AF67436C-8CC2-443E-ADA5-CB45B71AD4FA Content-Disposition: attachment; x-maiconizer-atend=yes; filename=roadmapAtt.txt Content-Type: text/plain; name="roadmapAtt.txt" Content-Transfer-Encoding: quoted-printable =0D =0D COMMENTS ON draft 4614bis=0D =0D o I was nearly done with RFC 1122 when Dave Crocker spoke up and = complained that it was nearly impossible to find a particular = requirement. He was clearly right, so I dove back in and produced the = Summary charts that appear at the end of each section of 1122. Reading = 4614bis, I had Dave's problem. The explanation of RFCxxxx would contain = a reference to RFCyyyy, but it was very difficult and time consuming to = locate the description of yyyy, which is often in a different section of = the document. I think you should fix this somehow. One way might be to = add the bis section number to the reference entries. Since the = references and the sectionss are ordered by RFC #, it would be an easy = 2-step lookup from yyyy to a section number to the roadmap entry for = yyyy. The other approach would simply put section ref the in text -- = ".... RFCyyyy (see n.m) ..."=0D =0D o First paragraph p 4: says 5681 is "nearly universally deployed" but = later it is listed (quite properly, I would=0D think) in section 2 as MUST. That would seem to supercede the = deployment frequency. Something like "For instance, RFC 5681 is = considered part of the required core functionality of TCP, although RFC = 5681 is only a Draft Stndard".=0D =0D o 3rd paragraph of 5681 (p 6) is confusing; turn it around so the = sentence begins with 5681 and ends with 1122.=0D =0D o Nit: "Jumbograms" is inconsistently capitalized=0D =0D o First paragraph p9: omit word "traditionally" as misleading. It is = fundamental to VJ CC.=0D =0D o RFC 6633 p.10: Out of order.=0D and: s/provides recommendations/recommends/=0D =0D o Section 3.3: s/provides performance improvement/improves performance/=0D= =0D o Discussion of RFC 2883, p 11: So, the receiver infers it has = unnecessarily retransmitted a packet. What is it supposed to do with = that information?=0D =0D o RFC 4015 12: Seems weird that this is a standards track document and = classified as a SHOULD in your section 3.4, yet it seems that the Eifel = algorithm is defined in an Experimental RFC 3522 in section 4.3. At = least comment on the connection in one or the other.=0D =0D o First sentence 3.7 (p. 14): s/and/from/=0D =0D o RFC 4953 (p 14): s/resets (RSTs)/reset (send RST)/=0D =0D o RFC 5827 (p18) "(and SCTP)" raises the interesting question: can one = say that all the discussion in section 4.2 hold for SCTP as well as TCP?=0D= =0D o I am mystified by Multipath TCP RFCs being scattered into 4.4, 6.2, = 6.4, and 6.5. They all seem to be Experimental. Do you have some reason = for these choices??=0D =0D o RFC 1693. Surely "use more specialized transport protocols" cannot be = the right answer. Is it likely that these specialized protocols = implement all the appropriate TCP congestion control and avoidance, etc? = I think not.=0D =0D o RFC 1705 (p 22) Is it worthwhile to point out that this is=0D the identifier/locator split that has been the subject of much=0D discussion?=0D =0D o RFC 6013 (p 22): s/is publish in 2011/was published in 2011/=0D =0D o RFC 761: s/mostly the/mostly to the/=0D =0D RFC 872: s/ON-A/on-a/=0D =0D RFC 896: This was a trememdously important RFC at the time. I believe = that it first introduced the term and the concept of=0D congestion collapse. =0D =0D Furthermore, it defined an algorithm for=0D efficient transmission of small packets that is still called=0D the Nagle Algorithm or simply "Nagle".=0D =0D RFC 3439: the word "extents" is obviously wrong. Also, 'primary =0D mechanism" does not sound right. How about "... complexity is the = primary impediment to efficient scaling"=0D =0D RFC 2757: ... long thin networks (i.e., networks with low bandwidth and = high delay) ...=0D =0D ZRFC 3366 and 3819 appear to cover roughly the same ground. I assume = they are both the result of Phil Karn's passionate pleas.=0D In any case, if I am right it would be nice to point out the=0D kinship in the Roadmap.=0D =0D o RFC4774: It is unclear that this belongs here; how abou 6.2?=0D Also, suggest s/co- existence in an Internet that may include/\=0D co-existence with/=0D =0D o RFC 5033: Since this document seems to be opposing 2914, ouldn't = it be better to move 5033 to section 6.2 where=0D 2914 appears?=0D =0D o RFC 2525: s/in doing so//=0D =0D o RFC 1337; missing space in title=0D =0D o Header prediction p35: was the typo "acpacket" in Van's message?=0D =0D I am glad youi included Van's message. I have a mailbox on disk in which = I collected Van's messages over a number of years. I=0D always hoped to find time to do a light editing and publish it=0D on the web (Van did give me permission) All together, it is a=0D course in the subtleties of protocols!=0D =0D o Forward Acknowledgement(FACK): Did you define fast retransmit=0D somewhere earlier? A backward ref to it would be helpful here.=0D =0D Cheers,=0D =0D Bob Braden= --Apple-Mail=_AF67436C-8CC2-443E-ADA5-CB45B71AD4FA-- --Apple-Mail=_6969B0E8-4B4C-42F4-92C0-7E40691771C8 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 iEYEARECAAYFAlIXXIIACgkQdyiq39b9uS6zngCgwFnvg1AzdByJiPsTlyhHh2Eo Jy8AoNy/xxxN5xIhYhuVcFAgjm79OWgg =vLc2 -----END PGP SIGNATURE----- --Apple-Mail=_6969B0E8-4B4C-42F4-92C0-7E40691771C8-- From ietf-secretariat-reply@ietf.org Fri Aug 23 03:12:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDEB21F8887 for ; Fri, 23 Aug 2013 03:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-Pn+f0az9pI for ; Fri, 23 Aug 2013 03:12:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4087F21F9BAD for ; Fri, 23 Aug 2013 03:12:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130823101234.32011.50447.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2013 03:12:34 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 23 Aug 2013 08:12:34 -0700 Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Aug 2013 10:12:35 -0000 Changed milestone "Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tcpm/charter/ From michael.scharf@alcatel-lucent.com Fri Aug 23 08:38:54 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88A11E82FC for ; Fri, 23 Aug 2013 08:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsudNLth1sQf for ; Fri, 23 Aug 2013 08:38:49 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7126A11E82FB for ; Fri, 23 Aug 2013 08:38:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r7NFckWp013845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Aug 2013 10:38:48 -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 r7NFckrf011506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 17:38:46 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 23 Aug 2013 17:38:46 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Berlin Minutes Thread-Index: AQHOn7VFiWkJcy2TskafcJ+U5K5qDZmi7NQA Date: Fri, 23 Aug 2013 15:38:45 +0000 Message-ID: <655C07320163294895BBADA28372AF5D087D44@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Mark Nottingham Subject: [tcpm] FW: Berlin Minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Aug 2013 15:38:54 -0000 "### Transport Joint Meeting" (partly) matters to TCPM... Michael -----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net]=20 Sent: Friday, August 23, 2013 5:57 AM To: ietf-http-wg@w3.org Group Subject: Berlin Minutes ... are now up at: http://www.ietf.org/proceedings/87/minutes/minutes-87-httpbis Corrections / updates to me. Regards, -- Mark Nottingham http://www.mnot.net/ From michael.scharf@alcatel-lucent.com Fri Aug 23 11:18:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB40811E811B for ; Fri, 23 Aug 2013 11:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, GB_I_INVITATION=-2, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqMOF7RdWgtt for ; Fri, 23 Aug 2013 11:18:31 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6D311E810D for ; Fri, 23 Aug 2013 11:18:26 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7NIILwC028004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Aug 2013 13:18:23 -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 r7NIIK9W002919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 20:18:20 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.60]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 23 Aug 2013 20:18:20 +0200 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Thread-Topic: [tcpm] Feedback on TCP Fast Open? Thread-Index: Ac6PaI4pnwTAopi7RjGsw4hp5IioMgADhLSAAJaUk2AA3fCfAAK4sB3A Date: Fri, 23 Aug 2013 18:18:19 +0000 Message-ID: <655C07320163294895BBADA28372AF5D0884D4@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D07CBF8@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D07DE77@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "tcpm@ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [tcpm] Feedback on TCP Fast Open? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Aug 2013 18:18:35 -0000 SGkgWXVjaHVuZywgaW5saW5lLi4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tXSANCj4gU2VudDog U2F0dXJkYXksIEF1Z3VzdCAxMCwgMjAxMyAxOjM4IEFNDQo+IFRvOiBTY2hhcmYsIE1pY2hhZWwg KE1pY2hhZWwpDQo+IENjOiBXaWxsaWFtIENoYW4gKLPC1sey/Sk7IHRjcG1AaWV0Zi5vcmc7IGll dGYtaHR0cC13Z0B3My5vcmcNCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBGZWVkYmFjayBvbiBUQ1Ag RmFzdCBPcGVuPw0KPiANCj4gT24gTW9uLCBBdWcgNSwgMjAxMyBhdCA0OjUwIEFNLCBTY2hhcmYs IE1pY2hhZWwgKE1pY2hhZWwpIA0KPiA8bWljaGFlbC5zY2hhcmZAYWxjYXRlbC1sdWNlbnQuY29t PiB3cm90ZToNCj4gPiBIaSBXaWxsIChhbmQgdGhlIG90aGVycyBpbiB0aGlzIHRocmVhZCksDQo+ ID4NCj4gPiBUaGFua3MgYSBsb3QgZm9yIHRoaXMgZXhjZWxsZW50IGZlZWRiYWNrIGFuZCB0aGUg aW5zaWdodHMhIA0KPiBUaGlzIGlzIHZlcnkgbXVjaCBhcHByZWNpYXRlZC4NCj4gPg0KPiA+IEBB dXRob3JzOiBBY3R1YWxseSwgSSB3b25kZXIgaWYgdGhlIHNwZWNpZmljIGFkdmFudGFnZXMgb2Yg DQo+IFRGTyBmb3IgSFRUUFMgY291bGQgYmUgYmV0dGVyIGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1l bnQsIA0KPiBpLmUuLCBpbiBTZWN0aW9uIDYuMz8gRm9yIGluc3RhbmNlLCBieSBzZXBhcmF0ZSBh cHBsaWNhYmlsaXR5IA0KPiBzZWN0aW9ucyBmb3IgSFRUUCBhbmQgSFRUUFM/IElmIGlkZW1wb3Rl bmN5IGlzIG5vdCBhbiBpc3N1ZSANCj4gZm9yIEhUVFBTLCBpdCB3b3VsZCBiZSB3b3J0aHdpbGUg dG8gZXhwbGljaXRseSBzdHJlc3MgdGhhdC4NCj4gSXQncyBhbHJlYWR5IGluIC0wNA0KPiANCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWZhc3RvcGVuLTA0I3Nl Y3Rpb24tNi4zDQoNClllcywgb2YgY291cnNlIEkndmUgc2VlbiB0aGlzLiBNeSBxdWVzdGlvbiBp cyB3aGV0aGVyIGFkdmFudGFnZXMgb2YgVEZPIGZvciBIVFRQUyBjb3VsZCBiZSAqKipiZXR0ZXIq KiogZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudCwgZm9yIGluc3RhbmNlLCBieSAqKipzZXBhcmF0 ZSBhcHBsaWNhYmlsaXR5IHNlY3Rpb25zKioqIGZvciBIVFRQIGFuZCBUTFMvSFRUUFMuDQoNCkZv ciBpbnN0YW5jZSwgSSB3YXMgdGhpbmtpbmcgb2YgdHdvIHNlcGFyYXRlIHNlY3Rpb25zIGZvciB0 aGUgY29udGVudCB0aGF0IGlzIG5vdyBpbiBzZWN0aW9uIDYuMy4xOiANCg0KNi4zLjEgQXBwbGlj YWJpbGl0eSBmb3IgSFRUUA0KDQo2LjMuMiBBcHBsaWNhYmlsaXR5IGZvciBUTFMvSFRUUFMNCg0K VG8gbWUsIFdpbGwncyBleHBsYW5hdGlvbiBvbiB0aGUgYXBwbGljYWJpbGl0eSB0byBUTFMgc2Vl bXMgdXNlZnVsIGluZm9ybWF0aW9uLCBhbmQgY3VycmVudGx5IHRoaXMgaXMgc29tZWhvdyBoaWRk ZW4gYXQgdGhlIHZlcnkgZW5kIG9mIHNlY3Rpb24gNi4zLjEuIElmIHBvc3NpYmxlLCBhIHJlZmVy ZW5jZSB3aHkgaWRlbXBvdGVuY3kgZG9lcyBub3QgbWF0dGVyIGZvciBUTFMgd291bGQgYmUgYSBn cmVhdCBwbHVzIC0gYnV0IEkgYW0gbm90IGEgVExTIGV4cGVydCBteXNlbGYgYW5kIGNhbm5vdCBw cm92aWRlIHRoYXQgcmVmZXJlbmNlIG91dCBvZiBteSBoZWFkLg0KDQpNaWNoYWVsIChhcyBpbmRp dmlkdWFsKQ0KDQoNCj4gPiBKdXN0IGFzIGEgdGhvdWdodC4uLg0KPiA+DQo+ID4gTWljaGFlbA0K PiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogd2ls bGNoYW5AZ29vZ2xlLmNvbSBbbWFpbHRvOndpbGxjaGFuQGdvb2dsZS5jb21dIE9uIA0KPiBCZWhh bGYgT2YgDQo+ID4+IFdpbGxpYW0gQ2hhbiAoPz8/KQ0KPiA+PiBTZW50OiBGcmlkYXksIEF1Z3Vz dCAwMiwgMjAxMyAzOjUyIFBNDQo+ID4+IFRvOiBTY2hhcmYsIE1pY2hhZWwgKE1pY2hhZWwpDQo+ ID4+IENjOiBpZXRmLWh0dHAtd2dAdzMub3JnOyB0Y3BtQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6 IFJlOiBGZWVkYmFjayBvbiBUQ1AgRmFzdCBPcGVuPw0KPiA+Pg0KPiA+PiBUaGFua3MgZm9yIHRo ZSBpbnZpdGF0aW9uIGZvciBmZWVkYmFjay4NCj4gPj4NCj4gPj4gSSd2ZSBiZWVuIHRoZSBwcmlt YXJ5IGNvbnRhY3Qgb24gdGhlIENocm9taXVtIC8gR29vZ2xlIA0KPiBDaHJvbWUgbmV0d29yayAN Cj4gPj4gc3RhY2sgdGVhbSBmb3IgWXVjaHVuZyBhbmQgdGhlIG90aGVyIFRDUCBGYXN0IE9wZW4g YXV0aG9ycyANCj4gYXQgR29vZ2xlLCANCj4gPj4gc28gd2hpbGUgSSBvbmx5IGx1cmsgaW4gdGNw bSwgSSd2ZSBiZWVuIHJlYXNvbmFibHkgDQo+IGludm9sdmVkIGluIHRoaXMgDQo+ID4+IHBhcnRp Y3VsYXIgZmVhdHVyZS4gSSd2ZSB0aG91Z2h0IGEgbG90IGFib3V0IGhvdyB3ZSB3b3VsZCANCj4g dXNlIHRoaXMgaW4gDQo+ID4+IENocm9taXVtIGlmIGF2YWlsYWJsZS4NCj4gPj4gRm9yIHNvbWUg ZGV0YWlsZWQgdGhvdWdodHMgaW50ZW5kZWQgZm9yIGEgYnJvd3NlciBpbXBsZW1lbnRvciANCj4g Pj4gYXVkaWVuY2UsIHlvdSBjYW4gcmVhZCB0aG9zZSBkZXRhaWxzIGF0IG15IGJsb2cgDQo+ID4+ IChodHRwczovL2luc291Y2lhbnQub3JnL3RlY2gvc29tZS1xdWljay10aG91Z2h0cy1vbi10Y3At ZmFzdC1vDQo+ID4+IHBlbi1hbmQtY2hyb21pdW0vKS4NCj4gPj4NCj4gPj4gVGhlIHNob3J0IG9m IGl0IGlzLCBmb3IgdmFuaWxsYSBIVFRQLCBpdCdzIHVuY2xlYXIgaG93IA0KPiBiZW5lZmljaWFs IGl0IA0KPiA+PiB3b3VsZCBiZSBmb3IgdXMgc2luY2Ugd2UgYWxyZWFkeSBoYXZlIHN1Y2ggZ2Fp bnMgZm9yIGJyb3dzZXIgDQo+ID4+IHByZWNvbm5lY3QgKG91ciBicm93c2VyIGZlYXR1cmUgdGhh dCBsZWFybnMgZnJvbSBwYXN0IHdlYiANCj4gYnJvd3NpbmcgdG8gDQo+ID4+IHNwZWN1bGF0aXZl bHkgZXN0YWJsaXNoIGNvbm5lY3Rpb25zLCB0eXBpY2FsbHkganVzdCBUQ1AgDQo+IGNvbm5lY3Rp b25zIA0KPiA+PiBidXQgcGVyaGFwcyBkb2luZyBhIFRMUyBvciBvdGhlciBoYW5kc2hha2VzIHRv byBhcyANCj4gbmVlZGVkKS4gVGhlcmUncyBhIA0KPiA+PiBmdW5kYW1lbnRhbCB0ZW5zaW9uIGJl dHdlZW4gb3VyIHByZWNvbm5lY3QgZmVhdHVyZSBhbmQgVENQIA0KPiBGYXN0IE9wZW4gDQo+ID4+ IGZvciB2YW5pbGxhIEhUVFAuIEZ1cnRoZXIgZXhwZXJpbWVudGF0aW9uIGlzIG5lY2Vzc2FyeSBh bmQgDQo+IHdlJ3ZlIGJlZW4gDQo+ID4+IHdvcmtpbmcgb24gdGhpcy4gSSdtIGhvcGVmdWwgd2Ug Y2FuIGZpbmQgYSB3YXkgdG8gbGV2ZXJhZ2UgDQo+IHRoaXMgZm9yIA0KPiA+PiBvdXIgZ2Fpbiwg YnV0IGl0IHJlcXVpcmVzIG1vcmUgaW52ZXN0aWdhdGlvbi4NCj4gPj4NCj4gPj4gRm9yIFRMUyBv dmVyIFRDUCwgdGhlcmUgaXMgYSBtdWNoIG1vcmUgb2J2aW91cyB3aW4gc2luY2Ugd2UgY2FuIA0K PiA+PiBzcXVlZXplIHRoZSBUTFMgQ0xJRU5UX0hFTExPIGludG8gdGhlIFRDUCBTWU4sIGFuZCB0 aGVyZSBpcyBubyANCj4gPj4gY29uY2VybiBhYm91dCB2aW9sYXRpbmcgaWRlbXBvdGVuY3kuIFRo aXMgY29tYmluZXMgd2l0aCBvdXIgDQo+ID4+IHByZWNvbm5lY3QgZmVhdHVyZSB2ZXJ5IG5pY2Vs eSwgc28gSSBhbSByYXRoZXIgZXhjaXRlZCBhYm91dCB0aGUgDQo+ID4+IHBvdGVudGlhbCBmb3Ig dGhpcyB1c2UgY2FzZS4gV2hpbGUgSFRUUFMgYWRvcHRpb24gaXMgc3RpbGwgDQo+IGxvdywgSSdt IA0KPiA+PiBob3BlZnVsIHRoYXQgaXQgd2lsbCBpbmNyZWFzZSBvdmVyIHRpbWUgKGVzcGVjaWFs bHkgZ2l2ZW4gDQo+IHRoZSBjb250ZXh0IA0KPiA+PiBvZiByZWNlbnQgcmV2ZWxhdGlvbnMpLiBT byBJIHRoaW5rIHRoZSBpbXBvcnRhbmNlIG9mIHRoZSBIVFRQUyB1c2UgDQo+ID4+IGNhc2Ugd2ls bCBncm93LCBhbmQgdGh1cyB0aGUgcG90ZW50aWFsIGltcG9ydGFuY2Ugb2YgVENQIA0KPiBGYXN0 IE9wZW4gaW4gDQo+ID4+IGRlY3JlYXNpbmcgdXNlciBwZXJjZWl2ZWQgbGF0ZW5jeS4NCj4gPj4N Cj4gPj4gQ2hlZXJzLA0KPiA+PiBXaWxsDQo+ID4+DQo+ID4+DQo+ID4+IE9uIEZyaSwgQXVnIDIs IDIwMTMgYXQgMzoxMCBBTSwgU2NoYXJmLCBNaWNoYWVsIChNaWNoYWVsKSANCj4gPj4gPG1pY2hh ZWwuc2NoYXJmQGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+DQo+ID4+ICAg ICAgIEhpIGFsbCwNCj4gPj4NCj4gPj4gICAgICAgQXMgbWVudGlvbmVkIHRvZGF5IG9uIHRoZSBt aWMsIHRoZSBUQ1BNIHdvcmtpbmcgZ3JvdXAgaGFzIGEgDQo+ID4+IHdvcmtpbmcgZ3JvdXAgaXRl bSB0aGF0IGFsbG93cyBkYXRhIHRvIGJlIGNhcnJpZWQgaW4gdGhlIFNZTiBhbmQgDQo+ID4+IFNZ Ti1BQ0sgcGFja2V0cyBhbmQgdGhhdCBpcyBjb25zdW1lZCBieSB0aGUgcmVjZWl2aW5nIGVuZCAN Cj4gZHVyaW5nIHRoZSANCj4gPj4gaW5pdGlhbCBjb25uZWN0aW9uIGhhbmRzaGFrZSwgd2hpY2gg aXMgc2F2ZXMgVENQIGhhbmRzaGFrZXMuIFRoZSANCj4gPj4gZG9jdW1lbnQgd2FzIGRpc2N1c3Nl ZCBhbGVhZHkgZXh0ZW5zaXZlbHkgaW4gVENQTSBhbmQgd2lsbCBiZSANCj4gPj4gdXBkYXRlZC4g VENQTSdzIHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCBpcyBub3QgZmFyIGF3YXkgZnJvbSBXR0xD Lg0KPiA+Pg0KPiA+PiAgICAgICBUaGUgbGluayBpczoNCj4gPj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLWZhc3RvcGVuLTA0DQo+ID4+DQo+ID4+ICAgICAgIElu IHRoZSBzcGlyaXQgb2YgdG9kYXkncyBzZXNzaW9uLCBmZWVkYmFjayBmcm9tIHRoZSBodHRwYmlz IA0KPiA+PiBjb21tdW5pdHkgd291bGQgYmUgdmVyeSBhcHByZWNpYXRlZC4gUGxlYXNlIG5vdGUg dGhhdCB0aGlzIA0KPiBtZWNoYW5pc20gDQo+ID4+IHNsaWdodGx5IGNoYW5nZXMgdGhlIHN0YW5k YXJkIFRDUCBzZW1hbnRpY3MsIGFzIGV4cGxhaW5lZCBpbiB0aGUgDQo+ID4+IGFic3RyYWN0Og0K PiA+Pg0KPiA+PiAgICAgICAgICBIb3dldmVyIFRGTyBkZXZpYXRlcyBmcm9tIHRoZSBzdGFuZGFy ZCBUQ1AgDQo+IHNlbWFudGljcyBpbiB0aGF0IA0KPiA+PiB0aGUgZGF0YSBpbiB0aGUNCj4gPj4g ICAgICAgICAgU1lOIGNvdWxkIGJlIHJlcGxheWVkIHRvIGFuIGFwcGxpY2F0aW9uIGluIHNvbWUg cmFyZSANCj4gPj4gY2lyY3Vtc3RhbmNlcy4NCj4gPj4gICAgICAgICAgQXBwbGljYXRpb25zIHNo b3VsZCBub3QgdXNlIFRGTyB1bmxlc3MgdGhleSBjYW4gdG9sZXJhdGUgDQo+ID4+IHRoaXMgaXNz dWUsDQo+ID4+ICAgICAgICAgIHdoaWNoIGlzIGRldGFpbGVkIGluIHRoZSBBcHBsaWNhYmlsaXR5 IHNlY3Rpb24uDQo+ID4+DQo+ID4+ICAgICAgIEZ1cnRoZXIgaW5mb3JtYXRpb24gY2FuIGJlIGZv dW5kIGluIFNlY3Rpb24gNiBvZiB0aGUgDQo+IGRvY3VtZW50Lg0KPiA+Pg0KPiA+PiAgICAgICBD b21tZW50cyBvciByZXZpZXdzIHdvdWxkIGJlIGhpZ2hseSB3ZWxjb21lLiBUaGUgZGlzY3Vzc2lv biANCj4gPj4gc2hvdWxkIHRha2UgcGxhY2Ugb24gdGhlIFRDUE0gbWFpbGluZyBsaXN0Lg0KPiA+ Pg0KPiA+PiAgICAgICBUaGFua3MhDQo+ID4+DQo+ID4+ICAgICAgIE1pY2hhZWwgKFRDUE0gY28t Y2hhaXIpDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0Y3BtIG1haWxpbmcgbGlzdA0K PiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RjcG0NCj4g From michawe@ifi.uio.no Sun Aug 25 04:24:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300AC21F9BC3 for ; Sun, 25 Aug 2013 04:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.572 X-Spam-Level: X-Spam-Status: No, score=-100.572 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_56=0.6, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfr19Xg+kkCP for ; Sun, 25 Aug 2013 04:24:15 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id A240921F9BCA for ; Sun, 25 Aug 2013 04:24:13 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VDYQS-0003Qb-FP; Sun, 25 Aug 2013 13:24:08 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.103]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VDYQR-0001qm-H6; Sun, 25 Aug 2013 13:24:08 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D08846E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sun, 25 Aug 2013 13:24:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9351F901-37DB-4180-9F9D-EF334CE75A63@ifi.uio.no> References: <655C07320163294895BBADA28372AF5D07F2E3@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D08846E@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1508) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 6866 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D67E8AEFECC87BBCC2F346DC55F5C8EA2D42831A X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 42 max/h 4 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-ietf-tcpm-accecn-reqs-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 11:24:21 -0000 Ahhh, sorry, it went to tcpm-chairs, not tcpm=85 my bad, I didn't see = the mistake in the receiver address, thanks for noticing!! So I'm cc'ing tcpm now, as has always been my intention, sorry again! Michael On Aug 23, 2013, at 7:54 PM, "Scharf, Michael (Michael)" = wrote: > Hi Michael, >=20 > Thanks! >=20 > Have you shared this very useful review with the authors? (Possibly = also with the list?) >=20 > Michael >=20 >=20 >> -----Original Message----- >> From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 >> Sent: Monday, August 12, 2013 3:34 PM >> To: tcpm-chairs@tools.ietf.org >> Subject: Re: Review of draft-ietf-tcpm-accecn-reqs-02 >>=20 >> Hi all, >>=20 >> On 6. aug. 2013, at 16:40, Scharf, Michael (Michael) wrote: >>=20 >>> Hi all, >>>=20 >>> According to our minutes, you volunteered in the TCPM=20 >> meeting to review draft-ietf-tcpm-accecn-reqs-02. The TCPM=20 >> chairs appreciate this a lot, since this document didn't get=20 >> a lot of feedback recently. >>>=20 >>> It would really help if you could have a look at the=20 >> document and post your thoughts to the TCPM mailing list. We=20 >> are specifically interested whether the problem statement and=20 >> the requirements are complete. It would also be of interest=20 >> if the survey of the design approaches misses something. >>>=20 >>> Again, thanks a lot for volunteering! >>>=20 >>> Michael >>=20 >> Here's my review! Answering your questions about completeness=20 >> of the problem statement and requirements, I think so. >> My comments are mostly editorial. Here they are, section by=20 >> section - sorry that they're a mix of nits (many) and=20 >> slightly more important things (not so many). >>=20 >> Secondly, a disclaimer about English: I'm not an English=20 >> speaker, so I might be criticizing things that are in fact=20 >> okay, as I always try to suggest something that I know to be=20 >> correct in case of doubt. More feedback is better than less,=20 >> I guess, so here it goes, all of it: >>=20 >>=20 >> Abstract: >>=20 >> don't think feedback can be used as a word. General fix:=20 >> search "feedback X" and change to "feed X back" (e.g. problem=20 >> is also in intro) >>=20 >> "more accurate ECN feedback information" seems redundant,=20 >> enough with "...ECN feedback" or "...ECN information" >>=20 >> last sentence: requirement_s_ >>=20 >>=20 >> Intro: >>=20 >> "A sender using DCTCP congestion control and=20 >> s/supports/supporting ConEx:" >>=20 >> next item (standard TCP sender) - I'd remove this, it seems=20 >> quite unnecessary here. >>=20 >> Next par: "deliver identical performance" seems strange to=20 >> me, as it's just a signaling scheme - I'd say "as much=20 >> information" or "provide the same signal" or something like that. >>=20 >>=20 >> sec. 1.1: >>=20 >> last par: "more congestion marks belong_ing_ to the same overload..." >>=20 >>=20 >> sec 2: >>=20 >> par 2: s/This leads always/This always leads last line of par=20 >> 2: should be "can not _be_ signaled back..." >>=20 >> next par, last line: "nonce sum is maintain_ed_ that counts..." >>=20 >>=20 >> sec 3: >>=20 >> item resilience: >> "in most cases only every second data packet triggers an=20 >> ACK." isn't precise, in most cases it's *at most every second=20 >> data packet*, but it could well be less. >> last line of this par: "take delayed ACK_s_ and ACK loss..." >>=20 >> next par: >> s/out dated/outdated >> "high dynamic" - didn't get what this means and it sounds=20 >> wrong. Maybe best to stop the sentence before "due to..." >>=20 >> next par: "should be provided how a machanism" - the "how"=20 >> seems wrong somehow, maybe "on how" would be correct. Later=20 >> same sentence: "re-ensure" can just be replaced by ensure to=20 >> be clearer. >>=20 >> next par: "congestion event(remove "s") occurs at least one..." >>=20 >> next par: The very first sentence ("Of course, the more=20 >> accurate..") seems strange and out of place, I'd suggest to=20 >> remove it. Second, it's a bit odd that all the items are=20 >> positive except for the last two (complexity and overhead -=20 >> I'd suggest to replace "Complexity" with "Simplicity" and=20 >> "Overhead" with "Coding efficiency"). >>=20 >> next par: "prepared to s/proved/provide a method to fall-back=20 >> to well known RFC3160 signaling (remove comma) if the new signal..." >>=20 >>=20 >> sec 4: >>=20 >> last line: "any acknowledgement mechanism." - I think *I*=20 >> understand what you mean: that they don't acknowledge back=20 >> from the sender to the receiver, like normal ECN does with=20 >> CWR. However, given that there is a lot of talk about ACKs=20 >> everywhere, this bit could be hard to understand, and I'd=20 >> rather phrase this clearer (maybe simply say "do not=20 >> implement reliable signaling"). >>=20 >>=20 >> sec 4.1 and 4.2: >>=20 >> This is so full of mistakes that I'm actually faster=20 >> copy+pasting the corrected text here, so here it goes, with=20 >> my fixes marked: >>=20 >> ********** >> The three ECN/NS header *flags*, ECE, CWR and NS are=20 >> re-used (not only for >> additional capability negotiation during the TCP handshake exchange >> but) to signal the current value of *a* CE counter at the receiver. >> This approach only provides ** ["a" removed] limited=20 >> resilience against ACK *loss* >> depending of the number of used bits. >>=20 >> There are several codings proposed so far: *A* one bit scheme sends >> one ECE for each CE received (while ** ["the" removed] CWR=20 >> could be used to >> introduce redundant information in *the* next ACK to increase the >> robustness against ACK loss). An 3 bit counter scheme=20 >> uses all three >> bits for continuously feeding *back* the three most=20 >> significant bits of a CE >> counter ** ["back" removed]. *A* 3 bit codepoint scheme=20 >> encodes either a CE counter >> or an ECT(1) counter in 8 codepoints. >>=20 >> The proposed schemes *provide* accumulated information on ECN-CE- >> marking feedback, similar to the number of acknowledged=20 >> bytes in the >> TCP header. Due to the limited number of bits the ECN feedback >> information will wrap-around more often (than the acknowledgement). >> [I don't understand this bracket and suggest removing it.] >> Thus with a smaller number of ACK losses it is already possible to >> loose feedback information. The resilience could be increased by >> introducing redundancy, e.g. send each counter increase=20 >> twice or more >> times. Of course any of these additional mechanisms will increasee >> the complexity. If the congestion rate is larger *than*=20 >> the ACK rate >> (multiplied with the number of feedback *signals*=20 >> ["information" cannot be counted I think] that can be >> *transmitted* per ACK), the congestion information cannot=20 >> correctly be >> *fed* back. Thus an accurate ECN feedback mechanism needs=20 >> to be able >> to also cover the worst case situation where every packet is CE >> marked. This can potentially be realized by dynamically=20 >> *adapting* the >> ACK rate and redundancy which again increases complexity and also >> potentially the signaling overhead. For all schemes, an integrity >> check is only provided if ECN Nonce can be supported. >>=20 >> 4.2. Use of Other Header Bits >>=20 >> As seen in Figure 1, there are currently three unused=20 >> *flags* ["bits" removed] in >> the TCP header. The proposed 3 bit or codepoint schemes could be >> extended by one or more bits ["," removed] to add higher=20 >> resilience against ACK >> loss. The relative gain would be proportionally higher resilience >> against ACK loss, while the respective drawbacks would remain >> identical. >>=20 >> Moreover, the Urgent Pointer could be used if the Urgent=20 >> Flag is not >> set. As this is often the case, the *resilience* could by=20 >> increased >> without additional signaling overhead. >>=20 >> ********* >>=20 >> sec 4.3: >>=20 >> There is the following sentence here "E.g. ECN for RTP/UDP=20 >> provides explicit (should be "explicitly provides") the=20 >> number of ECT(0), ....". I was waiting for such a statement=20 >> to appear much earlier! Here it is out of place, it should be=20 >> move to somewhere in the introduction, and it needs a=20 >> reference to RFC 6679. Similarly, SCTP counts the number of=20 >> ECN marks, and that should also be stated with a reference to=20 >> the RFC or draft specifying it. Putting this in the=20 >> introduction is valuable I think, as it makes it it clear=20 >> that this functionality is really only missing in TCP, it's=20 >> already there in SCTP and RTP/UDP! >>=20 >> "ECN feedback is not such a critical information": remove "a"=20 >> before "critical", and "not such" doesn't sound good I=20 >> think... it's also a rather imprecise statement. Maybe "not=20 >> extremely critical information" would be better? I don't like=20 >> that one very much either but it's the best I can come up=20 >> with right now. >>=20 >>=20 >> sec 7: par 1 starts with "this scheme" =3D> which scheme?? The=20 >> draft only discusses schemes. You could say "schemes that=20 >> signal more precise ECN information" here. In sentence 2 you=20 >> also say "those schemes" which is strange now but would okay=20 >> if you fix sentence 1. >>=20 >>=20 >> Finally, the last 5 references are not cited in the text.=20 >> AFAIK it's bad style to add references but not cite them - if=20 >> you don't cite them they are unnecessary. >>=20 >>=20 >> That's all folks - I hope it's helpful! >> Michael >>=20 From ycheng@google.com Thu Aug 29 15:30:39 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5B521F9CFB for ; Thu, 29 Aug 2013 15:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwZWXZfQcXvQ for ; Thu, 29 Aug 2013 15:30:38 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 26F2611E817D for ; Thu, 29 Aug 2013 15:30:36 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j10so1146103oah.1 for ; Thu, 29 Aug 2013 15:30:36 -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 :content-type; bh=aV6pGHUgqM2okv5YDKd/OCq7nDAdq0ZfIQuLJtMLchk=; b=bZKmvOP0LcuUUMKkXjIjUishFA30UZOfehYCJu4vfFJjA89ZxHDbAeUMUCpqWI0W5M +wO2bFPMFUGV+WRib8JrpdKBfuDj4yGSjCONgyY06YN5p/dX/8zVPRB7128/xDl8acDm bYzSVKzQ4icCcfHRCGtkvpsqywEaBmqF35nmrKyMnaS0SIUwBTBTm3lzttBPJw3udFQU xuQPThLyj86Y0XotFFqqVW3Sl/n5JMiluWnPQhbhdscqlV+8nxcpw9cSLGILG3L+VKhc Zvr8aqwAgGUN56fBRQKolaCe6ai/isjA6nvg1+hyvFGvIbJwwvU4/1d/xQXDNB7mJQoP R28Q== 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:content-type; bh=aV6pGHUgqM2okv5YDKd/OCq7nDAdq0ZfIQuLJtMLchk=; b=Fc8mCm3VqDir9yVRZNVVPjQUmHgmHjvL4dP1huFiiqICXLgEokBsKfKW+7FB+8mx/K tOCzPxAiysLq6Cvf2MCeQ4kFXFcmSxAVdUIprv0RWCoQGp2PXW8IJaWblpNr4Y3uWare 8HuSlYX+C0uyshb6HEzv0Nb56tADWwPItc9azdkuo5Erq/n4k6h7Izt3kzyPFZKr94cN F0Av7LAow7FJ4zqoqsy6brJWK4MEEzzh6/c3wu4OAbP0l+qDr0d1ysqU9/QOiOXfjMG1 xmsu1PfqGtj4bOC51UzOFDLStF0njneCB+fosQrS3RAlTtKBeaHeWsXEYG8oTsEpzhXX zY6g== X-Gm-Message-State: ALoCoQk4/2lNZPAfA9atTh6iGS0Orc5E3gx4EG1DFd5UyVEL1Z7sbX7L5prh9dkg56d6KiqPjEqM4912uk4sXcXkXzludeeQYnieHL5CEugi19iR6R6fEm8p97kR+mfD2Dw+BRbGNN4Lsin0aDHVBapr9fOhNyhN7Nsx2JsqHXL5TlC6aPN83t7Wx1ol8BCslZR8ykgaEPFr X-Received: by 10.60.16.104 with SMTP id f8mr2669978oed.71.1377815436489; Thu, 29 Aug 2013 15:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.28.67 with HTTP; Thu, 29 Aug 2013 15:30:16 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 29 Aug 2013 15:30:16 -0700 Message-ID: To: "iccrg@cs.ucl.ac.uk list" , "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] Fwd: Initial batch of packetdrill tests X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Aug 2013 22:30:39 -0000 Many people asked for more test examples for packetdrill after my iccrg presentation in berlin. Here you go :) Tests for other implementation or extensions to cover other protocols are welcome. ---------- Forwarded message ---------- From: Barath Raghavan Date: Thu, Aug 29, 2013 at 7:37 AM Subject: Initial batch of packetdrill tests To: packetdrill@googlegroups.com Hi all, We've put out an initial batch of packetdrill test scripts that test a variety of features of the Linux network stack. We've confirmed that all these tests pass on a stock (Ubuntu) 3.11.0-rc4 kernel. In the new tests/linux/ subdirectory is a brief README file and a run_tests.sh script that flushes TCP metrics before each test run, to avoid test flakiness. Please let us know if you run into any issues or have any comments or questions. Thanks! -Barath -- You received this message because you are subscribed to the Google Groups "packetdrill" group. To unsubscribe from this group and stop receiving emails from it, send an email to packetdrill+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.