From touch@isi.edu Mon Jan 3 16:44:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CD03A65A5 for ; Mon, 3 Jan 2011 16:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHfNrwAuYqcY for ; Mon, 3 Jan 2011 16:43:59 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D53BB3A659C for ; Mon, 3 Jan 2011 16:43:59 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p040joTD020765 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 3 Jan 2011 16:45:50 -0800 (PST) Message-ID: <4D226DBE.3000305@isi.edu> Date: Mon, 03 Jan 2011 16:45:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jerry Chu References: <4D13DD62.3080103@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p040joTD020765 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 00:44:01 -0000 Hi Jerry (et al.), I'd like to hear from others before addressing these issues in detail, but most of them are just a matter of picking a reasonable default or alternative. The parameters proposed in the doc were intended as a starting point for discussion. Joe On 12/26/2010 12:57 PM, Jerry Chu wrote: > Hi Joe, > > Thanks for the writeup. Your proposal seems like a good step toward > finding a permanent solution to the IW problem. The following are my > comments: > > 1. The long check period (e.g., one month) is necessary to allow > enough samples to avoid false negative/postives and ensure > stability/convergence. But many hosts today won't survive that long > period without a reboot, hence losing all the IW/counter statistics > and have to start over again. This includes not only most of the > client devices but many servers as well. > > What this implies is basically the algorithm will never (or rarely) > have enough time to move IW, either up or down. Even it did, upon the > next reboot the latest IW is lost. Does it start from scatch then? > > 2. To fix the above problem requires either some local persitent > storage or some external (e.g., through the network) storage to save > counters more frequently. This is certainly doable, but will > introduce a lot of complexity, basically ruining the simplicity of > the algorithm you proposed. > > For some hosts the above may not even be feasible. > > 3. The proposed check > > "if (IWnotchecked&& ((ISN - seqno)/MSS< IW))) {" > > under "3. During a retransmission,...", although simple (hence > meeting the KISS requirement), counts against IW even though the > initial burst may be smaller than IW. OTOH, tracking the actual > burst sizes more accurately and counting them against 3..IW buckets > as Mark Allman described earlier adde more complexity. Is it really > necessary? > > For a web server the size distribution of the HTTP responses drops > off quickly after certain threshold. Assuming we decide our loss > tolerant level is 5%. When the IW is bumped to certain leve, e.g., > 20, there may be less than 5% of HTTP responses that are greater > than 20*1460 = 30KB. Assuming IW<= 20 is all good but IW> 20 is > all badness, lumping all the counters together under a single IW > may never fail the 95% check, hence allowing IW to grow unbounded > even though those connections with response sizes greater than 16 > always suffer. One may argue the small percentage of connections > sort of justifying fudging it out. But if one judges from the > volume (of just the initial bursts) it may not be insignificant. > > A good compromise may be to track only connections with burst > sizes = IW, or>= IW minus some threshold, relying on the fact > that the ones below IW minus some threshold have been verified > before so it's not too risky not to continue to validate them. > > This does unfortunately require some code, although minimal, to be > added to the fast path to check the initial burst size. In some > implementations it may not even be easy to accurately delineate/ > compute the "burst" size, but one can always fudge in that case. > > 4. The proposal makes an assumption that the choice of IW is to > be blamed if the percentage of connection experiencing pkt loss > during its IW is greater than some threshold. But this may not be > true. A host may experience high loss percentage regardless of IW. > E.g., IW3 performs as bad as IW10. > > If the losses are spread across a large percentage of connections, > then one can argue it's moot whether an optimal IW is picked because > performance will suck for most connections anyway (assuming a high > loss threshold of, e.g., 5%). But if the losses concentrate on only > 5% of remote peers and these peers suffer real high pkt loss rate, > this false positive will forbid IW to ever grow, and hence deprives > the rest 95% connections of the benefit of a larger IW. > > I have no idea how often this false positive case might exist but > if it turns out to be a large percentage then the proposal will be > worthless in terms of addressing the small IW problem. > > 5. A possible fix may be to use two sets of counters rather than one. > One tracks the loss rate of all the initial burst sizes<= 3. The > other tracks the rest upto IW. Then compare the two, and allow IW to > increase if the loss rate of the second set is within some threshold > (either absolute or some percentage) of the first one. > > But one problem with the above is that the number of the base case > (IW3) may have been negatively affected by other hosts moving up to > a higher IW. > > 6. Regarding te sequence number wrap around problem, one can add a > simple check to reset IWnotchecked when seqno goes beyond IW but > this requres adding a check to the past path. I agree this issue is > tiny that may be ignored and just allow the false positive. > > 7. [Ch10] - misses N. Dukkipati as a co-author. > > Jerry > > On Thu, Dec 23, 2010 at 3:38 PM, Joe Touch wrote: >> Hi, all, >> >> A preliminary draft has been posted: >> >> http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt >> >> It includes the algorithm and a lot of other details, some fleshed out (the >> intro), others as a list. The goal is to use this as a basis of initial >> discussion. >> >> (I have not determined the author list yet, so it says TBD right now...) >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From ycheng@google.com Mon Jan 3 16:54:45 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899AB3A67E3 for ; Mon, 3 Jan 2011 16:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.059 X-Spam-Level: X-Spam-Status: No, score=-104.059 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMNpzyNyoT-T for ; Mon, 3 Jan 2011 16:54:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A97523A67E1 for ; Mon, 3 Jan 2011 16:54:43 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p040uoJm027308 for ; Mon, 3 Jan 2011 16:56:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294102610; bh=jMEo/y8uU4+39CocaGLbjjV1fGQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xTbOi6IM4B4Wn8eBt1GBjB+kgr1eBJIb1bpaIhBwOhu6rwbdFBShCgNkCt17vzNuC QpAa8lo0u3ZWj5H8w4BgA== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by wpaz5.hot.corp.google.com with ESMTP id p040umV3009380 for ; Mon, 3 Jan 2011 16:56:49 -0800 Received: by qwe5 with SMTP id 5so17247005qwe.40 for ; Mon, 03 Jan 2011 16:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=BI77fQXf26FD1zhmxdnrc003RKvNzjGGOmvnTJ3wcWo=; b=jpJDPDgMOOW97U8ZaBxhIcyl9C45aUe39KOdngNFF3pp1HCCOXyDZdg7KaTsFt7fl2 okFDjF/Cddh5u+VlvM/Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=EfnaXMPBMuQc0KPlDQ8R851Vt8t8Tdy3PDfHkmvipt0/hvk9HnsVRzHmEhyOXZNB88 bLqiGuMHxabtXnaCKvEg== Received: by 10.224.28.210 with SMTP id n18mr19860648qac.191.1294102608660; Mon, 03 Jan 2011 16:56:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.59.65 with HTTP; Mon, 3 Jan 2011 16:56:27 -0800 (PST) In-Reply-To: References: <20101207033356.439642715136@lawyers.icir.org> From: Yuchung Cheng Date: Mon, 3 Jan 2011 16:56:27 -0800 Message-ID: To: "Per Hurtig (work)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] new version of 2988bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 00:54:46 -0000 Hi Per, The author in [LS00] has a follow-up paper claiming this problem turns out to be a feature. It might be worthwhile to address this part in the proposal. "The peak-hopper: a new end-to-end retransmission timer for reliable unicast transport" http://www.ieee-infocom.org/2004/Papers/52_3.PDF Section II, subsection B. The implicit RTO offset: In previous work, we had identified this as a =93bug=94 [LS00], but our analysis in this study has convinced us that this is actually a feature. This =93responsive safety margin=94 compensates for the problems explained in the following two sub-sections, and especially for the sluggish response to delay spikes often avoids spurious timeouts. It is important to note, though, that this safety margin does not exist for highly interactive applications where often only a single packet is in flight. On Wed, Dec 22, 2010 at 1:16 AM, Per Hurtig (work) wrot= e: > > Hi all, > > we have submitted an I-D that summarizes an alternate way to restart > the TCP/SCTP RTO timer: > > http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt > > The difference between this approach and RFC2988(bis)'s approach is > the way outstanding segments are > considered. We're happy to receive any comments on the draft. > > > Regards, Per H > > > > > On Tue, Dec 7, 2010 at 04:33, Mark Allman wrote: > > > > Folks- > > > > We posted a new version of the 2988bis I-D today. =A0It is: > > > > =A0draft-paxson-tcpm-rfc2988bis-01.txt > > > > The big change is a new set of empirical results that pertain to > > dropping the initial RTO from 3sec to 1sec is now given (along with the > > previous results from Google) in the appendix. =A0Generally speaking, > > these results show it is pretty safe to drop the initial RTO. > > > > Have a look. =A0I believe the authors are pretty happy with this docume= nt > > at this point. > > > > 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 Michael.Scharf@alcatel-lucent.com Tue Jan 4 10:55:58 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36B3A6A7C for ; Tue, 4 Jan 2011 10:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCs0b4BWl-2e for ; Tue, 4 Jan 2011 10:55:57 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 9B7173A6A74 for ; Tue, 4 Jan 2011 10:55:57 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p04Iw3PZ030376; Tue, 4 Jan 2011 19:58:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2011 19:57:03 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0498DA89@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4D13DD62.3080103@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Automatic IW draft posted Thread-Index: Acui+qk+0mGVsJ3fQyOAxYKzL4CBRwJOv05g References: <4D13DD62.3080103@isi.edu> From: "SCHARF, Michael" To: "Joe Touch" , X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 18:55:58 -0000 Joe, the question of byte-based vs. segment-based window management may require some further discussion: IMHO, the condition "if (IWnotchecked && ((ISN - seqno)/MSS < IW))) {" assumes that all sent segments have full size. If an app writes smaller pieces of data (telnet-like), this expression will wrongly count a retransmission that occurs many RTTs after the connection setup, even even if the IW was never fully used. Also, if the sender sends IW segments smaller than the MSS immediately after the connection setup (disabling Nagle) and if a loss occurs, this expression will wrongly not count this retransmission even if IW was indeed used, at least in terms of packets. This will in particular be an issue if a bottleneck is packet-congestible. Therefore, I want to back Jerry's statement that a more careful tracking of the initial burst size may be required. For instance, after the connection setup, one could count the packets and bytes until the arrival of the first new ACK, assuming this to be a definition for the initial burst. In this case, one can easily determine whether a burst of IW was indeed sent (either bytes or packets). The statistics would then consider only the connections that actually used the full IW. But, unfortunately, this seems to require some additional fast path code. BTW, in the Quick-Start implementation we wrote some time ago, we had to implement a similar check in order to determine whether a retransmission was out of the initial burst. As mandated by RFC 4782, we realized this exactly by awaiting the first new ACK. For Slow-Start after idle times, the whole issue is apparently more complex, due to congestion window validation etc. IMHO it may make sense to monitor the IW performance only after connection setup, to keep it simple. In that case, it may be useful to set "IWnotchecked =3D 0" when the congestion window is reset to IW after an idle time. As a side note, IMHO it may make also sense to briefly comment in the draft on the possibility of spurious retransmissions due to reordering, even though this is probably a corner case that might just be ignored. Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Friday, December 24, 2010 12:38 AM > To: tcpm@ietf.org > Subject: [tcpm] Automatic IW draft posted >=20 > Hi, all, >=20 > A preliminary draft has been posted: >=20 > http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt >=20 > It includes the algorithm and a lot of other details, some=20 > fleshed out (the intro), others as a list. The goal is to use=20 > this as a basis of initial discussion. >=20 > (I have not determined the author list yet, so it says TBD=20 > right now...) >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From wwwrun@rfc-editor.org Tue Jan 4 11:18:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DD93A6CD9; Tue, 4 Jan 2011 11:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL2U9dmtefhx; Tue, 4 Jan 2011 11:18:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 63CDE3A6BDB; Tue, 4 Jan 2011 11:18:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C142EE071A; Tue, 4 Jan 2011 11:20:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110104192016.C142EE071A@rfc-editor.org> Date: Tue, 4 Jan 2011 11:20:16 -0800 (PST) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6093 on On the Implementation of the TCP Urgent Mechanism X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 19:18:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6093 Title: On the Implementation of the TCP Urgent Mechanism Author: F. Gont, A. Yourtchenko Status: Standards Track Stream: IETF Date: January 2011 Mailbox: fernando@gont.com.ar, ayourtch@cisco.com Pages: 12 Characters: 25921 Updates: RFC793, RFC1011, RFC1122 I-D Tag: draft-ietf-tcpm-urgent-data-07.txt URL: http://www.rfc-editor.org/rfc/rfc6093.txt This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. 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/rfcsearch.html. 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 nanditad@google.com Wed Jan 5 17:27:25 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862FE3A6E4C for ; Wed, 5 Jan 2011 17:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.476 X-Spam-Level: X-Spam-Status: No, score=-104.476 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufQodRWBXNLd for ; Wed, 5 Jan 2011 17:27:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7BB293A6E4B for ; Wed, 5 Jan 2011 17:27:23 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p061TUUL012465 for ; Wed, 5 Jan 2011 17:29:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294277370; bh=GQj1HVD+/bEL1ghyqu9V0HNFMbE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=g+rGhQYwzOJprskX6X2k725Lkgb1zGviUwIqj3u2FyMI+IzuGHHzyzFlKeonheI/p wS3ZfdZfimXjRDCt8pmpg== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by wpaz37.hot.corp.google.com with ESMTP id p061T0aD016144 for ; Wed, 5 Jan 2011 17:29:29 -0800 Received: by gyg13 with SMTP id 13so7928051gyg.2 for ; Wed, 05 Jan 2011 17:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1lVndF3w8ba/S7aa0NIvZt3vqVrEpB7CSdSf3kMIkbM=; b=VL/Ve9veOYe92wVYGHQP5AtNli40QGXWG0l+zg+61dI5c7yJyejuudptWNgq36O3aH psVP2+XVMASbTeQWFw7w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JRldGPakRWxk8TclPmjiZ2J9aAU1UrHBJnfR0thfgkV+K/dw+JqOhmg9IIdbrEmQiD lgSCyQSH/GVvulC/DsBQ== MIME-Version: 1.0 Received: by 10.90.101.1 with SMTP id y1mr1399996agb.96.1294277368467; Wed, 05 Jan 2011 17:29:28 -0800 (PST) Received: by 10.91.220.20 with HTTP; Wed, 5 Jan 2011 17:29:27 -0800 (PST) In-Reply-To: <4D13DD62.3080103@isi.edu> References: <4D13DD62.3080103@isi.edu> Date: Wed, 5 Jan 2011 17:29:27 -0800 Message-ID: From: Nandita Dukkipati To: Joe Touch Content-Type: multipart/alternative; boundary=0016361e87c2c9d00d0499236e17 X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:27:25 -0000 --0016361e87c2c9d00d0499236e17 Content-Type: text/plain; charset=ISO-8859-1 Joe, I have three high level questions on the draft, mostly aimed at understanding on why we should expect the algorithm to work well in practice. 1) Timescale for determining IW impact. One of the algorithm goals is to adapt to the network feedback (on IW impact) over long timescales. A lot of things change over periods such as a month -- network configurations, topologies, routing, server software, applications, traffic patterns and so on. If the net change due to all the non-IW reasons is larger than or in the same order as the measurable change due to IW, then what does it mean to measure the impact of IW? Please note that this is more then merely choosing the algorithm parameter; it is a core design issue. My concern is partly rooted from our own experience in the large-scale IW experiments. To average out the diurnal patterns and the weekday/weekend differences, it was necessary to run the experiments (baseline IW3 and experiment IW10) over at least one week, i.e., one week of IW3 and one week of IW10. It was an absolute pain to perform an apples-to-apples comparison while adjusting for all the non-IW changes that also took place within these weeks. And this was with a large jump from IW3 to IW10; the impact of a smaller IW change -- such as 2MSS increment -- will be even harder to discern over longer periods. (Soon after, we solved this problem by moving to a new and better experiment infrastructure that allowed setting IW based on IP address hash, thus allowing experimenting with multiple IWs in parallel.) 2) What if losses are bimodal across connections. A core assumption of the proposal is that increasing IW will increase the %connections with losses, which is then used to decide on incrementing/decrementing IW. Again, the real experiments show otherwise. One of the things we tried hard is to figure out what kinds of networks/users we are negatively impacting by increasing losses. While we always observed an overall increased retransmission rate, but not really an increase in %connections or %HTTP responses experiencing losses. But... it may well turn out that (if and when) everyone switches to a larger IW, the above observation is no longer true. However, being a core part of the proposal, I think the assumption needs better (preferably empirical) evidence. 3) Convergence to uniform IW. This is mentioned as one of the goals. With the current specification, my sense is this goal will be hard to achieve. Depending on the region of users served, the %connections with losses can be vastly different across the globe, naturally lower in States/Western Europe, and higher for regions like Africa/India. Since the threshold (5% or whatever number you choose) is a constant, obviously the IW may never get a chance to grow beyond MinIW for certain regions and can grow to MaxIW for others. Do we really need convergence to a uniform value?... something to think about. Thanks, -Nandita On Thu, Dec 23, 2010 at 3:38 PM, Joe Touch wrote: > Hi, all, > > A preliminary draft has been posted: > > http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt > > It includes the algorithm and a lot of other details, some fleshed out (the > intro), others as a list. The goal is to use this as a basis of initial > discussion. > > (I have not determined the author list yet, so it says TBD right now...) > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0016361e87c2c9d00d0499236e17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joe,

I have three hig= h level questions on the draft, mostly aimed at understanding on why we sho= uld expect the algorithm to work well in practice.

1) Timescale for determining IW impact.

One of the= algorithm goals is to adapt to the network feedback (on IW impact) over lo= ng timescales.=A0A lot of things change over periods such as a month -- net= work configurations, topologies, routing, server software, applications, tr= affic patterns and so on. If the net change due to all the non-IW reasons i= s larger than or in the same order as the measurable change due to IW, then= what does it mean to measure the impact of IW?

Please note that this is more then merely choosing the = algorithm parameter; it is a core design issue. My concern is partly rooted= from our own experience in the large-scale IW experiments. To average out = the diurnal patterns and the weekday/weekend differences, it was necessary = to run the experiments (baseline IW3 and experiment IW10) over at least one= week, i.e., one week of IW3 and one week of IW10. It was an absolute pain = to perform an apples-to-apples comparison while adjusting for all the non-I= W changes that also took place within these weeks. And this was with a larg= e jump from IW3 to IW10; the impact of a smaller IW change -- such as 2MSS = increment -- will be even harder to discern over longer periods.

(Soon after, we solved this problem by moving to a new = and better experiment infrastructure that allowed setting IW based on IP ad= dress hash, thus allowing experimenting with multiple IWs in parallel.)

2) What if losses are bimodal across connections.
=

A core assumption of the proposal is that increasing IW= will increase the %connections with losses, which is then used to decide o= n incrementing/decrementing IW. Again, the real experiments show otherwise.= One of the things we tried hard is to figure out what kinds of networks/us= ers we are negatively impacting by increasing losses. While we always obser= ved an overall increased retransmission rate, but not really an increase in= %connections or %HTTP responses experiencing losses.=A0

But... it may well turn out that (if and when) everyone= switches to a larger IW, the above observation is no longer true. However,= being a core part of the proposal, I think the assumption needs better (pr= eferably empirical) evidence.

3) Convergence to uniform IW.

This is men= tioned as one of the goals. With the current specification, my sense is thi= s goal will be hard to achieve.=A0Depending on the region of users served, = the %connections with losses can be vastly different across the globe, natu= rally lower in States/Western Europe, and higher=A0for regions like Africa/= India. Since the threshold (5% or whatever number you choose) is a constant= , obviously the IW may never get a chance to grow beyond MinIW for certain = regions and can grow to MaxIW for others. Do we really need convergence to = a uniform value?... something to think about.

Thanks,
-Nandita


--0016361e87c2c9d00d0499236e17-- From touch@isi.edu Wed Jan 5 17:44:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754513A6BB4 for ; Wed, 5 Jan 2011 17:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5URKhQc4ntU for ; Wed, 5 Jan 2011 17:44:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4113C3A67D4 for ; Wed, 5 Jan 2011 17:44:08 -0800 (PST) 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 p061jkD9001031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 5 Jan 2011 17:45:46 -0800 (PST) Message-ID: <4D251ECA.1030009@isi.edu> Date: Wed, 05 Jan 2011 17:45:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Nandita Dukkipati References: <4D13DD62.3080103@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@ietf.org" Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:44:10 -0000 Hi, Nandita, Overall, what I'd say is that: - if the IW value fluctuates too much, dampen it, or just live with the fluctuations in specific, a fixed IW will be just as susceptible to network changes as well anyway - if IW increases don't result in an increased number of connections with losses, then the IW isn't creating the loss if that happens, then increasing the IW is consistent with the behavior seen - it's not clear that the IW will converge to a globally uniform value it might be more accurate to say that we hope it will converge over sets of connections that share resources Joe On 1/5/2011 5:29 PM, Nandita Dukkipati wrote: > Joe, > > I have three high level questions on the draft, mostly aimed at > understanding on why we should expect the algorithm to work well in > practice. > > 1) Timescale for determining IW impact. > > One of the algorithm goals is to adapt to the network feedback (on IW > impact) over long timescales. A lot of things change over periods such > as a month -- network configurations, topologies, routing, server > software, applications, traffic patterns and so on. If the net change > due to all the non-IW reasons is larger than or in the same order as the > measurable change due to IW, then what does it mean to measure the > impact of IW? > > Please note that this is more then merely choosing the algorithm > parameter; it is a core design issue. My concern is partly rooted from > our own experience in the large-scale IW experiments. To average out the > diurnal patterns and the weekday/weekend differences, it was necessary > to run the experiments (baseline IW3 and experiment IW10) over at least > one week, i.e., one week of IW3 and one week of IW10. It was an absolute > pain to perform an apples-to-apples comparison while adjusting for all > the non-IW changes that also took place within these weeks. And this was > with a large jump from IW3 to IW10; the impact of a smaller IW change -- > such as 2MSS increment -- will be even harder to discern over longer > periods. > > (Soon after, we solved this problem by moving to a new and better > experiment infrastructure that allowed setting IW based on IP address > hash, thus allowing experimenting with multiple IWs in parallel.) > > 2) What if losses are bimodal across connections. > > A core assumption of the proposal is that increasing IW will increase > the %connections with losses, which is then used to decide on > incrementing/decrementing IW. Again, the real experiments show > otherwise. One of the things we tried hard is to figure out what kinds > of networks/users we are negatively impacting by increasing losses. > While we always observed an overall increased retransmission rate, but > not really an increase in %connections or %HTTP responses experiencing > losses. > > But... it may well turn out that (if and when) everyone switches to a > larger IW, the above observation is no longer true. However, being a > core part of the proposal, I think the assumption needs better > (preferably empirical) evidence. > > 3) Convergence to uniform IW. > > This is mentioned as one of the goals. With the current specification, > my sense is this goal will be hard to achieve. Depending on the region > of users served, the %connections with losses can be vastly different > across the globe, naturally lower in States/Western Europe, and > higher for regions like Africa/India. Since the threshold (5% or > whatever number you choose) is a constant, obviously the IW may never > get a chance to grow beyond MinIW for certain regions and can grow to > MaxIW for others. Do we really need convergence to a uniform value?... > something to think about. > > Thanks, > -Nandita > > On Thu, Dec 23, 2010 at 3:38 PM, Joe Touch > wrote: > > Hi, all, > > A preliminary draft has been posted: > > http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt > > It includes the algorithm and a lot of other details, some fleshed > out (the intro), others as a list. The goal is to use this as a > basis of initial discussion. > > (I have not determined the author list yet, so it says TBD right now...) > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From ycheng@google.com Wed Jan 5 18:21:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705F93A67E3 for ; Wed, 5 Jan 2011 18:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.917 X-Spam-Level: X-Spam-Status: No, score=-105.917 tagged_above=-999 required=5 tests=[AWL=-3.940, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRYxIopCMTo7 for ; Wed, 5 Jan 2011 18:21:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 009A73A67B4 for ; Wed, 5 Jan 2011 18:21:06 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p062NBDE010270 for ; Wed, 5 Jan 2011 18:23:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294280592; bh=lmCcTVvgEZYDeDdrcdPBarFrzi0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=bwaWDz7ant1seY66UMpbA7IOOgYwfP1XI1Yk/fLyYHbXdbngMUTSG/w2EI09pFMJI TjQ17ric3y1Bd7SI7tqEw== Received: from vws8 (vws8.prod.google.com [10.241.21.136]) by kpbe11.cbf.corp.google.com with ESMTP id p062NAZx029375 for ; Wed, 5 Jan 2011 18:23:10 -0800 Received: by vws8 with SMTP id 8so6759295vws.40 for ; Wed, 05 Jan 2011 18:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=g8INggye2Dl/TgB6OOwJefyILcIXpXdiz7nK9ksFSRI=; b=doMRNw1g+Az464IPYSoeK+swqzRRdJLuvnGL6xfTgPJGf4Ig+a4vKnw4JHip5rGflr 5xxuxSKBUfJ3t/friF1g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Zc8loww9eOEVE2iNnFlvM/4s0OdZO02rLrMK1XUXxjzHKnl6bJRJDgKKATlx+Ayvg6 dGLEnQeJQRu7m21OVmtw== Received: by 10.220.198.134 with SMTP id eo6mr3495641vcb.277.1294280589913; Wed, 05 Jan 2011 18:23:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.59.65 with HTTP; Wed, 5 Jan 2011 18:22:49 -0800 (PST) In-Reply-To: <4D251ECA.1030009@isi.edu> References: <4D13DD62.3080103@isi.edu> <4D251ECA.1030009@isi.edu> From: Yuchung Cheng Date: Wed, 5 Jan 2011 18:22:49 -0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:21:08 -0000 On Wed, Jan 5, 2011 at 5:45 PM, Joe Touch wrote: > Hi, Nandita, > > Overall, what I'd say is that: > > - if the IW value fluctuates too much, dampen it, or just live with the > fluctuations > =A0 =A0 =A0 =A0in specific, a fixed IW will be just as susceptible to > =A0 =A0 =A0 =A0network changes as well anyway > > - if IW increases don't result in an increased number of connections with > losses, then the IW isn't creating the loss A higher IW may result in creating more losses for certain types of networks/connections, hence the ratio of connection experiences remain constant but the overall loss rate increase. We observe that in our live traffic experiments. Her point is that % of connections experiencing losses alone may not be sufficient to indicate an overly sized IW. > =A0 =A0 =A0 =A0if that happens, then increasing the IW is consistent > =A0 =A0 =A0 =A0with the behavior seen > > - it's not clear that the IW will converge to a globally uniform value > =A0 =A0 =A0 =A0it might be more accurate to say that we hope it will > =A0 =A0 =A0 =A0converge over sets of connections that share resources > > Joe > > On 1/5/2011 5:29 PM, Nandita Dukkipati wrote: >> >> Joe, >> >> I have three high level questions on the draft, mostly aimed at >> understanding on why we should expect the algorithm to work well in >> practice. >> >> 1) Timescale for determining IW impact. >> >> One of the algorithm goals is to adapt to the network feedback (on IW >> impact) over long timescales. A lot of things change over periods such >> as a month -- network configurations, topologies, routing, server >> software, applications, traffic patterns and so on. If the net change >> due to all the non-IW reasons is larger than or in the same order as the >> measurable change due to IW, then what does it mean to measure the >> impact of IW? >> >> Please note that this is more then merely choosing the algorithm >> parameter; it is a core design issue. My concern is partly rooted from >> our own experience in the large-scale IW experiments. To average out the >> diurnal patterns and the weekday/weekend differences, it was necessary >> to run the experiments (baseline IW3 and experiment IW10) over at least >> one week, i.e., one week of IW3 and one week of IW10. It was an absolute >> pain to perform an apples-to-apples comparison while adjusting for all >> the non-IW changes that also took place within these weeks. And this was >> with a large jump from IW3 to IW10; the impact of a smaller IW change -- >> such as 2MSS increment -- will be even harder to discern over longer >> periods. >> >> (Soon after, we solved this problem by moving to a new and better >> experiment infrastructure that allowed setting IW based on IP address >> hash, thus allowing experimenting with multiple IWs in parallel.) >> >> 2) What if losses are bimodal across connections. >> >> A core assumption of the proposal is that increasing IW will increase >> the %connections with losses, which is then used to decide on >> incrementing/decrementing IW. Again, the real experiments show >> otherwise. One of the things we tried hard is to figure out what kinds >> of networks/users we are negatively impacting by increasing losses. >> While we always observed an overall increased retransmission rate, but >> not really an increase in %connections or %HTTP responses experiencing >> losses. >> >> But... it may well turn out that (if and when) everyone switches to a >> larger IW, the above observation is no longer true. However, being a >> core part of the proposal, I think the assumption needs better >> (preferably empirical) evidence. >> >> 3) Convergence to uniform IW. >> >> This is mentioned as one of the goals. With the current specification, >> my sense is this goal will be hard to achieve. Depending on the region >> of users served, the %connections with losses can be vastly different >> across the globe, naturally lower in States/Western Europe, and >> higher for regions like Africa/India. Since the threshold (5% or >> whatever number you choose) is a constant, obviously the IW may never >> get a chance to grow beyond MinIW for certain regions and can grow to >> MaxIW for others. Do we really need convergence to a uniform value?... >> something to think about. >> >> Thanks, >> -Nandita >> >> On Thu, Dec 23, 2010 at 3:38 PM, Joe Touch > > wrote: >> >> =A0 =A0Hi, all, >> >> =A0 =A0A preliminary draft has been posted: >> >> =A0 =A0http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt >> >> =A0 =A0It includes the algorithm and a lot of other details, some fleshe= d >> =A0 =A0out (the intro), others as a list. The goal is to use this as a >> =A0 =A0basis of initial discussion. >> >> =A0 =A0(I have not determined the author list yet, so it says TBD right >> now...) >> >> =A0 =A0Joe >> =A0 =A0_______________________________________________ >> =A0 =A0tcpm mailing list >> =A0 =A0tcpm@ietf.org >> =A0 =A0https://www.ietf.org/mailman/listinfo/tcpm >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mallman@icir.org Wed Jan 5 19:51:57 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F913A6896 for ; Wed, 5 Jan 2011 19:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.347 X-Spam-Level: X-Spam-Status: No, score=-106.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slO6FLdzNKA3 for ; Wed, 5 Jan 2011 19:51:56 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id A954E3A67E2 for ; Wed, 5 Jan 2011 19:51:56 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p063s0jG026426; Wed, 5 Jan 2011 19:54:00 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A82562A12A26; Wed, 5 Jan 2011 22:54:00 -0500 (EST) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma15576-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 Jan 2011 22:54:00 -0500 Sender: mallman@icir.org Message-Id: <20110106035400.A82562A12A26@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 06 Jan 2011 03:51:57 -0000 ----------ma15576-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 1. The long check period (e.g., one month) is necessary to allow > enough samples to avoid false negative/postives and ensure > stability/convergence. But many hosts today won't survive that long > period without a reboot, hence losing all the IW/counter statistics > and have to start over again. This includes not only most of the > client devices but many servers as well. > > What this implies is basically the algorithm will never (or rarely) > have enough time to move IW, either up or down. Even it did, upon the > next reboot the latest IW is lost. Does it start from scatch then? This seems like an excessively minor point to me. Stuffing a few counters and a config setting into non-volatile storage every so often is pretty trivial. E.g., think about doing it twice a day or something so at most you lose 12 hours of state. Basically, if a host doesn't want to take the bother to try to track this information over time then they can deal with the implications of not using a larger initial cwnd because they are not tracking things well enough to ensure they are doing so safely. I just can't see this as some sort of big issue ... > For a web server the size distribution of the HTTP responses drops > off quickly after certain threshold. Assuming we decide our loss > tolerant level is 5%. When the IW is bumped to certain leve, e.g., > 20, there may be less than 5% of HTTP responses that are greater > than 20*1460 = 30KB. Assuming IW <= 20 is all good but IW > 20 is > all badness, lumping all the counters together under a single IW > may never fail the 95% check, hence allowing IW to grow unbounded > even though those connections with response sizes greater than 16 > always suffer. One may argue the small percentage of connections > sort of justifying fudging it out. But if one judges from the > volume (of just the initial bursts) it may not be insignificant. Right... this proposal turns on having a tolerance for "badness". If we want to meaningfully increase IW then there will be badness. The adaptive scheme sets up a way to manage that badness. Can we construct scenarios that are still bad? Sure. But, that is always the case. E.g., IW=10 might be a fine general value, but it might always hurt performance to some given host. allman ----------ma15576-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0lPNgACgkQWyrrWs4yIs50VgCeL+nXuuA7Js/toyBmpae51TuN K/0An39p7w/AFygIhY9RulnRwrWKl6qr =467a -----END PGP SIGNATURE----- ----------ma15576-1-- From mallman@icir.org Wed Jan 5 19:52:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C651D3A6E60 for ; Wed, 5 Jan 2011 19:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjGgFTL8E-5r for ; Wed, 5 Jan 2011 19:52:03 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6159B3A6E5F for ; Wed, 5 Jan 2011 19:52:03 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p063s8fA026492; Wed, 5 Jan 2011 19:54:08 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1C3E12A12A49; Wed, 5 Jan 2011 22:54:08 -0500 (EST) To: Nandita Dukkipati From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma15583-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 Jan 2011 22:54:08 -0500 Sender: mallman@icir.org Message-Id: <20110106035408.1C3E12A12A49@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 06 Jan 2011 03:52:04 -0000 ----------ma15583-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > One of the algorithm goals is to adapt to the network feedback (on IW > impact) over long timescales. A lot of things change over periods such > as a month -- network configurations, topologies, routing, server > software, applications, traffic patterns and so on. If the net change > due to all the non-IW reasons is larger than or in the same order as > the measurable change due to IW, then what does it mean to measure the > impact of IW? I don't follow this at all. The IW is never the problem. The characteristics of the path are the problem. So, yeah, the path changes and the traffic mix changes and configs change and so the dynamics change. We are just trying to find a reasonable---not optimal---initial setting for the context the host is operating in. We are not trying to somehow tease apart root causes here, but rather just trying to arrive at a roughly OK initial setting for the vast majority of the cases. > 2) What if losses are bimodal across connections. > > A core assumption of the proposal is that increasing IW will increase the > %connections with losses, which is then used to decide on > incrementing/decrementing IW. Again, the real experiments show otherwise. > One of the things we tried hard is to figure out what kinds of > networks/users we are negatively impacting by increasing losses. While we > always observed an overall increased retransmission rate, but not really an > increase in %connections or %HTTP responses experiencing losses. > > But... it may well turn out that (if and when) everyone switches to a larger > IW, the above observation is no longer true. However, being a core part of > the proposal, I think the assumption needs better (preferably empirical) > evidence. I don't follow this. The proposal is to *use* empirical evidence to arrive at a reasonable value for an initial parameter setting. > 3) Convergence to uniform IW. > > This is mentioned as one of the goals. With the current specification, my > sense is this goal will be hard to achieve. Depending on the region of users > served, the %connections with losses can be vastly different across the > globe, naturally lower in States/Western Europe, and higher for regions like > Africa/India. Since the threshold (5% or whatever number you choose) is a > constant, obviously the IW may never get a chance to grow beyond MinIW for > certain regions and can grow to MaxIW for others. Do we really need > convergence to a uniform value?... something to think about. I agree that this seemed like a bogus bit in Joe's draft to me. We don't need to converge to anything but a reasonable value for whatever context a particular host operates in. allman ----------ma15583-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0lPN8ACgkQWyrrWs4yIs7+xwCeK7bxHPMUihXsw5Zw2YqMluBX IF0AnizS8TK1lkZFoPSj1M+0O7hyHB30 =h8h4 -----END PGP SIGNATURE----- ----------ma15583-1-- From hkchu@google.com Wed Jan 5 22:04:42 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5FA3A69B9 for ; Wed, 5 Jan 2011 22:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.416 X-Spam-Level: X-Spam-Status: No, score=-105.416 tagged_above=-999 required=5 tests=[AWL=-3.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGOPaN7KU-4o for ; Wed, 5 Jan 2011 22:04:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id C662F3A6B1E for ; Wed, 5 Jan 2011 22:04:40 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p0666k5c024294 for ; Wed, 5 Jan 2011 22:06:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294294007; bh=PqdcRHerTECUuCy2c8q9q+jMv88=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wciXPEQzan+ZJdkJ36lGm9JrifsMcLIoeGFiTVg+hwFv45IoocFLDDeaJG0LSw2wt gTDpR7pZjzg+YE+e0eHnQ== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by wpaz17.hot.corp.google.com with ESMTP id p0666jNr003469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 5 Jan 2011 22:06:45 -0800 Received: by ywo7 with SMTP id 7so6739874ywo.9 for ; Wed, 05 Jan 2011 22:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=s7lXXUxPCO07w+yubaxprLsSgPcmbG+FPOQ4+YF5Upo=; b=yxEfOS7V9W8aPO+ih5oZv2E6LWZGDLK3w30VbD1Xx0vnEZ8ljfY8Qt+bF+wn6JFhy6 oKxX13v3k1fbuIB4bB8w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QTPFRhkjNzHd6EP0B/XwYR/hg3qzXy7SUro9TMEgBJtNXyHXbNC/K95zy48WazsRX3 8KyabNEJ8j/lUY3GKm2Q== MIME-Version: 1.0 Received: by 10.150.58.4 with SMTP id g4mr23167916yba.291.1294294005000; Wed, 05 Jan 2011 22:06:45 -0800 (PST) Received: by 10.151.26.9 with HTTP; Wed, 5 Jan 2011 22:06:44 -0800 (PST) In-Reply-To: <20110106035400.A82562A12A26@lawyers.icir.org> References: <20110106035400.A82562A12A26@lawyers.icir.org> Date: Wed, 5 Jan 2011 22:06:44 -0800 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: multipart/alternative; boundary=000e0cd30b2c6729d60499274e4f X-System-Of-Record: true Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 06:04:42 -0000 --000e0cd30b2c6729d60499274e4f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 5, 2011 at 7:54 PM, Mark Allman wrote: > > > 1. The long check period (e.g., one month) is necessary to allow > > enough samples to avoid false negative/postives and ensure > > stability/convergence. But many hosts today won't survive that long > > period without a reboot, hence losing all the IW/counter statistics > > and have to start over again. This includes not only most of the > > client devices but many servers as well. > > > > What this implies is basically the algorithm will never (or rarely) > > have enough time to move IW, either up or down. Even it did, upon the > > next reboot the latest IW is lost. Does it start from scatch then? > > This seems like an excessively minor point to me. Stuffing a few > counters and a config setting into non-volatile storage every so often > is pretty trivial. E.g., think about doing it twice a day or something > so at most you lose 12 hours of state. > I think you've missed my main point (really #2 if you read on), which is not about stuffing a few counters in some persistent storage (only needed before system shutdown), but about whether the local storage is even available and usable for this purpose. This requirement will likely rule out many client devices, which is a shame IMO. > Basically, if a host doesn't want to take the bother to try to track > this information over time then they can deal with the implications of > not using a larger initial cwnd because they are not tracking things > well enough to ensure they are doing so safely. > > I just can't see this as some sort of big issue ... > > > For a web server the size distribution of the HTTP responses drops > > off quickly after certain threshold. Assuming we decide our loss > > tolerant level is 5%. When the IW is bumped to certain leve, e.g., > > 20, there may be less than 5% of HTTP responses that are greater > > than 20*1460 = 30KB. Assuming IW <= 20 is all good but IW > 20 is > > all badness, lumping all the counters together under a single IW > > may never fail the 95% check, hence allowing IW to grow unbounded > > even though those connections with response sizes greater than 16 > > always suffer. One may argue the small percentage of connections > > sort of justifying fudging it out. But if one judges from the > > volume (of just the initial bursts) it may not be insignificant. > > Right... this proposal turns on having a tolerance for "badness". If we > want to meaningfully increase IW then there will be badness. The > adaptive scheme sets up a way to manage that badness. Can we construct > scenarios that are still bad? Sure. But, that is always the case. > E.g., IW=10 might be a fine general value, but it might always hurt > performance to some given host. I understand the proposal strives to achieve two goals, 1) to prevent an overly aggressive IW from causing too much badness (subject to some agreed-upon tolerance) on a very large (e.g., global) scale, 2) to find an automated way to grow IW for the foreseeable future (e.g., over the next decade) and I'm being very realistic about it, i.e., not clinging to edge cases. But I just haven't convinced myself the likelihood that the proposed algorithm actually works (i.e., achieving the two goals above) is high. What if the scenarios I (and perhaps Nandita too) described turn out not to be the edge but the norm? The algorithm will either not catch enough badness until IW grows too large to cause real damage, or generate too much false positive to prevent IW from ever growing. Neither is the outcome we want to see. Jerry > allman > > > > --000e0cd30b2c6729d60499274e4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 5, 2011 at 7:54 PM, Mark Allman <mallman@icir.org> wrote:

> 1. The long check period (e.g., one month) is necessary to allow
> enough samples to avoid false negative/postives and ensure
> stability/convergence. But many hosts today won't survive that lon= g
> period without a reboot, hence losing all the IW/counter statistics > and have to start over again. This includes not only most of the
> client devices but many servers as well.
>
> What this implies is basically the algorithm will never (or rarely) > have enough time to move IW, either up or down. Even it did, upon the<= br> > next reboot the latest IW is lost. Does it start from scatch then?

This seems like an excessively minor point to me. =A0Stuffing a few counters and a config setting into non-volatile storage every so often
is pretty trivial. =A0E.g., think about doing it twice a day or something so at most you lose 12 hours of state.

= I think you've missed my main point (really #2 if you read on), which i= s not
about=A0stuffing a=A0few=A0counters in some persistent stor= age (only needed before
system shutdown),=A0but about whether the local storage is even=A0avai= lable=A0and
usable for this=A0purpose.

T= his requirement will likely rule out many client devices, which is a shame<= /div>
IMO.
=A0
Basically, if a host doesn't want to take the bother to try to track this information over time then they can deal with the implications of
not using a larger initial cwnd because they are not tracking things
well enough to ensure they are doing so safely.

I just can't see this as some sort of big issue ...

> For a web server the size distribution of the HTTP responses drops
> off quickly after certain threshold. Assuming we decide our loss
> tolerant level is 5%. When the IW is bumped to certain leve, e.g.,
> 20, there may be less than 5% of HTTP responses that are greater
> than 20*1460 =3D 30KB. Assuming IW <=3D 20 is all good but IW > = 20 is
> all badness, lumping all the counters together under a single IW
> may never fail the 95% check, hence allowing IW to grow unbounded
> even though those connections with response sizes greater than 16
> always suffer. One may argue the small percentage of connections
> sort of justifying fudging it out. But if one judges from the
> volume (of just the initial bursts) it may not be insignificant.

Right... this proposal turns on having a tolerance for "badness&= quot;. =A0If we
want to meaningfully increase IW then there will be badness. =A0The
adaptive scheme sets up a way to manage that badness. =A0Can we construct scenarios that are still bad? =A0Sure. =A0But, that is always the case.
E.g., IW=3D10 might be a fine general value, but it might always hurt
performance to some given host.=A0

I unders= tand the proposal strives to achieve two goals,
1) to prevent an= =A0overly aggressive IW from causing too much badness
(subject to= some=A0agreed-upon tolerance) on a very large=A0(e.g., global) scale,
2) to find an automated way to grow IW for the foreseeable future (e.g= ., over
the next decade)

and I'm bei= ng very realistic about it, i.e., not clinging to edge cases.
But I just haven't convinced myself the likelihood that the proposed al= gorithm
actually works (i.e., achieving the two goals above) is h= igh. What if the
scenarios I (and perhaps Nandita too)=A0describe= d turn out not to be the edge
but the norm? The algorithm will=A0either not catch enough badness unt= il IW
grows=A0too large to cause real damage,=A0or generate too m= uch false=A0positive to
prevent=A0IW from ever growing. Neither i= s the outcome we want to see.

Jerry


allman




--000e0cd30b2c6729d60499274e4f-- From nanditad@google.com Thu Jan 6 00:07:06 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B873A6B73 for ; Thu, 6 Jan 2011 00:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.726 X-Spam-Level: X-Spam-Status: No, score=-103.726 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbfXPz3TtWys for ; Thu, 6 Jan 2011 00:07:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AD9423A6B45 for ; Thu, 6 Jan 2011 00:07:04 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p0689A4t015383 for ; Thu, 6 Jan 2011 00:09:11 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294301351; bh=+StFP0/5sNzW1JmhK/5XtmXdTrA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=OLkncD8B+i/fm61OntyELzSOv6+EDjcjBdX37QDWenCl1L+krY62Z5UYFltSxDHd6 mQ13Z7dLo4EEhT5ZTHUYw== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by hpaq12.eem.corp.google.com with ESMTP id p0688g4F030624 for ; Thu, 6 Jan 2011 00:09:09 -0800 Received: by gyg13 with SMTP id 13so8029138gyg.2 for ; Thu, 06 Jan 2011 00:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QqKaUzLsuN/oXUtKoqAPLOM9Uzcgs2PdJ0IIxZ1qxOo=; b=cfDgENsNcx3hsneDYfjZcn6TRTuRMxPO/VQ4aVLxXXmJE1e3gm9w5n/2ix6c57mWkF gU/Ki/BcHvFTAWtRAJcA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DOljs2tg96eku3OB/5sA4gNeYBMuQ9pCCuKf3ZDqOz0xlN+qmtR9+5cZVz+OVuEDpd 57QlcHBbKs0VqWKtIM8A== MIME-Version: 1.0 Received: by 10.91.11.3 with SMTP id o3mr1632564agi.15.1294301348935; Thu, 06 Jan 2011 00:09:08 -0800 (PST) Received: by 10.91.220.20 with HTTP; Thu, 6 Jan 2011 00:09:08 -0800 (PST) In-Reply-To: <20110106035408.1C3E12A12A49@lawyers.icir.org> References: <20110106035408.1C3E12A12A49@lawyers.icir.org> Date: Thu, 6 Jan 2011 00:09:08 -0800 Message-ID: From: Nandita Dukkipati To: mallman@icir.org Content-Type: multipart/alternative; boundary=001636283e7822b92a049929040e X-System-Of-Record: true Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 08:07:06 -0000 --001636283e7822b92a049929040e Content-Type: text/plain; charset=ISO-8859-1 > One of the algorithm goals is to adapt to the network feedback (on IW > > impact) over long timescales. A lot of things change over periods such > > as a month -- network configurations, topologies, routing, server > > software, applications, traffic patterns and so on. If the net change > > due to all the non-IW reasons is larger than or in the same order as > > the measurable change due to IW, then what does it mean to measure the > > impact of IW? > > I don't follow this at all. The IW is never the problem. The > characteristics of the path are the problem. So, yeah, the path changes > and the traffic mix changes and configs change and so the dynamics > change. We are just trying to find a reasonable---not optimal---initial > setting for the context the host is operating in. We are not trying to > somehow tease apart root causes here, but rather just trying to arrive > at a roughly OK initial setting for the vast majority of the cases. > I believe we all agree that the goal is to find a reasonable (not necessarily optimal) value. The algorithm measures %connections with losses between epochs T1 and T2, and decides to adjust IW based on this feedback; my point is the measured feedback could be an artifact of non-IW related changes over T2-T1, and yet it is used to adjust IW. I understood Steps 3 and 4 of the algo. as if it is measuring the impact of IW change, but looks like that's not entirely the case. It seems like you care about %connections with losses in the context that the host is operating regardless of whether those losses are IW related. Is that correct? > 2) What if losses are bimodal across connections. > > > > A core assumption of the proposal is that increasing IW will increase the > > %connections with losses, which is then used to decide on > > incrementing/decrementing IW. Again, the real experiments show otherwise. > > One of the things we tried hard is to figure out what kinds of > > networks/users we are negatively impacting by increasing losses. While we > > always observed an overall increased retransmission rate, but not really > an > > increase in %connections or %HTTP responses experiencing losses. > > > > But... it may well turn out that (if and when) everyone switches to a > larger > > IW, the above observation is no longer true. However, being a core part > of > > the proposal, I think the assumption needs better (preferably empirical) > > evidence. > > I don't follow this. The proposal is to *use* empirical evidence to > arrive at a reasonable value for an initial parameter setting. > Here's an example from experiments to clarify the question. IW3: 96% connections have 0 losses. 4% connections experience losses. IWN (N>3): 96% connections have 0 losses. 4% connections now experience even further losses. The point being: %connections with losses is one metric, but clearly doesn't tell the whole story on the impact of IW. Why is it OK to just rely on %lossy-connections as a measure of impact? > 3) Convergence to uniform IW. > > > > This is mentioned as one of the goals. With the current specification, my > > sense is this goal will be hard to achieve. Depending on the region of > users > > served, the %connections with losses can be vastly different across the > > globe, naturally lower in States/Western Europe, and higher for regions > like > > Africa/India. Since the threshold (5% or whatever number you choose) is a > > constant, obviously the IW may never get a chance to grow beyond MinIW > for > > certain regions and can grow to MaxIW for others. Do we really need > > convergence to a uniform value?... something to think about. > > I agree that this seemed like a bogus bit in Joe's draft to me. We > don't need to converge to anything but a reasonable value for whatever > context a particular host operates in. > > allman --001636283e7822b92a049929040e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> One of the algorithm goals is to adapt to the network feedb= ack (on IW
> impact) over long timescales. A lot of things change over periods such=
> as a month -- network configurations, topologies, routing, server
> software, applications, traffic patterns and so on. If the net change<= br> > due to all the non-IW reasons is larger than or in the same order as > the measurable change due to IW, then what does it mean to measure the=
> impact of IW?

I don't follow this at all. =A0The IW is never the problem. =A0Th= e
characteristics of the path are the problem. =A0So, yeah, the path changes<= br> and the traffic mix changes and configs change and so the dynamics
change. =A0We are just trying to find a reasonable---not optimal---initial<= br> setting for the context the host is operating in. =A0We are not trying to somehow tease apart root causes here, but rather just trying to arrive
at a roughly OK initial setting for the vast majority of the cases.

I believe we all agree that the goal is to fin= d a reasonable (not necessarily optimal) value. The algorithm measures %con= nections with losses between epochs T1 and T2, and decides to adjust IW bas= ed on this feedback; my point is the measured feedback could be an artifact= of non-IW related changes over T2-T1, and yet it is used to adjust IW.=A0I= understood Steps 3 and 4 of the algo. as if it is measuring the impact of = IW change, but looks like that's not entirely the case. It seems like y= ou care about %connections with losses in the context that the host is oper= ating regardless of whether those losses are IW related. Is that correct?

> 2) What if losses are bimodal across connections. >
> A core assumption of the proposal is that increasing IW will increase = the
> %connections with losses, which is then used to decide on
> incrementing/decrementing IW. Again, the real experiments show otherwi= se.
> One of the things we tried hard is to figure out what kinds of
> networks/users we are negatively impacting by increasing losses. While= we
> always observed an overall increased retransmission rate, but not real= ly an
> increase in %connections or %HTTP responses experiencing losses.
>
> But... it may well turn out that (if and when) everyone switches to a = larger
> IW, the above observation is no longer true. However, being a core par= t of
> the proposal, I think the assumption needs better (preferably empirica= l)
> evidence.

I don't follow this. =A0The proposal is to *use* empirical eviden= ce to
arrive at a reasonable value for an initial parameter setting.

Here's an example from experiments to clarify t= he question.=A0
IW3: 96% connections have 0 losses. 4% connection= s experience losses.
IWN (N>3): 96% connections have 0 losses. 4% connections now experi= ence even further losses.

The point being: %connec= tions with losses is one metric, but clearly doesn't tell the whole sto= ry on the impact of IW. Why is it OK to just rely on %lossy-connections as = a measure of impact?

> 3) Convergence to uniform IW.
>
> This is mentioned as one of the goals. With the current specification,= my
> sense is this goal will be hard to achieve. Depending on the region of= users
> served, the %connections with losses can be vastly different across th= e
> globe, naturally lower in States/Western Europe, and higher for region= s like
> Africa/India. Since the threshold (5% or whatever number you choose) i= s a
> constant, obviously the IW may never get a chance to grow beyond MinIW= for
> certain regions and can grow to MaxIW for others. Do we really need > convergence to a uniform value?... something to think about.

I agree that this seemed like a bogus bit in Joe's draft to me. = =A0We
don't need to converge to anything but a reasonable value for whatever<= br> context a particular host operates in.

allman
--001636283e7822b92a049929040e-- From ilpo.jarvinen@helsinki.fi Thu Jan 6 04:47:07 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82883A6F08 for ; Thu, 6 Jan 2011 04:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8sgLAG84Yzi for ; Thu, 6 Jan 2011 04:47:06 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBE23A6F02 for ; Thu, 6 Jan 2011 04:47:05 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 06 Jan 2011 14:49:11 +0200 id 00093E52.4D25BA47.00006934 Date: Thu, 6 Jan 2011 14:49:11 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Nandita Dukkipati In-Reply-To: Message-ID: References: <20110106035408.1C3E12A12A49@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="8323329-25700443-1294318028=:28590" Content-ID: Cc: Joe Touch , "tcpm@ietf.org" , mallman@icir.org Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 12:47:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-25700443-1294318028=:28590 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 6 Jan 2011, Nandita Dukkipati wrote: > > 2) What if losses are bimodal across connections. > > > > A core assumption of the proposal is that increasing IW will > increase the > > %connections with losses, which is then used to decide on > > incrementing/decrementing IW. Again, the real experiments show > otherwise. > > One of the things we tried hard is to figure out what kinds of > > networks/users we are negatively impacting by increasing > losses. While we > > always observed an overall increased retransmission rate, but > not really an > > increase in %connections or %HTTP responses experiencing > losses. > > > > But... it may well turn out that (if and when) everyone > switches to a larger > > IW, the above observation is no longer true. However, being a > core part of > > the proposal, I think the assumption needs better (preferably > empirical) > > evidence. > > I don't follow this.  The proposal is to *use* empirical evidence to > arrive at a reasonable value for an initial parameter setting. > > > Here's an example from experiments to clarify the question.  > IW3: 96% connections have 0 losses. 4% connections experience losses. > IWN (N>3): 96% connections have 0 losses. 4% connections now experience even > further losses. > > The point being: %connections with losses is one metric, but clearly doesn't > tell the whole story on the impact of IW. Why is it OK to just rely on > %lossy-connections as a measure of impact? It is not supposed to. Per destination problems and problems that affect all destinations are separate problems. And this proposal is not to address the first one. Yet, I'm again puzzled, you came to IETF to tell that larger IW does no harm, or at worst, hurts only oneself (more losses yes, but where's the harm?). Why would it now suddently turn out to be something that should be avoided in a way that hurts performance of those 96%? -- i. --8323329-25700443-1294318028=:28590-- From mallman@icir.org Thu Jan 6 06:12:02 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5773A6F26 for ; Thu, 6 Jan 2011 06:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.062 X-Spam-Level: X-Spam-Status: No, score=-106.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pYKUj5p0RG7 for ; Thu, 6 Jan 2011 06:12:02 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id ECB7E3A6F45 for ; Thu, 6 Jan 2011 06:11:37 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p06EDfR4028148; Thu, 6 Jan 2011 06:13:42 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9C84A2A17054; Thu, 6 Jan 2011 09:13:41 -0500 (EST) To: Nandita Dukkipati From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Rock and Roll MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma52757-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Jan 2011 09:13:41 -0500 Sender: mallman@icir.org Message-Id: <20110106141341.9C84A2A17054@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 06 Jan 2011 14:12:03 -0000 ----------ma52757-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I believe we all agree that the goal is to find a reasonable (not > necessarily optimal) value. The algorithm measures %connections with > losses between epochs T1 and T2, and decides to adjust IW based on > this feedback; my point is the measured feedback could be an artifact > of non-IW related changes over T2-T1, and yet it is used to adjust > IW. I understood Steps 3 and 4 of the algo. as if it is measuring the > impact of IW change, but looks like that's not entirely the case. It > seems like you care about %connections with losses in the context that > the host is operating regardless of whether those losses are IW > related. Is that correct? I didn't write Joe's document. To me you measure whether loss happened in the IW and that determines whether it "works" or "doesn't work" for that connection. I.e., your T2-T1 is the initial window. I am not entirely sure what you mean by "non-IW related changes". There is no need to understand what caused the loss. If it happens enough at IW=X then we decide that IW is too aggressive. > The point being: %connections with losses is one metric, but clearly > doesn't tell the whole story on the impact of IW. Why is it OK to just > rely on %lossy-connections as a measure of impact? Not, it isn't % lossy connections. At least in my thinking it is % with loss in the IW. But, that aside. If you are noting that there is a difference between losing one packet in the initial window and losing IW-1 packets then I might buy that. Propose a different assessment criteria if you have one in mind. E.g., is overall loss rate in the IW better? I.e., retransmits from IW / packets sent in IW (across zillions of connections) must be within some threshold? Or, something? If you see some better way to do this, please clue us in. To me there is simplicity in the binary "loss in IW or not?" notion and since the goal I have in mind is to find something reasonable it seems this other stuff is second order. But, I'd be open to thinking about other proposals. allman ----------ma52757-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0lzhUACgkQWyrrWs4yIs653ACfXr7NSvjzjMZnFXDOjbstITXV fGgAnjmPGK18Fo+x8PnYXePQ7m2cIrkr =eC26 -----END PGP SIGNATURE----- ----------ma52757-1-- From mallman@icir.org Thu Jan 6 06:30:53 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876EF3A6E28 for ; Thu, 6 Jan 2011 06:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.06 X-Spam-Level: X-Spam-Status: No, score=-106.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFq0CL4lTKs8 for ; Thu, 6 Jan 2011 06:30:52 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 383173A6D3C for ; Thu, 6 Jan 2011 06:30:52 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p06EWuTJ029596; Thu, 6 Jan 2011 06:32:57 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 51F972A175FA; Thu, 6 Jan 2011 09:32:56 -0500 (EST) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Rock and Roll MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53908-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Jan 2011 09:32:55 -0500 Sender: mallman@icir.org Message-Id: <20110106143256.51F972A175FA@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 06 Jan 2011 14:30:53 -0000 ----------ma53908-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Jerry- > I think you've missed my main point (really #2 if you read on), which > is not about stuffing a few counters in some persistent storage (only > needed before system shutdown), but about whether the local storage is > even available and usable for this purpose. > > This requirement will likely rule out many client devices, which is a > shame IMO. Maybe my mental model is busted but I am struggling with the notion that there are "many" (what is that?) "client devices" (what are these?) that both have no non-volatile storage and would benefit greatly from larger IWs. It does not seem onerous to me to use a design principle that says to be more aggressive you have to track the implications of that aggressiveness and reduce it if they are too great. If you have a situation whereby a host cannot track the implications because it has no non-volatile storage and it doesn't stay up long enough to get a reasonable sample then that host should not be aggressive. > I understand the proposal strives to achieve two goals, > 1) to prevent an overly aggressive IW from causing too much badness > (subject to some agreed-upon tolerance) on a very large (e.g., global) > scale, > 2) to find an automated way to grow IW for the foreseeable future (e.g., > over the next decade) > > and I'm being very realistic about it, i.e., not clinging to edge > cases. But I just haven't convinced myself the likelihood that the > proposed algorithm actually works (i.e., achieving the two goals > above) is high. What if the scenarios I (and perhaps Nandita too) > described turn out not to be the edge but the norm? The algorithm will > either not catch enough badness until IW grows too large to cause real > damage, or generate too much false positive to prevent IW from ever > growing. Neither is the outcome we want to see. I just disagree. First, if we make only modest increases in the IW at fairly gross intervals (e.g., bump by 1 packet at most once / month) then it seems to me the probability of "causing real damage" is quite low. Certainly lower than increasing a static value from 3 to 10, say. Second, I don't buy the notion of a "false positive". If you have a case where 50% of the connections use IW=X and work fine and 50% of the connections that use IW=X see loss then that is not a reasonable default IW to use. Even if the 50% that don't work all go to one host across some ratty link. You can say that is holding down the growth unnecessarily if you want, but my view is that is the wrong way to look at it. You can call that a "false positive", but there is nothing false about it. It is an empirical observation about half the traffic. The right way to look at it is as a *default* IW X is causing issues for half your traffic and so it is not a good default. If you want to be more savvy and segregate this traffic because it is holding down the global default for everyone else then that seems fine to me. I.e., use IW=3 for this ratty host and run everything else through the adaptive procedure. You can always go get more savvy about caching information. But, I disagree that such a ratty link holding down the *default* IW is somehow wrong. It might be suboptimal. It might be conservative. But, its probably reasonable. We're not shooting for optimality. And, even if we were we'd never get it. allman ----------ma53908-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0l0pYACgkQWyrrWs4yIs6u9ACfdR3eZAngYq6L4qzFRNfiorXp iEIAoIlQgijZhi+lLW+dq9U7gTxSREgK =LBOn -----END PGP SIGNATURE----- ----------ma53908-1-- From mallman@icir.org Thu Jan 6 10:17:42 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8922B3A6F37 for ; Thu, 6 Jan 2011 10:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.359 X-Spam-Level: X-Spam-Status: No, score=-106.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R163w9D+qACT for ; Thu, 6 Jan 2011 10:17:41 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 76F863A6F2F for ; Thu, 6 Jan 2011 10:17:40 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p06IJllD025508 for ; Thu, 6 Jan 2011 10:19:47 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F0ECD2A38D2A for ; Thu, 6 Jan 2011 13:19:46 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Rock and Roll MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1984-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Jan 2011 13:19:46 -0500 Sender: mallman@icir.org Message-Id: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Subject: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 06 Jan 2011 18:17:42 -0000 ----------ma1984-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Given that there are three proposals put down in I-D form in some matter of baked-ness I am wondering if there is any sort of clear WG preference on the *approach* to changing the initial window. So, putting aside the particulars for a moment and just thinking about the approach I'd like to take a quick, informal, absolutely non-binding in any way (obviously) poll to take the WG's pulse. So, do you prefer ... (A) To increase the current static IW definition to a single updated value. (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am explicitly not asking about IW=10, just IW=some_X.) (B) To increase the current static IW definition with a schedule of IW updates to play out over some period of time. (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am explicitly not asking if you like the given schedule.) (C) To define a procedure for hosts to figure out how to adapt their IW over time. (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am explicitly not asking if you buy the particulars of this, just the overall approach.) (D) The current IW seems OK and I haven't seen a good reason to think it needs changed. Thanks! allman ----------ma1984-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0mB8IACgkQWyrrWs4yIs7spQCfX/KS741FVAQqba2WT6ERU9oi kEcAn2zykXQPfXkyXHHO0H0AVFztckVn =Wl5r -----END PGP SIGNATURE----- ----------ma1984-1-- From wesley.m.eddy@nasa.gov Thu Jan 6 10:36:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF6D3A6F35 for ; Thu, 6 Jan 2011 10:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.331 X-Spam-Level: X-Spam-Status: No, score=-106.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ytsfh+CA4Yyx for ; Thu, 6 Jan 2011 10:36:03 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 9C55F3A6F2E for ; Thu, 6 Jan 2011 10:36:03 -0800 (PST) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 643D4A8630; Thu, 6 Jan 2011 12:38:10 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id p06IcAM1018570; Thu, 6 Jan 2011 12:38:10 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Thu, 6 Jan 2011 12:38:10 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "mallman@icir.org" , "tcpm@ietf.org" Date: Thu, 6 Jan 2011 12:34:50 -0600 Thread-Topic: [tcpm] informal poll about initial cwnd Thread-Index: Acutzl9eTKh3h6umScyXkRJyFLp8bQAAgevS Message-ID: References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> In-Reply-To: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-06_09:2011-01-06, 2011-01-06, 1970-01-01 signatures=0 Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:36:04 -0000 I've been thinking we might wind up with some set of A/B/C in conjunction. = It seems like they don't have to be mutually exclusive since different hos= ts could implement different Experimenal policies, as long as each is felt = to be reasonable for Experimental. Of course, it would probably be better = to have one Proposed Standard. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Mark Allma= n [mallman@icir.org] Sent: Thursday, January 06, 2011 1:19 PM To: tcpm@ietf.org Subject: [tcpm] informal poll about initial cwnd Given that there are three proposals put down in I-D form in some matter of baked-ness I am wondering if there is any sort of clear WG preference on the *approach* to changing the initial window. So, putting aside the particulars for a moment and just thinking about the approach I'd like to take a quick, informal, absolutely non-binding in any way (obviously) poll to take the WG's pulse. So, do you prefer ... (A) To increase the current static IW definition to a single updated value. (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am explicitly not asking about IW=3D10, just IW=3Dsome_X.) (B) To increase the current static IW definition with a schedule of IW updates to play out over some period of time. (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am explicitly not asking if you like the given schedule.) (C) To define a procedure for hosts to figure out how to adapt their IW over time. (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am explicitly not asking if you buy the particulars of this, just the overall approach.) (D) The current IW seems OK and I haven't seen a good reason to think it needs changed. Thanks! allman= From nanditad@google.com Thu Jan 6 10:44:02 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47C33A6EFE for ; Thu, 6 Jan 2011 10:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.826 X-Spam-Level: X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=-4.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK7mEjOyukZT for ; Thu, 6 Jan 2011 10:44:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id C248B3A6CC6 for ; Thu, 6 Jan 2011 10:44:01 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p06Ik7sJ023569 for ; Thu, 6 Jan 2011 10:46:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294339568; bh=Bd8HATORhiJXmthMn2sT7n7rD+A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ob/Y/n0leYP5IVcjwNYcLGejVaE7Mu+T7BvqjBirvUgClp5zY7L/SP0fHKg+Bu2zi QltAWmNwY/0P3KgauQUIw== Received: from yie21 (yie21.prod.google.com [10.243.66.21]) by kpbe16.cbf.corp.google.com with ESMTP id p06Ik6NV031357 for ; Thu, 6 Jan 2011 10:46:06 -0800 Received: by yie21 with SMTP id 21so5227221yie.4 for ; Thu, 06 Jan 2011 10:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=czqHb8KovLjYsKuzVfo8W2yGFldqya0YbdxvCma5ee8=; b=AvxuIhq8cvX9uVm5uD2HlJaUBcuH/AUsIyIA1XIfH9KdExTtkeEaVMAUr0br9YzKn6 jcRdEMirKotYPbSQvitg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eSGYo/5kIOLMKeq+fRsz5s/Hzir7MWtv5Dp6zTkuoxvgJVuAQXipsQnZ0q2/nfxsRR LstO7iHN94Rfw6zgEo1w== MIME-Version: 1.0 Received: by 10.91.11.3 with SMTP id o3mr2301934agi.15.1294339565797; Thu, 06 Jan 2011 10:46:05 -0800 (PST) Received: by 10.91.220.20 with HTTP; Thu, 6 Jan 2011 10:46:05 -0800 (PST) In-Reply-To: References: <20110106035408.1C3E12A12A49@lawyers.icir.org> Date: Thu, 6 Jan 2011 10:46:05 -0800 Message-ID: From: Nandita Dukkipati To: =?ISO-8859-1?Q?Ilpo_J=E4rvinen?= Content-Type: multipart/alternative; boundary=001636283e7809c037049931ead6 X-System-Of-Record: true Cc: Joe Touch , "tcpm@ietf.org" , mallman@icir.org Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:44:03 -0000 --001636283e7809c037049931ead6 Content-Type: text/plain; charset=ISO-8859-1 > The point being: %connections with losses is one metric, but clearly > doesn't > > tell the whole story on the impact of IW. Why is it OK to just rely on > > %lossy-connections as a measure of impact? > > It is not supposed to. Per destination problems and problems that affect > all destinations are separate problems. And this proposal is not to > address the first one. Yet, I'm again puzzled, you came to IETF to > tell that larger IW does no harm, or at worst, hurts only oneself (more > losses yes, but where's the harm?). Why would it now suddently turn out > to be something that should be avoided in a way that hurts > performance of those 96%? > You understand me incorrectly. I am trying to get a sense of how the algorithm will work in practice, and hence these questions. Obviously, a dynamic algorithm that bounds damage (if any) and lays out a growth path for IW is better than a static setting. And I agree with that. --001636283e7809c037049931ead6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> The point being: %connections with losses is one metric, but clearly d= oesn't
> tell the whole story on the impact of IW. Why is it OK to just rely on=
> %lossy-connections as a measure of impact?

It is not supposed to. Per destination problems and problems th= at affect
all destinations are separate problems. And this proposal is not to
address the first one. Yet, I'm again puzzled, you came to IETF to
tell that larger IW does no harm, or at worst, hurts only oneself (more
losses yes, but where's the harm?). Why would it now suddently turn out=
to be something that should be avoided in a way that hurts
performance of those 96%?

You understan= d me incorrectly. I am trying to get a sense of how the algorithm will work= in practice, and hence these questions. Obviously, a dynamic algorithm tha= t bounds damage (if any) and lays out a growth path for IW is better than a= static setting. And I agree with that.
--001636283e7809c037049931ead6-- From michawe@ifi.uio.no Thu Jan 6 10:44:16 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137EE3A6F54 for ; Thu, 6 Jan 2011 10:44:16 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp+4QDxdnMSC for ; Thu, 6 Jan 2011 10:44:15 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 2E0303A6F43 for ; Thu, 6 Jan 2011 10:44:15 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Pauqr-0007O3-33; Thu, 06 Jan 2011 19:46:21 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Pauqq-00076w-NQ; Thu, 06 Jan 2011 19:46:21 +0100 Message-Id: <236913C2-29A3-4A01-B62B-FE5E09496D93@ifi.uio.no> From: Michael Welzl To: mallman@icir.org In-Reply-To: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 6 Jan 2011 19:45:59 +0100 References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 5330 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 31607044E83A8099CE79B9BDFA62B2C56FB424E4 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 368 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:44:16 -0000 That vote is a good idea, I think. I'm for this one: > (C) To define a procedure for hosts to figure out how to adapt their > IW > over time. > > (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am > explicitly not asking if you buy the particulars of this, just the > overall approach.) Cheers, Michael From touch@isi.edu Thu Jan 6 10:47:00 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4583A6F40 for ; Thu, 6 Jan 2011 10:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLgRgX9dxxhS for ; Thu, 6 Jan 2011 10:46:59 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 8A7123A6F3C for ; Thu, 6 Jan 2011 10:46:59 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p06ImhG8027255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 10:48:43 -0800 (PST) Message-ID: <4D260E8B.3030309@isi.edu> Date: Thu, 06 Jan 2011 10:48:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mallman@icir.org References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> In-Reply-To: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> 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] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:47:00 -0000 My preferences, in order: > (D) The current IW seems OK and I haven't seen a good reason to think > it needs changed. > (C) To define a procedure for hosts to figure out how to adapt their > IW over time. More specifically, I'd say C should be: to define a procedure based on feedback that increases the IW only where it measurably doesn't do harm If my draft doesn't do that, someone can write one that does. Joe From hkchu@google.com Thu Jan 6 11:26:39 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E02D3A6E1A for ; Thu, 6 Jan 2011 11:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.942 X-Spam-Level: X-Spam-Status: No, score=-103.942 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q90z1o2Gdq1h for ; Thu, 6 Jan 2011 11:26:38 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A945D3A6CDA for ; Thu, 6 Jan 2011 11:26:37 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p06JShgC011206 for ; Thu, 6 Jan 2011 11:28:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294342123; bh=LA/t4e/aYAbzm1H9WVXHjjN5Vkk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qYdtxxjYfMc0T0mXEc8QdoL4bRQPrjM9bNb/LaDl/o+mzT76MHWk0Kbh3sw9ozD6/ CfjFbVpP+BIeMVNKcC0/Q== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by hpaq11.eem.corp.google.com with ESMTP id p06JSfJ0002158 for ; Thu, 6 Jan 2011 11:28:41 -0800 Received: by yxm8 with SMTP id 8so7045930yxm.21 for ; Thu, 06 Jan 2011 11:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KB42pFa8RWtDhi3dAOIIMZ0K7FQ2P8819xnK1IXDZys=; b=w05ObWkLzH3Bjxmqcs1uwCgF+Lo1s2KUFBAMf1z4rsOtu6uptP4/dxOUmZtBLxwVle P45l2KV2CVs3RSeP7bLg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PlXqoG3eyB4TImjL3HTw3tfgd0l7PpACUAGgW8kj87ecp5Q5cjE8aYF1A0EAMGBnbD oX/r9ULtW++vazkObZfw== MIME-Version: 1.0 Received: by 10.150.147.8 with SMTP id u8mr24150369ybd.234.1294342120946; Thu, 06 Jan 2011 11:28:40 -0800 (PST) Received: by 10.151.26.9 with HTTP; Thu, 6 Jan 2011 11:28:40 -0800 (PST) In-Reply-To: <20110106143256.51F972A175FA@lawyers.icir.org> References: <20110106143256.51F972A175FA@lawyers.icir.org> Date: Thu, 6 Jan 2011 11:28:40 -0800 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: multipart/alternative; boundary=000e0cd51a4a563e210499328277 X-System-Of-Record: true Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:26:41 -0000 --000e0cd51a4a563e210499328277 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 6:32 AM, Mark Allman wrote: > > Jerry- > > > I think you've missed my main point (really #2 if you read on), which > > is not about stuffing a few counters in some persistent storage (only > > needed before system shutdown), but about whether the local storage is > > even available and usable for this purpose. > > > > This requirement will likely rule out many client devices, which is a > > shame IMO. > > Maybe my mental model is busted but I am struggling with the notion that > there are "many" (what is that?) "client devices" (what are these?) that > both have no non-volatile storage and would benefit greatly from larger > IWs. > Joe's proposal aims at solving the IW growth problem for the next decade (or two). Can anyone predict what the future devices and traffic pattern will look like? It's also better to have less external dependencies. > It does not seem onerous to me to use a design principle that says to be > more aggressive you have to track the implications of that > aggressiveness and reduce it if they are too great. > > If you have a situation whereby a host cannot track the implications > because it has no non-volatile storage and it doesn't stay up long > enough to get a reasonable sample then that host should not be > aggressive. > So do they get stuck at the bottom (i.e., IW3) forever? IW10 would be a much preferred value to get stuck with. Otherwise I'd prefer to give them a path to grow, e.g., by figuring out a way to monitor the usage of IW and its effect (if feasible), and periodically publish progress reports giving green light to some IW. BTW, the proposal is not clear on hosts that never last longer than the check period due to system shutdown and inability to save counters. They don't get to grow nor shrink the IW. But what's the IW to use to begin with (MaxIW or MinIW??) > > I understand the proposal strives to achieve two goals, > > 1) to prevent an overly aggressive IW from causing too much badness > > (subject to some agreed-upon tolerance) on a very large (e.g., global) > > scale, > > 2) to find an automated way to grow IW for the foreseeable future (e.g., > > over the next decade) > > > > and I'm being very realistic about it, i.e., not clinging to edge > > cases. But I just haven't convinced myself the likelihood that the > > proposed algorithm actually works (i.e., achieving the two goals > > above) is high. What if the scenarios I (and perhaps Nandita too) > > described turn out not to be the edge but the norm? The algorithm will > > either not catch enough badness until IW grows too large to cause real > > damage, or generate too much false positive to prevent IW from ever > > growing. Neither is the outcome we want to see. > > I just disagree. > > First, if we make only modest increases in the IW at fairly gross > intervals (e.g., bump by 1 packet at most once / month) then it seems to > me the probability of "causing real damage" is quite low. Certainly > lower than increasing a static value from 3 to 10, say. > There is a MaxIW based on year so it'd take years for IW to grow. But my point was if the algorithm just fails to catch badness, although it may take a long time to grow IW but it will get there at some point to cause damage. Second, I don't buy the notion of a "false positive". If you have a > case where 50% of the connections use IW=X and work fine and 50% of the > connections that use IW=X see loss then that is not a reasonable default > IW to use. Even if the 50% that don't work all go to one host across > some ratty link. You can say that is holding down the growth > unnecessarily if you want, but my view is that is the wrong way to look > at it. You can call that a "false positive", but there is nothing false > about it. It is an empirical observation about half the traffic. The > right way to look at it is as a *default* IW X is causing issues for > half your traffic and so it is not a good default. If you want to be > more savvy and segregate this traffic because it is holding down the > global default for everyone else then that seems fine to me. I.e., use > IW=3 for this ratty host and run everything else through the adaptive > procedure. You can always go get more savvy about caching information. > > But, I disagree that such a ratty link holding down the *default* IW is > somehow wrong. It might be suboptimal. It might be conservative. But, > its probably reasonable. We're not shooting for optimality. And, even > if we were we'd never get it. > Like I said repeatedly this is not about some minor optimization. It'd be silly and futile to try to seek optimization in the grand scheme of things. My concern is that some seemingly edge cases might turn out not to be so as described in my bullet 4 previously (cut&paste) below. The threshold of 50% you used above is unreal and trivialized the case. A realistic threshold might be between 5-10%. Again picking a good threshold is another difficult task. Too loose, you aren't catching any badness. Too tight, you shutdown IW growth completely. Is it even possible to have a single, threshold that is "good enough" (no, I'm not shooting for optimality) for global use? (quote from previous comments) "4. The proposal makes an assumption that the choice of IW is to be blamed if the percentage of connection experiencing pkt loss during its IW is greater than some threshold. But this may not be true. A host may experience high loss percentage regardless of IW. E.g., IW3 performs as bad as IW10. If the losses are spread across a large percentage of connections, then one can argue it's moot whether an optimal IW is picked because performance will suck for most connections anyway (assuming a high loss threshold of, e.g., 5%). But if the losses concentrate on only 5% of remote peers and these peers suffer real high pkt loss rate, this false positive will forbid IW to ever grow, and hence deprives the rest 95% connections of the benefit of a larger IW. I have no idea how often this false positive case might exist but if it turns out to be a large percentage then the proposal will be worthless in terms of addressing the small IW problem." Jerry > allman > > > > --000e0cd51a4a563e210499328277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 6:32 AM, Mark Allman <mallman@icir.org> wrote:

Jerry-

> I think you've missed my main point (really #2 if you read on), wh= ich
> is not about stuffing a few counters in some persistent storage (only<= br> > needed before system shutdown), but about whether the local storage is=
> even available and usable for this purpose.
>
> This requirement will likely rule out many client devices, which is a<= br> > shame IMO.

Maybe my mental model is busted but I am struggling with the notion t= hat
there are "many" (what is that?) "client devices" (what= are these?) that
both have no non-volatile storage and would benefit greatly from larger
IWs.

Joe's proposal aims at solving= the IW growth problem for the next decade (or two).
Can anyone p= redict what the future devices and traffic pattern will look like?
It's also better to have less external dependencies.

It does not seem onerous to me to use a design principle that says to be more aggressive you have to track the implications of that
aggressiveness and reduce it if they are too great.

If you have a situation whereby a host cannot track the implications
because it has no non-volatile storage and it doesn't stay up long
enough to get a reasonable sample then that host should not be
aggressive.

So do they get stuck at the= bottom (i.e., IW3) forever? IW10 would be a much
preferred value= to get stuck with. Otherwise=A0I'd prefer to give them a path to
grow, e.g., by figuring out a way to=A0monitor=A0the usage of IW and i= ts effect (if
feasible), and periodically publish progress report= s giving=A0green light to some IW.

BTW, the propos= al is not clear on hosts that never last longer than the check
period=A0due to system shutdown and inability to save counters. They d= on't get
to grow nor=A0shrink the IW. But what's the IW t= o use to begin with (MaxIW or
MinIW??)


> I understand the proposal strives to achieve two goals,
> 1) to prevent an overly aggressive IW from causing too much badness > (subject to some agreed-upon tolerance) on a very large (e.g., global)=
> scale,
> 2) to find an automated way to grow IW for the foreseeable future (e.g= .,
> over the next decade)
>
> and I'm being very realistic about it, i.e., not clinging to edge<= br> > cases. =A0But I just haven't convinced myself the likelihood that = the
> proposed algorithm actually works (i.e., achieving the two goals
> above) is high. What if the scenarios I (and perhaps Nandita too)
> described turn out not to be the edge but the norm? The algorithm will=
> either not catch enough badness until IW grows too large to cause real=
> damage, or generate too much false positive to prevent IW from ever > growing. Neither is the outcome we want to see.

I just disagree.

First, if we make only modest increases in the IW at fairly gross
intervals (e.g., bump by 1 packet at most once / month) then it seems to me the probability of "causing real damage" is quite low. =A0Cert= ainly
lower than increasing a static value from 3 to 10, say.

There is a MaxIW based on year so it'd take years for = IW to grow. But my
point was if the algorithm just fails to catch= badness, although it may take
a long time to grow IW but it will get there at some point to cause da= mage.

Second, I don'= ;t buy the notion of a "false positive". =A0If you have a
case where 50% of the connections use IW=3DX and work fine and 50% of the connections that use IW=3DX see loss then that is not a reasonable default<= br> IW to use. =A0Even if the 50% that don't work all go to one host across=
some ratty link. =A0You can say that is holding down the growth
unnecessarily if you want, but my view is that is the wrong way to look
at it. =A0You can call that a "false positive", but there is noth= ing false
about it. =A0It is an empirical observation about half the traffic. =A0The<= br> right way to look at it is as a *default* IW X is causing issues for
half your traffic and so it is not a good default. =A0If you want to be
more savvy and segregate this traffic because it is holding down the
global default for everyone else then that seems fine to me. =A0I.e., use IW=3D3 for this ratty host and run everything else through the adaptive
procedure. =A0You can always go get more savvy about caching information.
But, I disagree that such a ratty link holding down the *default* IW is
somehow wrong. =A0It might be suboptimal. =A0It might be conservative. =A0B= ut,
its probably reasonable. =A0We're not shooting for optimality. =A0And, = even
if we were we'd never get it.

Like = I said repeatedly this is not about some minor optimization. It'd be si= lly
and futile to try to seek optimization in the grand scheme of= things. My concern
is that some=A0seemingly edge cases might turn out not to be so as des= cribed in
my bullet 4=A0previously (cut&paste) below. The thr= eshold of 50% you used above
is unreal=A0and trivialized the case= . A realistic threshold might be between 5-10%.
Again=A0picking a good threshold is another difficult task. Too loose,= you aren't
catching=A0any badness. Too tight, you shutdown I= W growth completely. Is it even
possible=A0to have a single, thre= shold that is "good enough" (no, I'm not shooting
for optimality)=A0for global use?

(quote from= previous comments)
"4. The proposal makes an assumption tha= t the choice of IW is to
be blamed if the percentage of connectio= n experiencing pkt loss
during its IW is greater than some threshold. But this may not be
true. A host may experience high loss percentage regardless of IW.
E.g., IW3 performs as bad as IW10.

If the = losses are spread across a large percentage of connections,
then one can argue it's moot whether an optimal IW is picked becau= se
performance will suck for most connections anyway (assuming a = high
loss threshold of, e.g., 5%). But if the losses concentrate = on only
5% of remote peers and these peers suffer real high pkt loss rate,
this false positive will forbid IW to ever grow, and hence deprives<= /div>
the rest 95% connections of the benefit of a larger IW.

I have no idea how often this false positive case might= exist but
if it turns out to be a large percentage then the prop= osal will be
worthless in terms of addressing the small IW proble= m."

Jerry


allman




--000e0cd51a4a563e210499328277-- From mallman@icir.org Thu Jan 6 12:19:40 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106163A6F35 for ; Thu, 6 Jan 2011 12:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.365 X-Spam-Level: X-Spam-Status: No, score=-106.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo83u5rdI+CJ for ; Thu, 6 Jan 2011 12:19:39 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E51613A6F31 for ; Thu, 6 Jan 2011 12:19:38 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p06KLhEK009560; Thu, 6 Jan 2011 12:21:43 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 10F552A3BA4B; Thu, 6 Jan 2011 15:21:43 -0500 (EST) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Rock and Roll MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma9302-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Jan 2011 15:21:43 -0500 Sender: mallman@icir.org Message-Id: <20110106202143.10F552A3BA4B@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Automatic IW draft posted X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 06 Jan 2011 20:19:40 -0000 ----------ma9302-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > First, if we make only modest increases in the IW at fairly gross > > intervals (e.g., bump by 1 packet at most once / month) then it seems to > > me the probability of "causing real damage" is quite low. Certainly > > lower than increasing a static value from 3 to 10, say. > > There is a MaxIW based on year so it'd take years for IW to grow. But > my point was if the algorithm just fails to catch badness, although it > may take a long time to grow IW but it will get there at some point to > cause damage. Sure... the algorithm has one definition of badness (loss in the initial cwnd). If you have a better definition of badness please lay it on us. And, yes, ultimately we are making an engineering judgment that says the progression of the IW is conservative enough that we do not believe it will cause big issues. Is that true? I don't know. But, (a) I think the progress is pretty conservative and so the magnitude of any damage is likely to be modest at worst and (b) there is a built-in way to observe the issues and back the IW off. This is, IMO, very similar to making an engineering judgment of some static IW (like IW=10). What we have is a collection of anecdotes that say (to some of us) its likely OK. Do we know it will be OK when everyone uses it? Do we know it won't be Quite Bad for various pieces of the network? Do we know it won't "cause damage"? We don't. > A realistic threshold might be between 5-10%. Again picking a good > threshold is another difficult task. Too loose, you aren't catching > any badness. Too tight, you shutdown IW growth completely. Is it even > possible to have a single, threshold that is "good enough" (no, I'm > not shooting for optimality) for global use? Well, I don't expect to agree here, but I think anything is 5--10% is fine. I also don't care if the arrived at IW is 7 or 9 or 11. This is an initial parameter. We should strive to simply have it set somewhere within the right ballpark. The adaptive scheme, I believe, flips the decision from something we don't care about (the initial cwnd value) to something we do care about (the implications of TCP's initial settings). The arguments about IW=10, say, have not been "well, that's not a power of 2 and so I hate it" or "I love it because my birthday is the 10th" or whatever. Rather, the discussion has focused on how that IW impacts the traffic and the network. Nobody cares about the number. So, let's just directly focus on something we care about. If our tolerance is X% then what we're saying is that we want to get the best possible performance with the constraint that <= X% of the connections should experience loss within the initial cwnd. That statement says nothing about how we want to evolve the IW parameter. That statement is an objective statement of a property of our traffic. That will drive an IW choice. But, the IW choice is implementing the policy statement and therefore whether it grows or shrinks or whatever is immaterial. Rather, what we care about is the policy statement. I think we're still getting too hung up on "what will the IW be?". And, if you want to be smarter about things and happen to notice its one host (say) causing much of the loss in the initial window and want to drop the IW for that host and let the IW adapt higher for the remainder then that's fine. In the aggregate you're still <= X%. So, depending on how smart you want to be you don't have to let the tail wag the dog. But, if you don't want the complexity then you may have to live with a less optimal result. But, that's *your* choice as an implementer / operator. allman ----------ma9302-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0mJFYACgkQWyrrWs4yIs61BACfepEsfONoHwDrQUrfni46jgnp Lk8AnA8uOQtATz9mMUKZ/arUIkAgaqZ7 =3zUo -----END PGP SIGNATURE----- ----------ma9302-1-- From hkchu@google.com Thu Jan 6 12:56:31 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2B93A6C9F for ; Thu, 6 Jan 2011 12:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.13 X-Spam-Level: X-Spam-Status: No, score=-104.13 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGjtezPLY48c for ; Thu, 6 Jan 2011 12:56:28 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 62BE93A6A94 for ; Thu, 6 Jan 2011 12:56:28 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p06KwY8t015038 for ; Thu, 6 Jan 2011 12:58:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294347515; bh=VnYp/SqeMdhA/3Xiy5pkTeikxTo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YPHaS1oIV1VmU7058Rem3eqDozey7Ulu6vJgsKp5GYpvFw7Tn0wMygBNkDiv/5H5g 7ZxKsGDK8q0maU8m2ifQg== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by hpaq12.eem.corp.google.com with ESMTP id p06KwLGA004982 for ; Thu, 6 Jan 2011 12:58:32 -0800 Received: by gyd12 with SMTP id 12so7079806gyd.17 for ; Thu, 06 Jan 2011 12:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LUuc/ruc5Qj/S0hB9EbHBFs14O57b8I3IGGDUH+GHF0=; b=jNF9zosM0nCw+33hi/dQtx5vSYwl5OWpuY5yvX2WhAfUynSl7gALHFRqhcBffdsLnR IB51FmLemrh2nuSa5XFA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LFCE7dhsTZbt9TjuoL9U4eI5+0pBM0N81g4VPIkZ3rQzx5tORRYonWmu80QrXg5AN8 v8hPEcDiOdamL4B8T9Tw== MIME-Version: 1.0 Received: by 10.151.158.7 with SMTP id k7mr23607736ybo.405.1294347512187; Thu, 06 Jan 2011 12:58:32 -0800 (PST) Received: by 10.151.26.9 with HTTP; Thu, 6 Jan 2011 12:58:32 -0800 (PST) In-Reply-To: References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Date: Thu, 6 Jan 2011 12:58:32 -0800 Message-ID: From: Jerry Chu To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: multipart/alternative; boundary=0015174ff4faae0d48049933c3ae X-System-Of-Record: true Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 20:56:31 -0000 --0015174ff4faae0d48049933c3ae Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 10:34 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > I've been thinking we might wind up with some set of A/B/C in conjunction. > It seems like they don't have to be mutually exclusive since different > hosts could implement different Experimenal policies, as long as each is > felt to be reasonable for Experimental. Of course, it would probably be > better to have one Proposed Standard. > Agreed 100%. To me it's an obvious choice if C) proves to be feasible, i.e., translating into say, no more than 50 lines of simple code, not inflicting any noticeable performance penalty, without any external dependencies, and actually works as expected (i.e., attaining its goals of allowing a timely growth path for IW without causing significant more global congestions) then who would say no to that magic? But it is still a long IF IMO. (Note I'm not saying I don't believe C) will work. It's just I still have my doubt.) Also it seems to me a combination of A) and B) may serve those hosts that just can't do C) (e.g., either w/o persistent storage or having one but not usable for C)'s purpose). Jerry > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Mark > Allman [mallman@icir.org] > Sent: Thursday, January 06, 2011 1:19 PM > To: tcpm@ietf.org > Subject: [tcpm] informal poll about initial cwnd > > Given that there are three proposals put down in I-D form in some matter > of baked-ness I am wondering if there is any sort of clear WG preference > on the *approach* to changing the initial window. So, putting aside the > particulars for a moment and just thinking about the approach I'd like > to take a quick, informal, absolutely non-binding in any way (obviously) > poll to take the WG's pulse. > > So, do you prefer ... > > (A) To increase the current static IW definition to a single updated > value. > > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > explicitly not asking about IW=10, just IW=some_X.) > > (B) To increase the current static IW definition with a schedule of IW > updates to play out over some period of time. > > (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am > explicitly not asking if you like the given schedule.) > > (C) To define a procedure for hosts to figure out how to adapt their IW > over time. > > (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am > explicitly not asking if you buy the particulars of this, just the > overall approach.) > > (D) The current IW seems OK and I haven't seen a good reason to think it > needs changed. > > Thanks! > > allman > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0015174ff4faae0d48049933c3ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 10:34 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE = CORP] <wesle= y.m.eddy@nasa.gov> wrote:
I've been thinking we might wind up with some set of A/B/C in conjuncti= on. =A0It seems like they don't have to be mutually exclusive since dif= ferent hosts could implement different Experimenal policies, as long as eac= h is felt to be reasonable for Experimental. =A0Of course, it would probabl= y be better to have one Proposed Standard.

Agreed 100%.

To m= e it's an obvious choice if C) proves to be feasible, i.e., translating= into say,
no more than 50 lines of simple code, not inflicting a= ny noticeable performance
penalty,=A0without any external dependencies, and actually works as ex= pected
(i.e., attaining its goals of allowing a timely growth pat= h for IW without causing
significant more global congestions)=A0t= hen who=A0would say no to that magic?

But it is still a long IF IMO. (Note I'm not saying= I don't believe C) will work.
It's just=A0I still have m= y doubt.)

Also it seems to me a combination of A) = and B) may serve those hosts that just
can't=A0do C) (e.g., either w/o=A0persistent storage or having one= but not usable
for C)'s=A0purpose).

Jerry


________________________________________
From: tcpm-bounces@ietf.org [<= a href=3D"mailto:tcpm-bounces@ietf.org">tcpm-bounces@ietf.org] On Behal= f Of Mark Allman [mallman@icir.org]=
Sent: Thursday, January 06, 2011 1:19 PM
To: tcpm@ietf.org
Subject: [tcpm] informal poll about initial cwnd

Given that there are three proposals put down in I-D form in some matter of baked-ness I am wondering if there is any sort of clear WG preference on the *approach* to changing the initial window. =A0So, putting aside the<= br> particulars for a moment and just thinking about the approach I'd like<= br> to take a quick, informal, absolutely non-binding in any way (obviously) poll to take the WG's pulse.

So, do you prefer ...

(A) To increase the current static IW definition to a single updated
=A0 =A0value.

=A0 =A0(Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am
=A0 =A0explicitly not asking about IW=3D10, just IW=3Dsome_X.)

(B) To increase the current static IW definition with a schedule of IW
=A0 =A0updates to play out over some period of time.

=A0 =A0(Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am=
=A0 =A0explicitly not asking if you like the given schedule.)

(C) To define a procedure for hosts to figure out how to adapt their IW
=A0 =A0over time.

=A0 =A0(Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am =A0 =A0explicitly not asking if you buy the particulars of this, just the<= br> =A0 =A0overall approach.)

(D) The current IW seems OK and I haven't seen a good reason to think i= t
=A0 =A0needs changed.

Thanks!

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

--0015174ff4faae0d48049933c3ae-- From johnwheffner@gmail.com Thu Jan 6 13:18:12 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510943A6CAB for ; Thu, 6 Jan 2011 13:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4j8ISW56jXg for ; Thu, 6 Jan 2011 13:18:11 -0800 (PST) Received: from mail-ey0-f194.google.com (mail-ey0-f194.google.com [209.85.215.194]) by core3.amsl.com (Postfix) with ESMTP id 456E63A6CF0 for ; Thu, 6 Jan 2011 13:18:11 -0800 (PST) Received: by eya28 with SMTP id 28so2264205eya.1 for ; Thu, 06 Jan 2011 13:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z3ep+R395IAS7ADK7pFwzPMgj6N6nSHeUeDPJM3k8/s=; b=Hlsfw6loTwppUhuQubvi99shsSgf+tGDMX0Ji/knuz/0pTSzjiG9uprYKKIgwvZRon EGf5pDhcClGZQArU2VHdnPHvLF0xSO5JRvQd5ABFxgGItvRmdnrCm1ZUM0+I/St0Kbpp pIeIAtjKHYOU+fegvzqS83etxa35rb3H64d+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QNazzs1g3i6inw1KbLuSjYkbWZmhIF64FoPJxAMDoCzLEE6RhoPtePyX9Y6YoL9wEy HsF6Mjj3tZtO7ehtat/b1noVjYZXVp0+/gGknvegrIKTm9vksTiQHPQyfcyDHi6tB2W1 W/o2P5C89RKPbVVyKhZLgXCG7bd9sQu+ghjT4= MIME-Version: 1.0 Received: by 10.213.22.142 with SMTP id n14mr18283032ebb.57.1294348816331; Thu, 06 Jan 2011 13:20:16 -0800 (PST) Received: by 10.213.17.147 with HTTP; Thu, 6 Jan 2011 13:20:16 -0800 (PST) In-Reply-To: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Date: Thu, 6 Jan 2011 16:20:16 -0500 Message-ID: From: John Heffner To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:18:12 -0000 As a firm believer in simplicity where possible, I have strong reservations on (C). If approach (D) is chosen, implementors will very soon start making their own choices for non-standard IW. It's not clear to me this is a bad thing, but it could be. -John On Thu, Jan 6, 2011 at 1:19 PM, Mark Allman wrote: > > Given that there are three proposals put down in I-D form in some matter > of baked-ness I am wondering if there is any sort of clear WG preference > on the *approach* to changing the initial window. =A0So, putting aside th= e > particulars for a moment and just thinking about the approach I'd like > to take a quick, informal, absolutely non-binding in any way (obviously) > poll to take the WG's pulse. > > So, do you prefer ... > > (A) To increase the current static IW definition to a single updated > =A0 =A0value. > > =A0 =A0(Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > =A0 =A0explicitly not asking about IW=3D10, just IW=3Dsome_X.) > > (B) To increase the current static IW definition with a schedule of IW > =A0 =A0updates to play out over some period of time. > > =A0 =A0(Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I a= m > =A0 =A0explicitly not asking if you like the given schedule.) > > (C) To define a procedure for hosts to figure out how to adapt their IW > =A0 =A0over time. > > =A0 =A0(Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am > =A0 =A0explicitly not asking if you buy the particulars of this, just the > =A0 =A0overall approach.) > > (D) The current IW seems OK and I haven't seen a good reason to think it > =A0 =A0needs changed. > > Thanks! > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From rs@netapp.com Thu Jan 6 14:12:05 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8FA3A6D1A for ; Thu, 6 Jan 2011 14:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJKDzX2FX2iG for ; Thu, 6 Jan 2011 14:12:04 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 2B5B93A6B9E for ; Thu, 6 Jan 2011 14:12:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,285,1291622400"; d="scan'208";a="229944214" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 06 Jan 2011 14:14:10 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p06ME9As015163; Thu, 6 Jan 2011 14:14:10 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Jan 2011 23:14:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 22:13:32 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C3DDB9A@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] informal poll about initial cwnd Thread-Index: Acut54g59C1amfSzRaOo4P8tkgQQnQABkE2g References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> From: "Scheffenegger, Richard" To: "John Heffner" , X-OriginalArrivalTime: 06 Jan 2011 22:14:09.0617 (UTC) FILETIME=[0A8FB410:01CBADEF] Cc: tcpm@ietf.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:12:05 -0000 Certain implementors have already choosen, if the points in Dave's = presentation are adopted to main linux, for all I know. For the record, given the simplicity I would prefer (A) for low-end / = "closed" environment applications, and (C) for high-volume + public = deployments (ie. Home users/corporate intranets could do with a single = updated IW; operators who could have an impact on a larger (global) = scale to the public internet, should go with (C) - adding some = accountability, basically). Regards, Richard > -----Original Message----- > From: John Heffner [mailto:johnwheffner@gmail.com] > Sent: Donnerstag, 06. J=E4nner 2011 22:20 > To: mallman@icir.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] informal poll about initial cwnd >=20 > As a firm believer in simplicity where possible, I have strong > reservations on (C). >=20 > If approach (D) is chosen, implementors will very soon start making > their own choices for non-standard IW. It's not clear to me this is a > bad thing, but it could be. >=20 > -John >=20 >=20 > On Thu, Jan 6, 2011 at 1:19 PM, Mark Allman wrote: > > > > Given that there are three proposals put down in I-D form in some > matter > > of baked-ness I am wondering if there is any sort of clear WG > preference > > on the *approach* to changing the initial window. =A0So, putting = aside > the > > particulars for a moment and just thinking about the approach I'd > like > > to take a quick, informal, absolutely non-binding in any way > (obviously) > > poll to take the WG's pulse. > > > > So, do you prefer ... > > > > (A) To increase the current static IW definition to a single updated > > =A0 =A0value. > > > > =A0 =A0(Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > > =A0 =A0explicitly not asking about IW=3D10, just IW=3Dsome_X.) > > > > (B) To increase the current static IW definition with a schedule of > IW > > =A0 =A0updates to play out over some period of time. > > > > =A0 =A0(Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, = but I > am > > =A0 =A0explicitly not asking if you like the given schedule.) > > > > (C) To define a procedure for hosts to figure out how to adapt their > IW > > =A0 =A0over time. > > > > =A0 =A0(Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but = I am > > =A0 =A0explicitly not asking if you buy the particulars of this, = just the > > =A0 =A0overall approach.) > > > > (D) The current IW seems OK and I haven't seen a good reason to = think > it > > =A0 =A0needs changed. > > > > Thanks! > > > > 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 Michael.Scharf@alcatel-lucent.com Thu Jan 6 15:02:00 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978463A6F81 for ; Thu, 6 Jan 2011 15:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+5bcfeSyIM5 for ; Thu, 6 Jan 2011 15:01:59 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 5B48D3A6F71 for ; Thu, 6 Jan 2011 15:01:59 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p06N45GV020868 for ; Fri, 7 Jan 2011 00:04:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 7 Jan 2011 00:04:03 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0498DAB9@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] informal poll about initial cwnd Thread-Index: AcutzrpCBUaNw/y2Q1KcYGATpz3cjAAIRi8w References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:02:00 -0000 I would allow (A) because of its simplicity, but the same I-D should also mandate implementors to carefully monitor the impact and strongly recommend to revert to IW3 if any harm is observed. As one potential (recommended?) solution for this, it could propose a procedure somehow along the lines of (C). IMHO implementors MUST really carefully monitor the impact of an increased IW, in particular for large-scale deployments. This can be done by a procedure similar to draft-touch-tcpm-automatic-iw-00, but probably also by other control loops, e. g., by regularly monitoring transaction times at application level. The IETF should describe one application-agnostic way of monitoring the impact of a larger IW, but also allow implementors to come up with other solutions. Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Mark Allman > Sent: Thursday, January 06, 2011 7:20 PM > To: tcpm@ietf.org > Subject: [tcpm] informal poll about initial cwnd >=20 >=20 > Given that there are three proposals put down in I-D form in=20 > some matter of baked-ness I am wondering if there is any sort=20 > of clear WG preference on the *approach* to changing the=20 > initial window. So, putting aside the particulars for a=20 > moment and just thinking about the approach I'd like to take=20 > a quick, informal, absolutely non-binding in any way=20 > (obviously) poll to take the WG's pulse. >=20 > So, do you prefer ... >=20 > (A) To increase the current static IW definition to a single updated > value. >=20 > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > explicitly not asking about IW=3D10, just IW=3Dsome_X.) >=20 > (B) To increase the current static IW definition with a schedule of IW > updates to play out over some period of time. >=20 > (Current proposal:=20 > draft-allman-tcpm-bump-initcwnd-00.txt, but I am > explicitly not asking if you like the given schedule.) >=20 > (C) To define a procedure for hosts to figure out how to=20 > adapt their IW > over time. >=20 > (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am > explicitly not asking if you buy the particulars of this, just the > overall approach.) >=20 > (D) The current IW seems OK and I haven't seen a good reason=20 > to think it > needs changed. >=20 > Thanks! >=20 > allman >=20 >=20 >=20 >=20 From Anumita.Biswas@netapp.com Thu Jan 6 17:20:48 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2833A6DD1 for ; Thu, 6 Jan 2011 17:20:48 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2LNFnE1+eU8 for ; Thu, 6 Jan 2011 17:20:47 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 36ECC3A6DAE for ; Thu, 6 Jan 2011 17:20:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,286,1291622400"; d="scan'208";a="502581953" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Jan 2011 17:22:39 -0800 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p071Mb9o027168; Thu, 6 Jan 2011 17:22:38 -0800 (PST) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.17]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Jan 2011 17:22:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 17:22:36 -0800 Message-ID: In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C3DDB9A@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] informal poll about initial cwnd Thread-Index: Acut54g59C1amfSzRaOo4P8tkgQQnQABkE2gAAN7nzA= References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> <5FDC413D5FA246468C200652D63E627A0C3DDB9A@LDCMVEXC1-PRD.hq.netapp.com> From: "Biswas, Anumita" To: "Scheffenegger, Richard" , "John Heffner" , X-OriginalArrivalTime: 07 Jan 2011 01:22:37.0644 (UTC) FILETIME=[5EABB0C0:01CBAE09] Cc: tcpm@ietf.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 01:20:48 -0000 Fwiw, I prefer us going with (C) as well. A static value always has the = problem that it has to be revisited frequently and there is no guarantee = that it is correct for a given environment. Some implementations may be = more aggressive than others in setting the static value by not following = the standard spec as well. As we have seen from the many discussions on tcpm on IW, the problem is = complex to solve. So I am not sure if we can reach consensus quickly on = the algorithm to increase/decrease IW. In the spirit of making forward = progress, perhaps it makes sense to increase the IW "somewhat" = statically (option A) and continue to work on the dynamic algorithm = proposal. Also the loss distribution across all connections on a host is not = uniform when that host has connections to destinations on widely varying = networks (LANs and WANs). In a perfect world, path heuristics of each = connection should play into the algorithm (RTT, delay, local/remote = destination) so that the least lossy connections get the highest IW = versus the most lossy connections getting lower IWs. Cheers, Anumita. -----Original Message----- From: Scheffenegger, Richard=20 Sent: Thursday, January 06, 2011 2:14 PM To: John Heffner; mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] informal poll about initial cwnd Certain implementors have already choosen, if the points in Dave's = presentation are adopted to main linux, for all I know. For the record, given the simplicity I would prefer (A) for low-end / = "closed" environment applications, and (C) for high-volume + public = deployments (ie. Home users/corporate intranets could do with a single = updated IW; operators who could have an impact on a larger (global) = scale to the public internet, should go with (C) - adding some = accountability, basically). Regards, Richard > -----Original Message----- > From: John Heffner [mailto:johnwheffner@gmail.com] > Sent: Donnerstag, 06. J=E4nner 2011 22:20 > To: mallman@icir.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] informal poll about initial cwnd >=20 > As a firm believer in simplicity where possible, I have strong > reservations on (C). >=20 > If approach (D) is chosen, implementors will very soon start making > their own choices for non-standard IW. It's not clear to me this is a > bad thing, but it could be. >=20 > -John >=20 >=20 > On Thu, Jan 6, 2011 at 1:19 PM, Mark Allman wrote: > > > > Given that there are three proposals put down in I-D form in some > matter > > of baked-ness I am wondering if there is any sort of clear WG > preference > > on the *approach* to changing the initial window. =A0So, putting = aside > the > > particulars for a moment and just thinking about the approach I'd > like > > to take a quick, informal, absolutely non-binding in any way > (obviously) > > poll to take the WG's pulse. > > > > So, do you prefer ... > > > > (A) To increase the current static IW definition to a single updated > > =A0 =A0value. > > > > =A0 =A0(Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > > =A0 =A0explicitly not asking about IW=3D10, just IW=3Dsome_X.) > > > > (B) To increase the current static IW definition with a schedule of > IW > > =A0 =A0updates to play out over some period of time. > > > > =A0 =A0(Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, = but I > am > > =A0 =A0explicitly not asking if you like the given schedule.) > > > > (C) To define a procedure for hosts to figure out how to adapt their > IW > > =A0 =A0over time. > > > > =A0 =A0(Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but = I am > > =A0 =A0explicitly not asking if you buy the particulars of this, = just the > > =A0 =A0overall approach.) > > > > (D) The current IW seems OK and I haven't seen a good reason to = think > it > > =A0 =A0needs changed. > > > > Thanks! > > > > 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 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From muraris@microsoft.com Thu Jan 6 18:43:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28153A6E4E for ; Thu, 6 Jan 2011 18:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u901k7+mZycL for ; Thu, 6 Jan 2011 18:43:06 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3A4673A6E3B for ; Thu, 6 Jan 2011 18:43:06 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 6 Jan 2011 18:45:14 -0800 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.221]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Thu, 6 Jan 2011 18:45:12 -0800 From: Murari Sridharan To: "mallman@icir.org" , "tcpm@ietf.org" Thread-Topic: [tcpm] informal poll about initial cwnd Thread-Index: AQHLrc5la9GnplWcyUmC1Xx1bPDwUpPEy4Iy Date: Fri, 7 Jan 2011 02:45:12 +0000 Message-ID: References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> In-Reply-To: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 02:43:08 -0000 Orders of magnitude jump in bandwidth, with majortiy of link upgrades take = time so i prefer a simple approach, its been a while since we updated Cwnd = and there is evidence of larger windows along the values proposed so i'd st= ongly prefer A. However hosts MUST monitor loss patterns and revert to olde= r defaults and cache these settubgs per-network. We already cache per-netwo= rk properties so it should be trivial to do. There are things i like in (B)= which could be folded into a proposal recommending A. Everything else is u= nnecessarily complex and is likely to be error prone.=20 Thanks Murari=20 ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Mark Allma= n [mallman@icir.org] Sent: Thursday, January 06, 2011 10:19 AM To: tcpm@ietf.org Subject: [tcpm] informal poll about initial cwnd Given that there are three proposals put down in I-D form in some matter of baked-ness I am wondering if there is any sort of clear WG preference on the *approach* to changing the initial window. So, putting aside the particulars for a moment and just thinking about the approach I'd like to take a quick, informal, absolutely non-binding in any way (obviously) poll to take the WG's pulse. So, do you prefer ... (A) To increase the current static IW definition to a single updated value. (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am explicitly not asking about IW=3D10, just IW=3Dsome_X.) (B) To increase the current static IW definition with a schedule of IW updates to play out over some period of time. (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am explicitly not asking if you like the given schedule.) (C) To define a procedure for hosts to figure out how to adapt their IW over time. (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am explicitly not asking if you buy the particulars of this, just the overall approach.) (D) The current IW seems OK and I haven't seen a good reason to think it needs changed. Thanks! allman= From touch@isi.edu Thu Jan 6 20:56:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A9D3A6F06 for ; Thu, 6 Jan 2011 20:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doxfYmIXvxlr for ; Thu, 6 Jan 2011 20:56:13 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 919373A6E59 for ; Thu, 6 Jan 2011 20:56:13 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p074vdEU003751 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 20:57:49 -0800 (PST) Message-ID: <4D269D43.6040906@isi.edu> Date: Thu, 06 Jan 2011 20:57:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Murari Sridharan References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> 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" , "mallman@icir.org" Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 04:56:14 -0000 On 1/6/2011 6:45 PM, Murari Sridharan wrote: > Orders of magnitude jump in bandwidth, with majortiy of link > upgrades take time so i prefer a simple approach, its been a while > since we updated Cwnd and there is evidence of larger windows along > the values proposed so i'd stongly prefer A. OK, so you're for (A). > However hosts MUST > monitor loss patterns and revert to older defaults and cache these > settubgs per-network. That's basically (C) - understanding that the particular algorithm is subject to revision. > We already cache per-network properties so it > should be trivial to do. There are things i like in (B) which could > be folded into a proposal recommending A. That's now (B)? I'm confused as to what your response supports, FWIW. Joe From alexander.zimmermann@comsys.rwth-aachen.de Fri Jan 7 01:10:23 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9BB3A67EE for ; Fri, 7 Jan 2011 01:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg97xLOvvM0n for ; Fri, 7 Jan 2011 01:10:21 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id BC78F3A67C1 for ; Fri, 7 Jan 2011 01:10:21 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LEN00GXDAWR3E70@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 07 Jan 2011 10:12:27 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,288,1291590000"; d="sig'?scan'208";a="87730686" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 07 Jan 2011 10:12:27 +0100 Received: from [137.226.12.52] ([unknown] [137.226.12.52]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LEN00LYYAWRIG00@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 07 Jan 2011 10:12:27 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1-404250314 From: Alexander Zimmermann In-reply-to: Date: Fri, 07 Jan 2011 10:12:26 +0100 Content-transfer-encoding: 7bit Message-id: <18F17BEE-94C3-4CA0-835C-5389C58BC43C@comsys.rwth-aachen.de> References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> <5FDC413D5FA246468C200652D63E627A0C3DDB9A@LDCMVEXC1-PRD.hq.netapp.com> To: "Biswas, Anumita" X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:10:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-404250314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, as many of us I believe that (d) is not a solution. If we miss the opportunity to treat the IW now, implementers will do it for us... (and without us) In general I prefer (C), but besides the question on how we can increase the IW (C or A), I see another big problem: TIME. So, who is willing - to write I-D (C)=20 - to implement and demonstrate (Cs) (adress Jerry's concerns) I we go the c-way, we really need an strict time schedule. Alex Am 07.01.2011 um 02:22 schrieb Biswas, Anumita: > Fwiw, I prefer us going with (C) as well. A static value always has = the problem that it has to be revisited frequently and there is no = guarantee that it is correct for a given environment. Some = implementations may be more aggressive than others in setting the static = value by not following the standard spec as well. 100% agreed. >=20 > As we have seen from the many discussions on tcpm on IW, the problem = is complex to solve. So I am not sure if we can reach consensus quickly = on the algorithm to increase/decrease IW. In the spirit of making = forward progress, perhaps it makes sense to increase the IW "somewhat" = statically (option A) and continue to work on the dynamic algorithm = proposal. I like this idea. >=20 >=20 > Cheers, > Anumita. >=20 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-1-404250314 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0m2PoACgkQdyiq39b9uS4r6QCg2+IgJjestaSMsawXaiv9/UZP Hx0AoJKdLLutGn5BEM9ZANh1dpAXJMk+ =iGlx -----END PGP SIGNATURE----- --Apple-Mail-1-404250314-- From ka-cheong.poon@oracle.com Fri Jan 7 02:19:13 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1AA3A680F for ; Fri, 7 Jan 2011 02:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHxYn9syDmCO for ; Fri, 7 Jan 2011 02:19:13 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F06E93A67F9 for ; Fri, 7 Jan 2011 02:19:12 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p07ALHVN019792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Jan 2011 10:21:18 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p07ALDgE029495 for ; Fri, 7 Jan 2011 10:21:16 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 907323841294395675; Fri, 07 Jan 2011 02:21:15 -0800 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jan 2011 02:21:15 -0800 Message-ID: <4D26E916.4010204@oracle.com> Date: Fri, 07 Jan 2011 18:21:10 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20101209 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:19:14 -0000 On 01/ 7/11 02:34 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > I've been thinking we might wind up with some set of A/B/C in > conjunction. It seems like they don't have to be mutually exclusive > since different hosts could implement different Experimenal policies, > as long as each is felt to be reasonable for Experimental. Of > course, it would probably be better to have one Proposed Standard. Agreed. I don't think one size fits all. A procedure to find out the right value in one site may not be applicable to another site. It seems that folks are too eager in finding a "universal" solution when one may not exist. If (C) is rephrased as Define some guidelines which a site MAY follow to determine the right IW. I'd vote for that. Otherwise, I'd vote for (A) and wait for the next time this issue comes up again :-) This is not (B) since I cannot see the future so I don't believe a schedule of updates can be made. > ________________________________________ > From: tcpm-bounces@ietf.org > [tcpm-bounces@ietf.org] On Behalf Of Mark Allman [mallman@icir.org] > Sent: Thursday, January 06, 2011 1:19 PM To: tcpm@ietf.org Subject: > [tcpm] informal poll about initial cwnd > > Given that there are three proposals put down in I-D form in some > matter of baked-ness I am wondering if there is any sort of clear WG > preference on the *approach* to changing the initial window. So, > putting aside the particulars for a moment and just thinking about > the approach I'd like to take a quick, informal, absolutely > non-binding in any way (obviously) poll to take the WG's pulse. > > So, do you prefer ... > > (A) To increase the current static IW definition to a single updated > value. > > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > explicitly not asking about IW=10, just IW=some_X.) > > (B) To increase the current static IW definition with a schedule of > IW updates to play out over some period of time. > > (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am > explicitly not asking if you like the given schedule.) > > (C) To define a procedure for hosts to figure out how to adapt their > IW over time. > > (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am > explicitly not asking if you buy the particulars of this, just the > overall approach.) > > (D) The current IW seems OK and I haven't seen a good reason to think > it needs changed. > > Thanks! > > allman _______________________________________________ tcpm mailing > list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm -- K. Poon. ka-cheong.poon@oracle.com From ietfa@btconnect.com Fri Jan 7 04:17:20 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281623A67BD for ; Fri, 7 Jan 2011 04:17:20 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abcgI5YAjIsq for ; Fri, 7 Jan 2011 04:17:19 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id A35253A6802 for ; Fri, 7 Jan 2011 04:17:18 -0800 (PST) Received: from host81-156-207-254.range81-156.btcentralplus.com (HELO pc6) ([81.156.207.254]) by c2beaomr10.btconnect.com with SMTP id BFW14886; Fri, 07 Jan 2011 12:19:21 +0000 (GMT) Message-ID: <000401cbae5c$486cb860$4001a8c0@gateway.2wire.net> From: "t.petch" To: "SCHARF, Michael" , "tcpm" References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> <133D9897FB9C5E4E9DF2779DC91E947C0498DAB9@SLFSNX.rcs.alcatel-research.de> Date: Fri, 7 Jan 2011 11:13:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D2704C8.0117, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4D2704CB.0028,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:17:20 -0000 A) for me; it is simple. C) is great for sophisiticated implementors with a sophisticated infrastructure to suppport the implementation, which I think will often not be the case. Perhaps one for an xxxRG not a WG. D) I do not believe will ever happen. Tom Petch ----- Original Message ----- From: "SCHARF, Michael" To: Sent: Friday, January 07, 2011 12:04 AM Subject: Re: [tcpm] informal poll about initial cwnd > I would allow (A) because of its simplicity, but the same I-D should > also mandate implementors to carefully monitor the impact and strongly > recommend to revert to IW3 if any harm is observed. As one potential > (recommended?) solution for this, it could propose a procedure somehow > along the lines of (C). > > IMHO implementors MUST really carefully monitor the impact of an > increased IW, in particular for large-scale deployments. This can be > done by a procedure similar to draft-touch-tcpm-automatic-iw-00, but > probably also by other control loops, e. g., by regularly monitoring > transaction times at application level. The IETF should describe one > application-agnostic way of monitoring the impact of a larger IW, but > also allow implementors to come up with other solutions. > > Michael > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Mark Allman > > Sent: Thursday, January 06, 2011 7:20 PM > > To: tcpm@ietf.org > > Subject: [tcpm] informal poll about initial cwnd > > > > > > Given that there are three proposals put down in I-D form in > > some matter of baked-ness I am wondering if there is any sort > > of clear WG preference on the *approach* to changing the > > initial window. So, putting aside the particulars for a > > moment and just thinking about the approach I'd like to take > > a quick, informal, absolutely non-binding in any way > > (obviously) poll to take the WG's pulse. > > > > So, do you prefer ... > > > > (A) To increase the current static IW definition to a single updated > > value. > > > > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > > explicitly not asking about IW=10, just IW=some_X.) > > > > (B) To increase the current static IW definition with a schedule of IW > > updates to play out over some period of time. > > > > (Current proposal: > > draft-allman-tcpm-bump-initcwnd-00.txt, but I am > > explicitly not asking if you like the given schedule.) > > > > (C) To define a procedure for hosts to figure out how to > > adapt their IW > > over time. > > > > (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am > > explicitly not asking if you buy the particulars of this, just the > > overall approach.) > > > > (D) The current IW seems OK and I haven't seen a good reason > > to think it > > needs changed. > > > > Thanks! > > > > allman > > > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From perfgeek@mac.com Fri Jan 7 08:21:17 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CD83A68C0 for ; Fri, 7 Jan 2011 08:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkmxLLdvzJNR for ; Fri, 7 Jan 2011 08:21:16 -0800 (PST) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by core3.amsl.com (Postfix) with ESMTP id D22E23A6842 for ; Fri, 7 Jan 2011 08:21:16 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LEN00L67UUYOA60@asmtp013.mac.com> for tcpm@ietf.org; Fri, 07 Jan 2011 08:23:23 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1101070047 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-07_08:2011-01-07, 2011-01-07, 1970-01-01 signatures=0 Message-id: From: rick jones To: mallman@icir.org In-reply-to: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Date: Fri, 07 Jan 2011 08:23:20 -0800 References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:21:17 -0000 On Jan 6, 2011, at 10:19 AM, Mark Allman wrote: > So, do you prefer ... > > (A) To increase the current static IW definition to a single updated > value. > > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > explicitly not asking about IW=10, just IW=some_X.) A. Paint it yellow and ship it. (*) rick jones (*) http://greateasyjet.com/funny/paint_yellow.html http://homepage.mac.com/perfgeek From fernando.gont.netbook.win@gmail.com Fri Jan 7 15:57:40 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F1E3A69A4 for ; Fri, 7 Jan 2011 15:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU-2Z96MNcQ7 for ; Fri, 7 Jan 2011 15:57:39 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id 55B4B28C160 for ; Fri, 7 Jan 2011 15:52:19 -0800 (PST) Received: by gyf1 with SMTP id 1so3831132gyf.1 for ; Fri, 07 Jan 2011 15:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=+8FTLMP/5EIpH5CDyp+kBQgaZwQ+g1FxIVvozEuiBos=; b=JqaVYtEPIKaOviGYVRgB8i25en8ZAYJ7eC20LZg19H8/AOEDfN1mz5FEBFSrNKtfN5 jBPA8LDIPFN1dofB2zl04Y7jbTraMq0J5M+zmq0Bn0uCfpdT2fGIGok29Qf9IPABEJQv 3fQbahYgad0acFOhKHBlj+rG0Xfq0gIsl+s0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=aeqqE/yO95/LhodAlLXKsvXUuy/r+Bck38sNn8SDwxo8oq5ddz2cMzbxK+awB5+/J3 Ng0w3Z45IR41SAdTkAEFxmsiz1sVz6kHp0Jyc9vwR1BIrvPe98xgo/xjoWn/+eJxRCFx G/zbumjHQ48hpJpbu/TMiMk6lMzmpFJWDoOSs= Received: by 10.101.29.16 with SMTP id g16mr15460474anj.106.1294444466050; Fri, 07 Jan 2011 15:54:26 -0800 (PST) Received: from [192.168.123.100] ([190.48.230.149]) by mx.google.com with ESMTPS id t1sm34136260ano.3.2011.01.07.15.54.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 15:54:25 -0800 (PST) Sender: Fernando Gont Message-ID: <4D27A097.3040606@gont.com.ar> Date: Fri, 07 Jan 2011 20:24:07 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:57:40 -0000 Folks, We have published the I-D "Defending Against Sequence Number Attacks" (draft-gont-tcpm-rfc1948bis-00), which is a revision of Steven's RFC1948. The Abstract of the I-D is: ---- cut here ---- This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker of guessing the sequence numbers in use by a target connection are reduced. This document is a revision of RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. ---- cut here ---- Any comments will be more than welcome. Thanks, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-tcpm-rfc1948bis-00 Date: Mon, 3 Jan 2011 12:35:29 -0800 (PST) From: IETF I-D Submission Tool To: fernando@gont.com.ar CC: bellovin@acm.org A new version of I-D, draft-gont-tcpm-rfc1948bis-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-tcpm-rfc1948bis Revision: 00 Title: Defending Against Sequence Number Attacks Creation_date: 2011-01-03 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker of guessing the sequence numbers in use by a target connection are reduced. This document is a revision of RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. The IETF Secretariat. From hal.wigoda@gmail.com Fri Jan 7 20:48:59 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F3328C0DD for ; Fri, 7 Jan 2011 20:48:59 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv-kz84J9-Tv for ; Fri, 7 Jan 2011 20:48:58 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 8302C28C0CF for ; Fri, 7 Jan 2011 20:48:55 -0800 (PST) Received: from [75.21.87.212] (helo=[10.0.1.7]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PbQlX-0007ZN-Nm; Fri, 07 Jan 2011 23:50:59 -0500 References: <4D27A097.3040606@gont.com.ar> In-Reply-To: <4D27A097.3040606@gont.com.ar> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <4075D79C-D538-4A0C-BA74-75304A8D8880@gmail.com> Content-Transfer-Encoding: quoted-printable From: Hal Wigoda Date: Fri, 7 Jan 2011 22:50:56 -0600 To: Fernando Gont X-Mailer: Apple Mail (2.1082) X-ELNK-Trace: f4865024121a91b69649176a89d694c0f43c108795ac4507f8f9c01661e8a16b46c0eb759f7860a8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.21.87.212 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 04:48:59 -0000 Where can I get copy of this as I=20 am doing a paper on Covert Channels over TCP/IP using the sequence = number field.... On Jan 7, 2011, at 5:24 PM, Fernando Gont wrote: > Folks, >=20 > We have published the I-D "Defending Against Sequence Number Attacks" > (draft-gont-tcpm-rfc1948bis-00), which is a revision of Steven's = RFC1948. >=20 > The Abstract of the I-D is: > ---- cut here ---- > This document specifies an algorithm for the generation of TCP > Initial Sequence Numbers (ISNs), such that the chances of an off-path > attacker of guessing the sequence numbers in use by a target > connection are reduced. This document is a revision of RFC 1948, and > takes the ISN generation algorithm originally proposed in that > document to Standards Track. > ---- cut here ---- >=20 > Any comments will be more than welcome. >=20 > Thanks, > Fernando >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-gont-tcpm-rfc1948bis-00 > Date: Mon, 3 Jan 2011 12:35:29 -0800 (PST) > From: IETF I-D Submission Tool > To: fernando@gont.com.ar > CC: bellovin@acm.org >=20 >=20 > A new version of I-D, draft-gont-tcpm-rfc1948bis-00.txt has been > successfully submitted by Fernando Gont and posted to the IETF = repository. >=20 > Filename: draft-gont-tcpm-rfc1948bis > Revision: 00 > Title: Defending Against Sequence Number Attacks > Creation_date: 2011-01-03 > WG ID: Independent Submission > Number_of_pages: 12 >=20 > Abstract: > This document specifies an algorithm for the generation of TCP > Initial Sequence Numbers (ISNs), such that the chances of an off-path > attacker of guessing the sequence numbers in use by a target > connection are reduced. This document is a revision of RFC 1948, and > takes the ISN generation algorithm originally proposed in that > document to Standards Track. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Sat Jan 8 06:34:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6281D28C0FD for ; Sat, 8 Jan 2011 06:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.327 X-Spam-Level: X-Spam-Status: No, score=-10.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-++MB25CQza for ; Sat, 8 Jan 2011 06:34:12 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 3122828C0F0 for ; Sat, 8 Jan 2011 06:34:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,293,1291622400"; d="scan'208";a="230132795" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 08 Jan 2011 06:36:14 -0800 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p08EaDHC003869; Sat, 8 Jan 2011 06:36:14 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 8 Jan 2011 15:36:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 8 Jan 2011 14:36:02 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C3DDFCA@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4D27A097.3040606@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 Thread-Index: Acuuxznn7qJy6fTUTn2f1I1Vrkcv+AAeOI0g References: <4D27A097.3040606@gont.com.ar> From: "Scheffenegger, Richard" To: "Fernando Gont" , X-OriginalArrivalTime: 08 Jan 2011 14:36:13.0645 (UTC) FILETIME=[666E97D0:01CBAF41] Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:34:14 -0000 Fernando, group, On the basis of "eating our own dogfood", updating rfc1948 to make it to = standards track and updating it with current findings is a supportable = idea.=20 However, the complete replacement of the references to MD5 with SHA256 = may be discussable still - a partial list of acceptable hash algorithms = may be advisable (ie. MD5 might be more readily available to an = implementer, than SHA-256; thus he may want to skip proper ISN = generation altogether, if SHA-256 has to be implemented first. Or only a = poor substitute (such as PRN generator as MT64 (or even the = compiler-default random()) may be used as hash.... Only found a typo (section B.1 s/Informaitonal/Informational/). Regards, Richard > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Samstag, 08. J=E4nner 2011 00:24 > To: tcpm@ietf.org > Subject: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm- > rfc1948bis-00 >=20 > Folks, >=20 > We have published the I-D "Defending Against Sequence Number Attacks" > (draft-gont-tcpm-rfc1948bis-00), which is a revision of Steven's > RFC1948. >=20 > The Abstract of the I-D is: > ---- cut here ---- > This document specifies an algorithm for the generation of TCP > Initial Sequence Numbers (ISNs), such that the chances of an off-path > attacker of guessing the sequence numbers in use by a target > connection are reduced. This document is a revision of RFC 1948, and > takes the ISN generation algorithm originally proposed in that > document to Standards Track. > ---- cut here ---- >=20 > Any comments will be more than welcome. >=20 > Thanks, > Fernando >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-gont-tcpm-rfc1948bis-00 > Date: Mon, 3 Jan 2011 12:35:29 -0800 (PST) > From: IETF I-D Submission Tool > To: fernando@gont.com.ar > CC: bellovin@acm.org >=20 >=20 > A new version of I-D, draft-gont-tcpm-rfc1948bis-00.txt has been > successfully submitted by Fernando Gont and posted to the IETF > repository. >=20 > Filename: draft-gont-tcpm-rfc1948bis > Revision: 00 > Title: Defending Against Sequence Number Attacks > Creation_date: 2011-01-03 > WG ID: Independent Submission > Number_of_pages: 12 >=20 > Abstract: > This document specifies an algorithm for the generation of TCP > Initial Sequence Numbers (ISNs), such that the chances of an off-path > attacker of guessing the sequence numbers in use by a target > connection are reduced. This document is a revision of RFC 1948, and > takes the ISN generation algorithm originally proposed in that > document to Standards Track. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook@gmail.com Sat Jan 8 10:20:05 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D833A6802 for ; Sat, 8 Jan 2011 10:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y84gi4yCmmKc for ; Sat, 8 Jan 2011 10:20:04 -0800 (PST) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by core3.amsl.com (Postfix) with ESMTP id 9BFE33A677C for ; Sat, 8 Jan 2011 10:20:00 -0800 (PST) Received: by fxm14 with SMTP id 14so5422853fxm.1 for ; Sat, 08 Jan 2011 10:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Ok+WLwMufvuxCCfhRz83T7/Ts73Z6a6jvCP7+3ZPkPU=; b=WJwEX25eF2SkGNx9uACmoglWlpOtomS40J/vv6Qo7V7y4H02Nk2Tjku2CToCDTSH0u itrkdO8IHnxJxSd08HeKLQyNimFhTMNYXQAoi4qwjdnTLSthJeO/1CvjBHFjaj5MNLlo rm4GdMKg3Zc+Enk9XytSlxX3N02f+JKuNiZ5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ei/6opbhyO2aGG00JhprvZy6ajAgNri01OmkKN3GZ4eIR34ugy4mI7hcEUX+So3+Ut WsRlOc4mZWBdhw4a6Ee7VIKLDR+z5+wyoq4LYppGspIYjssZAIgQMbOXJcH8JfhfMDLr +XoEOCZxbh88wAAHzpLCn0Oyw7e0vrBibXkpk= MIME-Version: 1.0 Received: by 10.223.81.76 with SMTP id w12mr1972196fak.26.1294510928024; Sat, 08 Jan 2011 10:22:08 -0800 (PST) Sender: fernando.gont.netbook@gmail.com Received: by 10.223.74.3 with HTTP; Sat, 8 Jan 2011 10:22:07 -0800 (PST) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C3DDFCA@LDCMVEXC1-PRD.hq.netapp.com> References: <4D27A097.3040606@gont.com.ar> <5FDC413D5FA246468C200652D63E627A0C3DDFCA@LDCMVEXC1-PRD.hq.netapp.com> Date: Sat, 8 Jan 2011 15:22:07 -0300 X-Google-Sender-Auth: IlUtjOQl0OaCMOjpui6UK73oglI Message-ID: From: Fernando Gont To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Cc: ah@tr-sys.de, tcpm@ietf.org, fernando@gont.com.ar Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:20:05 -0000 Hi, Richard, Thanks so much for your timely feedback! -- You'll find my response inline... On Sat, Jan 8, 2011 at 11:36 AM, Scheffenegger, Richard wrote: > However, the complete replacement of the references to MD5 with SHA256 may be discussable > still - a partial list of acceptable hash algorithms may be advisable (ie. MD5 might be more readily > available to an implementer, than SHA-256; thus he may want to skip proper ISN generation altogether, > if SHA-256 has to be implemented first. Or only a poor substitute (such as PRN generator as MT64 > (or even the compiler-default random()) may be used as hash.... The recommendation of SHA-256 instead of MD5 was, for the most part, in response of my recent experience with the IESG: While pursuing draft-ietf-tsvwg-port-randomization, they suggested that MD5 be replaced with SHA-256 (in one of the port randomization algorithms, which uses the expression specified in RFC1948). IIRC, both of the co-authors (Steven and me) and Alfred (CC'ed, who reviewed this document before publication) agreed that MD5 would be fine for *this* purpose... but went ahead with s/MD5(HMAC-SHA-256/ because of what I mentioned about the IESG. I also recall that there's an I-D aiming at deprecate MD5 altogether? -- not sure how it would affect us. FWIW, I do agree with you that MD5 may be more readily available. -- actually, many systems already implement RFC1948, with MD5 rather than HMAC-SHA-256. All the above said, I'd be interested in hearing input from the WG about this particular issue. > Only found a typo (section B.1 s/Informaitonal/Informational/). Will fix this. Thanks! Best regards, Fernando From L.Wood@surrey.ac.uk Sat Jan 8 10:51:49 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974BB3A6805 for ; Sat, 8 Jan 2011 10:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMX9agJmataG for ; Sat, 8 Jan 2011 10:51:48 -0800 (PST) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id CBF283A6802 for ; Sat, 8 Jan 2011 10:51:47 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-72.messagelabs.com!1294512835!36975233!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 3830 invoked from network); 8 Jan 2011 18:53:55 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-7.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2011 18:53:55 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.223]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sat, 8 Jan 2011 18:53:55 +0000 From: To: , Date: Sat, 8 Jan 2011 18:53:54 +0000 Thread-Topic: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 Thread-Index: AcuvYP+gwL6Vr96vQGqkfp2w1nvM4gAAYXo7 Message-ID: References: <4D27A097.3040606@gont.com.ar> <5FDC413D5FA246468C200652D63E627A0C3DDFCA@LDCMVEXC1-PRD.hq.netapp.com>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ah@tr-sys.de, tcpm@ietf.org Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:51:49 -0000 Much discussion of the ID to deprecate MD5 on the main ietf mailing list in= last call. Consensus settled around 'MD5 is still useful if there are no s= ecurity implications, but do a careful security evaluation first before usi= ng MD5' and this is reflected in the updated http://tools.ietf.org/html/draft-turner-md5-seccon-update-08 Where the MD5 checksum is used inline with the protocol solely to protect against errors an MD5 checksum is still an acceptable use. Applications and protocols need to clearly state in their security considerations what security services, if any, are expected from the MD5 checksum. In fact, any application and protocol that employs MD5 needs to clearly state the expected security services from their use of MD5. My take is that all claimed 'secure' hashes will be found to have collision= s eventually, which is the nature of most checksums (where probability of c= olliisions increases with filesize). And there's probably an underlying mat= hematical proof that there will always be collisions... I am surprised secu= rity people aren't spending their time recommending that we don't use CRC32= c, or one's complement checksums, due to the high risk of collisions and ea= sy falsifiability... OMG, TCP still uses one's complement checksums! On eve= ry packet! It's insecure! The HORROR! Deprecate TCP NOW! And you should go ahead and use MD5, because hey, it's still better than th= e one's complement checksum endemic to TCP, and if TCP is still using one's= complement for packets, securing any aspect of TCP is just ridiculous. Usi= ng either MD5 or SHA for seq no generation is a palliative measure, as your= draft says, but using SHA is also a placebo; you think you're getting secu= rity because it's SHA, but you're not. Stick with MD5, where you know you'r= e not really getting security, and you therefore don't claim that TCP is se= cure because SHA is involved. The IESG response of 'must not use MD5' is the kind of kneejerk similar to= that longstanding 'all protocols must implement congestion control'. Not = suitable in all cases; more rational thought required. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Fernando G= ont [fernando@gont.com.ar] Sent: 08 January 2011 18:22 To: Scheffenegger, Richard Cc: ah@tr-sys.de; tcpm@ietf.org; fernando@gont.com.ar Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-= rfc1948bis-00 Hi, Richard, Thanks so much for your timely feedback! -- You'll find my response inline.= .. On Sat, Jan 8, 2011 at 11:36 AM, Scheffenegger, Richard wro= te: > However, the complete replacement of the references to MD5 with SHA256 ma= y be discussable > still - a partial list of acceptable hash algorithms may be advisable (ie= . MD5 might be more readily > available to an implementer, than SHA-256; thus he may want to skip prope= r ISN generation altogether, > if SHA-256 has to be implemented first. Or only a poor substitute (such a= s PRN generator as MT64 > (or even the compiler-default random()) may be used as hash.... The recommendation of SHA-256 instead of MD5 was, for the most part, in response of my recent experience with the IESG: While pursuing draft-ietf-tsvwg-port-randomization, they suggested that MD5 be replaced with SHA-256 (in one of the port randomization algorithms, which uses the expression specified in RFC1948). IIRC, both of the co-authors (Steven and me) and Alfred (CC'ed, who reviewed this document before publication) agreed that MD5 would be fine for *this* purpose... but went ahead with s/MD5(HMAC-SHA-256/ because of what I mentioned about the IESG. I also recall that there's an I-D aiming at deprecate MD5 altogether? -- not sure how it would affect us. FWIW, I do agree with you that MD5 may be more readily available. -- actually, many systems already implement RFC1948, with MD5 rather than HMAC-SHA-256. All the above said, I'd be interested in hearing input from the WG about this particular issue. > Only found a typo (section B.1 s/Informaitonal/Informational/). Will fix this. Thanks! Best regards, Fernando _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook.win@gmail.com Sat Jan 8 11:32:50 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0564F3A6810 for ; Sat, 8 Jan 2011 11:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RST+CwGeQpg5 for ; Sat, 8 Jan 2011 11:32:48 -0800 (PST) Received: from mail-gw0-f66.google.com (mail-gw0-f66.google.com [74.125.83.66]) by core3.amsl.com (Postfix) with ESMTP id A742E3A6805 for ; Sat, 8 Jan 2011 11:32:48 -0800 (PST) Received: by gwj18 with SMTP id 18so4069025gwj.1 for ; Sat, 08 Jan 2011 11:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=wTW9KOosawqdP0fnIGG12jmg6bYeS5tZEMUBe1fsyIY=; b=coJxgoOw+fg3OYcicHY2y2MPXLjcay4k1HJ6lFCVXFOahfFt08R2rff8k2OdwR4auX aKnMNfjR00KCleK6Y2qQFNoXPOzcGRH3maKbRI2ysyB27TView9IBL+NJBXxa9LvObYF kd8jYiTol7q8obJE8+08t34g330Mmv9pKEzYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=WnjwdBny1ClGWv07L+VUODmlRFFl/9oqlNABVBgqDqt2ppQxb2Y0rJ0iY8pISQh48y 4tiX20kGn5h/iF/S2RdUGyRrygt+z7vzFSresW2cMV1GAxsf/zcfL0YNcnTOOBElyc8a wNb6fkL+M3o/jafe7ZPJJbG6tcfdpVGTajAFs= Received: by 10.101.179.30 with SMTP id g30mr16045998anp.196.1294515296876; Sat, 08 Jan 2011 11:34:56 -0800 (PST) Received: from [192.168.0.127] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id x31sm35212145ana.29.2011.01.08.11.34.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 11:34:55 -0800 (PST) Sender: Fernando Gont Message-ID: <4D28BC58.7020608@gont.com.ar> Date: Sat, 08 Jan 2011 16:34:48 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4D27A097.3040606@gont.com.ar> <5FDC413D5FA246468C200652D63E627A0C3DDFCA@LDCMVEXC1-PRD.hq.netapp.com>, In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ah@tr-sys.de, tcpm@ietf.org Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:32:50 -0000 Hi, Lloyd, On 08/01/2011 03:53 p.m., L.Wood@surrey.ac.uk wrote: > Much discussion of the ID to deprecate MD5 on the main ietf mailing > list in last call. Consensus settled around 'MD5 is still useful if > there are no security implications, but do a careful security > evaluation first before using MD5' and this is reflected in the > updated http://tools.ietf.org/html/draft-turner-md5-seccon-update-08 > Where the MD5 checksum is used inline with the protocol solely to > protect against errors an MD5 checksum is still an acceptable use. > Applications and protocols need to clearly state in their security > considerations what security services, if any, are expected from the > MD5 checksum. In fact, any application and protocol that employs MD5 > needs to clearly state the expected security services from their use > of MD5. Well, but in this case we'd be "assuming" that MD5 is secure (*), and then the IESG would likely ask us to replace MD5 with SHA-256 during IESG review -- they did this for port-randomization, which borrows the scheme from RFC 1948. (*) For this particular use, we believe that MD5 is still good enough. -- after all RFC1948 aims at mitigating *blind* attacks (connection spoofing, etc.). If you're really worried about MD5 collisions for the ISNs, then you should be using IPsec or the like. > And you should go ahead and use MD5, because hey, it's still better > than the one's complement checksum endemic to TCP, and if TCP is > still using one's complement for packets, securing any aspect of TCP > is just ridiculous. Using either MD5 or SHA for seq no generation is > a palliative measure, as your draft says, but using SHA is also a > placebo; you think you're getting security because it's SHA, but > you're not. Stick with MD5, where you know you're not really getting > security, and you therefore don't claim that TCP is secure because > SHA is involved. MD5 or SHA buy you the same thing, because in our threat model an attacker would not be exploiting the collisions properties of MD5. > The IESG response of 'must not use MD5' is the kind of kneejerk > similar to that longstanding 'all protocols must implement > congestion control'. Not suitable in all cases; more rational thought > required. But you still need no DISCUSSes for a document to be published as an RFC... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Sat Jan 8 11:39:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E58128C14E for ; Sat, 8 Jan 2011 11:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUD3SKagEfHO for ; Sat, 8 Jan 2011 11:39:09 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id 3765828C145 for ; Sat, 8 Jan 2011 11:39:08 -0800 (PST) Received: by gyf1 with SMTP id 1so3926486gyf.1 for ; Sat, 08 Jan 2011 11:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=y41i/QqMIrt3t/QvmoTaxqifl+04baOjOl9dQBHx2x0=; b=hUerSehVrLOcX4Npa/zMW8GaB9GznFCKcZlLGJz4l59/01X9dzjxkJWXuhbsX7lHVB OHTrM/YGm95BHVr3icxeeqlQXim926Vist9f6pmJUm81BkpaupP6N65H5mB00XT/zHh7 ktrKPxOrtYGOD1osq9lVYTfLTCF4o70hGUVWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=r8Wk2m7jSb76W2X9VRGtHEXqf8T6ABEuHsJJ4uZjQWb8X5I4MEsrCPZr7cgzE31OMC jTinWS1bOywcvytSq+wGGx/ZhDwmLPuhCBr4C84Pv+R4u/aQH0mfqhE2rC4sDVjPUlCC CfAtaN5JqTujr1/j5QYZ051Fafk0r0B1JUGjM= Received: by 10.150.97.4 with SMTP id u4mr27252418ybb.273.1294515675046; Sat, 08 Jan 2011 11:41:15 -0800 (PST) Received: from [192.168.0.127] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id v39sm1215137yba.7.2011.01.08.11.41.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 11:41:14 -0800 (PST) Sender: Fernando Gont Message-ID: <4D27F91C.6060500@gont.com.ar> Date: Sat, 08 Jan 2011 02:41:48 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Hal Wigoda References: <4D27A097.3040606@gont.com.ar> <4075D79C-D538-4A0C-BA74-75304A8D8880@gmail.com> In-Reply-To: <4075D79C-D538-4A0C-BA74-75304A8D8880@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:39:10 -0000 Hi, Hal, http://www.ietf.org/id/draft-gont-tcpm-rfc1948bis-00.txt Best regards, Fernando On 08/01/2011 01:50 a.m., Hal Wigoda wrote: > > Where can I get copy of this as I > am doing a paper on Covert Channels over TCP/IP using the sequence number field.... > > On Jan 7, 2011, at 5:24 PM, Fernando Gont wrote: > >> Folks, >> >> We have published the I-D "Defending Against Sequence Number Attacks" >> (draft-gont-tcpm-rfc1948bis-00), which is a revision of Steven's RFC1948. >> >> The Abstract of the I-D is: >> ---- cut here ---- >> This document specifies an algorithm for the generation of TCP >> Initial Sequence Numbers (ISNs), such that the chances of an off-path >> attacker of guessing the sequence numbers in use by a target >> connection are reduced. This document is a revision of RFC 1948, and >> takes the ISN generation algorithm originally proposed in that >> document to Standards Track. >> ---- cut here ---- >> >> Any comments will be more than welcome. >> >> Thanks, >> Fernando >> >> >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-gont-tcpm-rfc1948bis-00 >> Date: Mon, 3 Jan 2011 12:35:29 -0800 (PST) >> From: IETF I-D Submission Tool >> To: fernando@gont.com.ar >> CC: bellovin@acm.org >> >> >> A new version of I-D, draft-gont-tcpm-rfc1948bis-00.txt has been >> successfully submitted by Fernando Gont and posted to the IETF repository. >> >> Filename: draft-gont-tcpm-rfc1948bis >> Revision: 00 >> Title: Defending Against Sequence Number Attacks >> Creation_date: 2011-01-03 >> WG ID: Independent Submission >> Number_of_pages: 12 >> >> Abstract: >> This document specifies an algorithm for the generation of TCP >> Initial Sequence Numbers (ISNs), such that the chances of an off-path >> attacker of guessing the sequence numbers in use by a target >> connection are reduced. This document is a revision of RFC 1948, and >> takes the ISN generation algorithm originally proposed in that >> document to Standards Track. >> >> >> >> >> 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 > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Sun Jan 9 00:58:41 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8493A67F8 for ; Sun, 9 Jan 2011 00:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.517 X-Spam-Level: X-Spam-Status: No, score=-108.517 tagged_above=-999 required=5 tests=[AWL=2.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icRq2Otqbf2i for ; Sun, 9 Jan 2011 00:58:40 -0800 (PST) Received: from mgw-da01.nokia.com (mgw-da01.ext.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 66E353A67EC for ; Sun, 9 Jan 2011 00:58:40 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0990i1j023977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jan 2011 11:00:46 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-8-576270865; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Sun, 9 Jan 2011 10:59:26 +0200 Message-Id: <349829AA-907C-4F75-8D52-D1F34FE1D667@nokia.com> References: <4D27A097.3040606@gont.com.ar> <5FDC413D5FA246468C200652D63E627A0C3DDFCA@LDCMVEXC1-PRD.hq.netapp.com> To: Fernando Gont X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Sun, 09 Jan 2011 11:00:41 +0200 (EET) X-Nokia-AV: Clean Cc: ah@tr-sys.de, tcpm@ietf.org Subject: Re: [tcpm] Fwd: New Version Notification fordraft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 08:58:41 -0000 --Apple-Mail-8-576270865 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-1-8, at 20:22, Fernando Gont wrote: > The recommendation of SHA-256 instead of MD5 was, for the most part, > in response of my recent experience with the IESG: While pursuing > draft-ietf-tsvwg-port-randomization, they suggested that MD5 be > replaced with SHA-256 (in one of the port randomization algorithms, > which uses the expression specified in RFC1948). the suggestion actually came from the sec-dir reviewer, and it wasn't a = very strong suggestion: On 2010-2-27, at 4:05, Charlie Kaufman wrote: > p16 para 2: suggests use of MD5, which is fine from the point of view = of documenting current practice, and in fact is cryptographically just = fine in this context. Nevertheless, crypto weenies the world over will = pounce on you if it looks like you're suggesting that people use it. = It's probably better to just suggest "some cryptographic hash function", = or if you have to suggest something specific, perhaps SHA-256. The = appendix at the end should specify the hash algorithm used by existing = implementations. Cullen, who was AD at the time, also commented on this, but basically = just wanted to make sure that a security person had reviewed this in = depth: On 2010-3-4, at 7:43, Cullen Jennings wrote: > I'm fairly skeptical of the advice on choosing the key sizes. I'm not = a crypto person but I'd love to see some analysis of this.=20 ... > I suspect I would be much more conformable with something that had = been looked at lots, like AES counter mode. Again, I'm not even = qualified to suggest anything here but I'm looking for evidence the = crypto stuff was seriously looked at.=20 So we probably could have argued to retain MD5 for port-randomization = (maybe as part of a list of crypto hash functions, as Charlie = suggested). That should mean that it should be OK to retain it here as = well, esp. if AES-256 creates implementation difficulties for some = stacks. Lars= --Apple-Mail-8-576270865 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEwOTA4NTkyN1owIwYJKoZIhvcNAQkE MRYEFNLYtbegDRR5DstuIwC+GoZ3G7T/MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AHDWsLlTWrr3c2gQ/hJqisrIbMHQcRjmuY6IbYJqbUy2axaERm/9elBAMS1+eFMk48IsDk8OEerw xuRR8sjSlTzPpF4hQE8/Wv/UnoVTIN95BB59b+JH0L/aai4C38bKJpUBimjMMfTLdsmzh/Hmr4rT Ifsv6yIbDH2jilszT+OYTvOyP3FR+is4EF8y/l9Ni2sDkJfAlWVfoUbVoAdjgPiFYwHHW6HVrGtb dzth5SDeceZrDHG/nbTRWv1xRENRZ9x1S+/v87yFox62aklGn6jPEcIX2/A07Jnux5lfq0eIvMZ7 Bmg+KT7jfO7j2mF+uvRudLM21qdydV8rmYKntdAAAAAAAAA= --Apple-Mail-8-576270865-- From rs@netapp.com Mon Jan 10 10:23:02 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7703A6B18 for ; Mon, 10 Jan 2011 10:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.131 X-Spam-Level: X-Spam-Status: No, score=-9.131 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuBL-7Hur4YY for ; Mon, 10 Jan 2011 10:22:57 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id F087928C0CF for ; Mon, 10 Jan 2011 10:22:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,302,1291622400"; d="scan'208,217";a="233865346" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Jan 2011 10:25:10 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (ldcrsexc2-prd.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0AIP9k9012778; Mon, 10 Jan 2011 10:25:10 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Jan 2011 18:25:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB0F3.B67F3324" x-cr-puzzleid: {EA3A595C-05F7-404E-AAF5-0D985F56AB8A} x-cr-hashedpuzzle: DhZu Ew+7 FFxS G5uH L2TS O+De PjC0 Pj0N QA1U TZk/ UDms UP9g UzxR VfAH Vg9T WtXS; 2; aQBjAGMAcgBnAEAAYwBzAC4AdQBjAGwALgBhAGMALgB1AGsAOwB0AGMAcABtAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {EA3A595C-05F7-404E-AAF5-0D985F56AB8A}; cgBzAEAAbgBlAHQAYQBwAHAALgBjAG8AbQA=; Mon, 10 Jan 2011 18:24:47 GMT; UgBUAFQATQAgACsAIAB0AGkAbQBlAHMAdABhAG0AcABzAA== Content-class: urn:content-classes:message Date: Mon, 10 Jan 2011 18:24:47 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTTM + timestamps Thread-Index: Acuw86lm0NT7H57wQhaXrheqf3sEDw== From: "Scheffenegger, Richard" To: , X-OriginalArrivalTime: 10 Jan 2011 18:25:09.0939 (UTC) FILETIME=[B6BA3830:01CBB0F3] Subject: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:23:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB0F3.B67F3324 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi group, in order not to spam the whole group, I would like to learn who is interested in the heuristics and signaling around round-trip measurement, timestamps and possible synergies between TS and other option, as well as some empirical measurements around currently deployed tcp stacks that diverge from the IETF specs in these aspects. In the light of some recent developments (ie. LEDBAT, path-chirp/chirp CC), and more efficient (end-of-flow / non-congestion) loss recovery, improvements in that space may be of interest to a larger group of implementers too... With your feedback, I would like to learn the extent of possible interest, before going further with my work in that area! Best regards, Richard Scheffenegger =09 ------_=_NextPart_001_01CBB0F3.B67F3324 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RTTM + timestamps

Hi = group,

in order not to spam = the whole group, I would like to learn who is interested = in the heuristics and signaling = around round-trip measurement, timestamps and possible synergies between = TS and other option, as well as = some empirical measurements around currently deployed tcp stacks that = diverge from the IETF specs in these aspects.

In the light of = some recent developments = (ie. = LEDBAT, path-chirp/chirp = CC), = and more efficient (end-of-flow / = non-congestion) loss recovery, improvements in = that space may be of interest to a = larger group of implementers = too…

With your feedback, I would like to learn the extent of = possible interest, before going further with my work in = that area!

Best = regards,

    Richard = Scheffenegger

------_=_NextPart_001_01CBB0F3.B67F3324-- From touch@isi.edu Mon Jan 10 11:07:28 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9613A6B0E for ; Mon, 10 Jan 2011 11:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-LxFBOGPCTz for ; Mon, 10 Jan 2011 11:07:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id DDEE63A69C5 for ; Mon, 10 Jan 2011 11:07:27 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0AJ9DCi013866 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 11:09:13 -0800 (PST) Message-ID: <4D2B5958.3090304@isi.edu> Date: Mon, 10 Jan 2011 11:09:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> In-Reply-To: <4D27A097.3040606@gont.com.ar> 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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:07:28 -0000 My key questions are below. IMO, this might be ready for experimental, but shouldn't go standards-track unless it uses an algorithm for which we have substantial experience. This doc introduces a new alg, which isn't appropriate for a simple "revise to standards track" process, IMO. Joe 1) is this the most important change we want to make to TCP as a WG, we ought to be discussing this for every standards-track change to TCP; we don't seem to be doing this as a plan 2) the discussion of how this doc changes 1948 needs to be included in the core of the doc (Sec 2, IMO), and needs to be updated - this is a new algorithm, which, IMO, is experimental at best the alg proposed in Sec 2 is predictable for a given socket pair; that seems inconsistent with the security concerns that drive this doc - security concerns with MD5 need to be cited; the current note cites the definition of MD5 only; it's not clear they apply for unkeyed use as just a hash function - the impact of guessing a sequence number should be discussed better; as per 4953, increasing window sizes and link speeds means that knowing ISN value isn't as important as it once was 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed most machines simply don't keep TW around as long as they are required; they also sometimes use a single pseudo-random generator across all connections; this needs to be considered in more detail 3) the doc should discuss how it can be implemented on a machine that doesn't know absolute time even TCP's timestamps don't need to be absolute, but if a machine always boots the same way with the same info, it will reuse sequence numbers unless it has a persistent clock, coordinates time with another party, or has persistent state; none of these are necessarily true, e.g., for small devices 4) where true authentication is noted as an alternative, TCP-AO should be included, IMO From touch@isi.edu Mon Jan 10 11:13:26 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279CF28C0EF for ; Mon, 10 Jan 2011 11:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnitxezdWRe1 for ; Mon, 10 Jan 2011 11:13:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 7046328C0E4 for ; Mon, 10 Jan 2011 11:13:25 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0AJF3e9014962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 11:15:03 -0800 (PST) Message-ID: <4D2B5AB6.6070206@isi.edu> Date: Mon, 10 Jan 2011 11:15:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> In-Reply-To: <4D2B5958.3090304@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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:13:26 -0000 As a broader question, do we really need to say "do this" (where "this" is a new algorithm)? Or would it be sufficient to say (as, e.g., a BCP), "doing something is a good thing". Joe From fernando.gont.netbook.win@gmail.com Mon Jan 10 11:37:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74FC328C0F1 for ; Mon, 10 Jan 2011 11:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZC7+-b9wfuh for ; Mon, 10 Jan 2011 11:37:14 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 527A028B23E for ; Mon, 10 Jan 2011 11:37:14 -0800 (PST) Received: by yxd5 with SMTP id 5so4340965yxd.1 for ; Mon, 10 Jan 2011 11:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=IT2BbaNtN5BMCWtZTvm9Rg7rTID2lJbmp8Swmlg39xg=; b=RaIwlVN8ph8fCa7Y7/5Hw/Lmckfu03d2cMdXY3QJHglvI8TBh822Vjq8EzQpmP/Faw BikZzMtb9Bw9GT2qtJ7BMx1f8iaUjTnD6cXVHh7SGFYL+PiDPH6w8PpaicaqVRRRRkII MqZWkMeF4M299gYg6S+Qr8pG2twt6o4MmVGvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=NfwVT15KpgcKd2xiGFnHN/CWIU2GzyNVZA2B/NeD79k2nwM815N5XrpxXGRBwJdHSU f0GkoxMfxf9bKOawOzM5CSUpEflr2zvGGpdLDjBipwxPj8pBCi6NtAKBCM2xBX2c3sGv JOfy3KU/ZaG4E5M1RBjDQGQvGOzUJKjvndGMM= Received: by 10.236.102.129 with SMTP id d1mr5873015yhg.50.1294688325596; Mon, 10 Jan 2011 11:38:45 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id m49sm2246015yha.2.2011.01.10.11.38.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 11:38:44 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B602E.1060408@gont.com.ar> Date: Mon, 10 Jan 2011 16:38:22 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> In-Reply-To: <4D2B5958.3090304@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:37:15 -0000 Hi, Joe, On 10/01/2011 04:09 p.m., Joe Touch wrote: > IMO, this might be ready for experimental, but shouldn't go > standards-track unless it uses an algorithm for which we have > substantial experience. Yes, I'll be backing out SHA-256 and will go back to recommending MD5. -- As already noted on this list, this change was political rather than technical. So I assume that this would address your concern and you'd be game for std track, right? > 1) is this the most important change we want to make to TCP > > as a WG, we ought to be discussing this for > every standards-track change to TCP; we don't seem > to be doing this as a plan huh? Why should this be "the most important change to TCP" for us to work on it? > 2) the discussion of how this doc changes 1948 needs to be included in > the core of the doc (Sec 2, IMO), and needs to be updated No problem with this -- what do others think? > - this is a new algorithm, which, IMO, is experimental at best > the alg proposed in Sec 2 is predictable for a given socket > pair; that seems inconsistent with the security concerns that > drive this doc Joe, this document is about mitigating blind attacks. If you know the socket pair, you can predict the ISN, unless you were able to see the ISN of a previous connection for that socket pair -- which is a completely different threat-model, that this document does not (and doesn't aim to) address. > - security concerns with MD5 need to be cited; the current > note cites the definition of MD5 only; it's not clear > they apply for unkeyed use as just a hash function The I-D cited by Lloyd will be referenced in the next revision. > - the impact of guessing a sequence number should be discussed > better; as per 4953, increasing window sizes and link speeds > means that knowing ISN value isn't as important as it once was Guessing the ISN is still as important as it was when it comes to connection spoofing (note that most of the discussion is about connection spoofing and trust relationship exploitation). We could possibly add an informative reference to RFC 4953 for other sequence number issues. > 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed > > most machines simply don't keep TW around as long as they > are required; they also sometimes use a single pseudo-random > generator across all connections; this needs to be considered > in more detail So now you care about running code? -- It's surprising that you're raising this, instead of declaring them as bugs and be done with it. Anyway, this document is not about the TIME-WAIT state. And proper references are included where appropriate (e.g., the reference to the CPNI TCP security document) > 3) the doc should discuss how it can be implemented on a machine that > doesn't know absolute time > even TCP's timestamps don't need to be absolute, but if a > machine always boots the same way with the same info, it > will reuse sequence numbers unless it has a persistent clock, > coordinates time with another party, or has persistent state; > none of these are necessarily true, e.g., for small devices C'mon, Joe: initialize that timer to a random value, and be done with it. > 4) where true authentication is noted as an alternative, TCP-AO should > be included, IMO No problem with this. Will do. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jan 10 11:48:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5134F28C106 for ; Mon, 10 Jan 2011 11:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ITmPz6R9iMS for ; Mon, 10 Jan 2011 11:48:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 1FDB328C0FF for ; Mon, 10 Jan 2011 11:48:07 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0AJnZEh022567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 11:49:35 -0800 (PST) Message-ID: <4D2B62CF.7040307@isi.edu> Date: Mon, 10 Jan 2011 11:49:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> In-Reply-To: <4D2B602E.1060408@gont.com.ar> 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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:48:08 -0000 On 1/10/2011 11:38 AM, Fernando Gont wrote: > Hi, Joe, > > On 10/01/2011 04:09 p.m., Joe Touch wrote: >> IMO, this might be ready for experimental, but shouldn't go >> standards-track unless it uses an algorithm for which we have >> substantial experience. > > Yes, I'll be backing out SHA-256 and will go back to recommending MD5. > -- As already noted on this list, this change was political rather than > technical. > > So I assume that this would address your concern and you'd be game for > std track, right? The specification of the PRF needs to be more detailed. I.e., state how the hash is padded, byte order, and what portion of the output you're using (since MD5 hashes are too long). >> 1) is this the most important change we want to make to TCP >> >> as a WG, we ought to be discussing this for >> every standards-track change to TCP; we don't seem >> to be doing this as a plan > > huh? Why should this be "the most important change to TCP" for us to > work on it? This is a general question; we don't want to be spending cycles around the edges if we have bigger fish to fry. >> 2) the discussion of how this doc changes 1948 needs to be included in >> the core of the doc (Sec 2, IMO), and needs to be updated > > No problem with this -- what do others think? > > > >> - this is a new algorithm, which, IMO, is experimental at best >> the alg proposed in Sec 2 is predictable for a given socket >> pair; that seems inconsistent with the security concerns that >> drive this doc > > Joe, this document is about mitigating blind attacks. If you know the > socket pair, you can predict the ISN, unless you were able to see the > ISN of a previous connection for that socket pair -- which is a > completely different threat-model, that this document does not (and > doesn't aim to) address. If knowing the socket pair means you can predict the ISN, then this doc shouldn't be discussing the need for a random component or the time value. I.e., your response above is inconsistent with a LOT of the discussion in this doc. >> - security concerns with MD5 need to be cited; the current >> note cites the definition of MD5 only; it's not clear >> they apply for unkeyed use as just a hash function > > The I-D cited by Lloyd will be referenced in the next revision. > > > >> - the impact of guessing a sequence number should be discussed >> better; as per 4953, increasing window sizes and link speeds >> means that knowing ISN value isn't as important as it once was > > Guessing the ISN is still as important as it was when it comes to > connection spoofing (note that most of the discussion is about > connection spoofing and trust relationship exploitation). > > We could possibly add an informative reference to RFC 4953 for other > sequence number issues. > > >> 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed >> >> most machines simply don't keep TW around as long as they >> are required; they also sometimes use a single pseudo-random >> generator across all connections; this needs to be considered >> in more detail > > So now you care about running code? -- It's surprising that you're > raising this, instead of declaring them as bugs and be done with it. I'm concerned about the performance impact of declaring this a SHOULD. > Anyway, this document is not about the TIME-WAIT state. And proper > references are included where appropriate (e.g., the reference to the > CPNI TCP security document) If the result of this SHOULD impacts TW performance, then yes, it is about TW state. >> 3) the doc should discuss how it can be implemented on a machine that >> doesn't know absolute time >> even TCP's timestamps don't need to be absolute, but if a >> machine always boots the same way with the same info, it >> will reuse sequence numbers unless it has a persistent clock, >> coordinates time with another party, or has persistent state; >> none of these are necessarily true, e.g., for small devices > > C'mon, Joe: initialize that timer to a random value, and be done with it. Stand-alone boxes don't necessarily understand 'random' - if they reboot and execute the same code in the same order, their 'random' is deterministic. You need to address that. This relates to the other concerns about some TCP mods that require state in home routers - it's a valid concern. You're declaring a SHOULD; you need to explain what you assume is available. Joe >> 4) where true authentication is noted as an alternative, TCP-AO should >> be included, IMO > > No problem with this. Will do. > > Thanks, From fernando.gont.netbook.win@gmail.com Mon Jan 10 12:09:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB833A6B0A for ; Mon, 10 Jan 2011 12:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyJM5xdat-ME for ; Mon, 10 Jan 2011 12:09:07 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id 00D2C28C0FF for ; Mon, 10 Jan 2011 12:09:06 -0800 (PST) Received: by yxd5 with SMTP id 5so4345798yxd.1 for ; Mon, 10 Jan 2011 12:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=cY4BUZvd1pRkwhxp60mdKMAyvMo1eSLa8hGmKEVKt0o=; b=JwXDHL4sI38iJkNeX53BoqokzJJuqhocM9AZR5EOT1jezbRAmic8lCfZEwFfl8U8fx I6z4upgEismXf5to5irMt4OwgGqocp07i6XpVxB3wlWXiGrDYQlst+V3yX0ncLx1T4fO au8ij6Dpfz4AfZO4E9x1csJ+ZR9+Oyg8YhcA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=CUJ5QpZ2d3aNr58DAEFlDFFQz3Q2oHuVltmJxzz/GMbL2Jj5YqKc6Y6Ekyy+E9JL7U PqGNgcJY1hoLR1YXuuDAUDHQPiUFEkb5QzByIYQyjhxXFtA8Jpuz2eDYEeUlpuLbB7bS wZcmItSoQNHs92mR4c3EfEF+yZKQbfpaQyaAU= Received: by 10.91.27.24 with SMTP id e24mr6624046agj.164.1294690281290; Mon, 10 Jan 2011 12:11:21 -0800 (PST) Received: from [192.168.2.4] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id c7sm37961393ana.37.2011.01.10.12.11.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 12:11:20 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B67E0.5020007@gont.com.ar> Date: Mon, 10 Jan 2011 17:11:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> In-Reply-To: <4D2B62CF.7040307@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:09:08 -0000 Hi, Joe, >> Yes, I'll be backing out SHA-256 and will go back to recommending MD5. >> -- As already noted on this list, this change was political rather than >> technical. >> >> So I assume that this would address your concern and you'd be game for >> std track, right? > > The specification of the PRF needs to be more detailed. I.e., state how > the hash is padded, byte order, and what portion of the output you're > using (since MD5 hashes are too long). How come that you don't deem this one as an implementation detail that should not concern us? >>> - this is a new algorithm, which, IMO, is experimental at best >>> the alg proposed in Sec 2 is predictable for a given socket >>> pair; that seems inconsistent with the security concerns that >>> drive this doc >> >> Joe, this document is about mitigating blind attacks. If you know the >> socket pair, you can predict the ISN, unless you were able to see the >> ISN of a previous connection for that socket pair -- which is a >> completely different threat-model, that this document does not (and >> doesn't aim to) address. > > If knowing the socket pair means you can predict the ISN, then this doc > shouldn't be discussing the need for a random component or the time value. Sorry, let me rephrase: With the proposed algorithm, you can only predict an ISN if you know the socket pair *and* you know the ISN of a previous connection between the source host and the destination endpoint. -- But this is *intentional*. -- We do want the ISNs to be monotonically increasing across connections -- hence the predictability to an *on* *path* attacker. >>> 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed >>> >>> most machines simply don't keep TW around as long as they >>> are required; they also sometimes use a single pseudo-random >>> generator across all connections; this needs to be considered >>> in more detail >> >> So now you care about running code? -- It's surprising that you're >> raising this, instead of declaring them as bugs and be done with it. > > I'm concerned about the performance impact of declaring this a SHOULD. It's a SHOULD not a MUST. So, if anything "what are the reasons for not implementing this? -- Performance"? >> Anyway, this document is not about the TIME-WAIT state. And proper >> references are included where appropriate (e.g., the reference to the >> CPNI TCP security document) > > If the result of this SHOULD impacts TW performance, then yes, it is > about TW state. Can you clearly state what your concern is? -- I just don't follow. And... What does RFC 1948 have to do with TIME-WAIT performance? >>> 3) the doc should discuss how it can be implemented on a machine that >>> doesn't know absolute time >>> even TCP's timestamps don't need to be absolute, but if a >>> machine always boots the same way with the same info, it >>> will reuse sequence numbers unless it has a persistent clock, >>> coordinates time with another party, or has persistent state; >>> none of these are necessarily true, e.g., for small devices >> >> C'mon, Joe: initialize that timer to a random value, and be done with it. > > Stand-alone boxes don't necessarily understand 'random' - if they reboot > and execute the same code in the same order, their 'random' is > deterministic. You need to address that. This relates to the other > concerns about some TCP mods that require state in home routers - it's a > valid concern. You're declaring a SHOULD; you need to explain what you > assume is available. Ok, my proposed text would be: "This specification assumes the host supports a random() function that provides random numbers as in, e.g. ISO C random() function." If you have anything better, please post it. That aside: What would be your concern about the node re-using the same ISNs? (even assuming connections are established at the same time since the node was bootstrapped... because you're assuming this, right?) -- Would an off-path attacker be able to predict them? And, if not, why are you still concerned about it? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jan 10 13:09:36 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F203A67B2 for ; Mon, 10 Jan 2011 13:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9mTn234MoWK for ; Mon, 10 Jan 2011 13:09:34 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id CAAFB3A67A8 for ; Mon, 10 Jan 2011 13:09:34 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0ALBJio008018 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 13:11:19 -0800 (PST) Message-ID: <4D2B75F7.60802@isi.edu> Date: Mon, 10 Jan 2011 13:11:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B67E0.5020007@gont.com.ar> In-Reply-To: <4D2B67E0.5020007@gont.com.ar> 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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:09:36 -0000 On 1/10/2011 12:11 PM, Fernando Gont wrote: > Hi, Joe, > >>> Yes, I'll be backing out SHA-256 and will go back to recommending MD5. >>> -- As already noted on this list, this change was political rather than >>> technical. >>> >>> So I assume that this would address your concern and you'd be game for >>> std track, right? >> >> The specification of the PRF needs to be more detailed. I.e., state how >> the hash is padded, byte order, and what portion of the output you're >> using (since MD5 hashes are too long). > > How come that you don't deem this one as an implementation detail that > should not concern us? The question is really "what is this document requiring". Is your intent to say "use MD5", and figure the rest our yourself? If so, why bother using the "+" operator, or putting the time value outside the hash? Either such details matter or they don't; if they don't, you need to explain why they don't. You don't *need* to spec it out to the bit level if that doesn't matter, but you do need to explain why you spec out some parts and not others. >>>> - this is a new algorithm, which, IMO, is experimental at best >>>> the alg proposed in Sec 2 is predictable for a given socket >>>> pair; that seems inconsistent with the security concerns that >>>> drive this doc >>> >>> Joe, this document is about mitigating blind attacks. If you know the >>> socket pair, you can predict the ISN, unless you were able to see the >>> ISN of a previous connection for that socket pair -- which is a >>> completely different threat-model, that this document does not (and >>> doesn't aim to) address. >> >> If knowing the socket pair means you can predict the ISN, then this doc >> shouldn't be discussing the need for a random component or the time value. > > Sorry, let me rephrase: With the proposed algorithm, you can only > predict an ISN if you know the socket pair *and* you know the ISN of a > previous connection between the source host and the destination > endpoint. -- But this is *intentional*. > > -- We do want the ISNs to be monotonically increasing across connections The alg you gave is monotonically increasing across connections within a socket pair. Presumably that's what you mean, right? > -- hence the predictability to an *on* *path* attacker. > > >>>> 2) the impact of this doc on TIME_WAIT isn't sufficiently addressed >>>> >>>> most machines simply don't keep TW around as long as they >>>> are required; they also sometimes use a single pseudo-random >>>> generator across all connections; this needs to be considered >>>> in more detail >>> >>> So now you care about running code? -- It's surprising that you're >>> raising this, instead of declaring them as bugs and be done with it. >> >> I'm concerned about the performance impact of declaring this a SHOULD. > > It's a SHOULD not a MUST. So, if anything "what are the reasons for not > implementing this? -- Performance"? 1) per-connection computational overhead 2) the need to retain per-socketpair state for TW (vs., e.g., some *known* implementations that do otherwise to reduce the state needed to avoid TW reuse). >>> Anyway, this document is not about the TIME-WAIT state. And proper >>> references are included where appropriate (e.g., the reference to the >>> CPNI TCP security document) >> >> If the result of this SHOULD impacts TW performance, then yes, it is >> about TW state. > > Can you clearly state what your concern is? -- I just don't follow. > > And... What does RFC 1948 have to do with TIME-WAIT performance? If you generate ISNs that are monotonic within a socket pair, but are otherwise arbitrary across different socket pairs, you NEED to keep the TWs per socket pair. If you want to keep less TW state, you can use a different mechanism. >>>> 3) the doc should discuss how it can be implemented on a machine that >>>> doesn't know absolute time >>>> even TCP's timestamps don't need to be absolute, but if a >>>> machine always boots the same way with the same info, it >>>> will reuse sequence numbers unless it has a persistent clock, >>>> coordinates time with another party, or has persistent state; >>>> none of these are necessarily true, e.g., for small devices >>> >>> C'mon, Joe: initialize that timer to a random value, and be done with it. >> >> Stand-alone boxes don't necessarily understand 'random' - if they reboot >> and execute the same code in the same order, their 'random' is >> deterministic. You need to address that. This relates to the other >> concerns about some TCP mods that require state in home routers - it's a >> valid concern. You're declaring a SHOULD; you need to explain what you >> assume is available. > > Ok, my proposed text would be: > "This specification assumes the host supports a random() function that > provides random numbers as in, e.g. ISO C random() function." > > If you have anything better, please post it. The point is that some boxes that use that function will generate the same value upon reboot. The fact that neither you nor I have a solution to this is the point - your requirement is making an assumption which is not true. > That aside: What would be your concern about the node re-using the same > ISNs? (even assuming connections are established at the same time since > the node was bootstrapped... because you're assuming this, right?) -- > Would an off-path attacker be able to predict them? And, if not, why are > you still concerned about it? You need to address what your algorithm requires and what it does not. If you can demonstrate that there's no ill effect, then you can explain that, e.g., you DON'T really need the random call. Joe From william.allen.simpson@gmail.com Mon Jan 10 13:15:35 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB813A67B4 for ; Mon, 10 Jan 2011 13:15:35 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6GRq6mS8OoN for ; Mon, 10 Jan 2011 13:15:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7161E3A67A8 for ; Mon, 10 Jan 2011 13:15:34 -0800 (PST) Received: by iyi42 with SMTP id 42so19788300iyi.31 for ; Mon, 10 Jan 2011 13:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VvX1Gn0mAKsda26HsSOZ/nbqJZxRz2DSWFfSjmQesWA=; b=MvUvn7ELp0ewFRQDQPEA6oWHas7maqP6/ze1qUW+YPnYhGiuuHwfOzdV/g41J6rTEO qwViOX960CxADUP5ocIXg2PPZ+S/XG8ktpW1ZKWqVgXElNSikE36sqIoBcvg/nqTiBYO KovDfdvN/lzA0vKx6UeljznLsCVFLVaJmqKeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ub6JrPpXfk3mE41+CH0KwhL7sE7/xvH88vmkhxtVId6cxvy7iTzX7PGTazySvrDCp9 d5lSE4qqLgtNm2F5gEMkK5JY00CqJoHnrohPgdnMynltDN9uZtlJql4J3MLa6JIMjwR5 j4z/OISpkoKLVFvP+h74ATKEPQ+tDDZjzmqTc= Received: by 10.231.39.74 with SMTP id f10mr8389664ibe.84.1294694269012; Mon, 10 Jan 2011 13:17:49 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id z4sm26606697ibg.19.2011.01.10.13.17.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 13:17:47 -0800 (PST) Message-ID: <4D2B7779.40400@gmail.com> Date: Mon, 10 Jan 2011 16:17:45 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> In-Reply-To: <4D2B62CF.7040307@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:15:35 -0000 On 1/10/11 2:49 PM, Joe Touch wrote: > The specification of the PRF needs to be more detailed. I.e., state how the hash is padded, byte order, and what portion of the output you're using (since MD5 hashes are too long). > Strongly disagree! The standard should only be that a PRF is used. There are no interoperability requirements. Moreover, we'd endlessly spin our wheels needlessly arguing about these insignificant details. In code I was writing not that long ago, I used part of the hash for the ISN, and part for the timestamp, and part for the cookie. There were plenty of bits to go around. > This is a general question; we don't want to be spending cycles around the edges if we have bigger fish to fry. > Oh humbug. These are all drafts concerning things we've known need to be updated for TCP for 15+ years. Heck, a draft by a WG co-chair is 4 years old, and still not finished (and I'd place that one at the top). Kudos to Gont for being willing to do the work -- and dodge the bullets. >>> 2) the discussion of how this doc changes 1948 needs to be included in >>> the core of the doc (Sec 2, IMO), and needs to be updated >> >> No problem with this -- what do others think? >> Change discussions should be nearest the end of the document, not the core. > I'm concerned about the performance impact of declaring this a SHOULD. > I'm not. We've been using high performance MD5 for such things since the days of 186s in a cell phone. I think it should be a MUST! From touch@isi.edu Mon Jan 10 13:26:27 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B023A6816 for ; Mon, 10 Jan 2011 13:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssgKT3-DYofx for ; Mon, 10 Jan 2011 13:26:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 856273A6812 for ; Mon, 10 Jan 2011 13:26:26 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0ALS7jo011009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 13:28:07 -0800 (PST) Message-ID: <4D2B79E6.5060201@isi.edu> Date: Mon, 10 Jan 2011 13:28:06 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: William Allen Simpson References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B7779.40400@gmail.com> In-Reply-To: <4D2B7779.40400@gmail.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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:26:27 -0000 On 1/10/2011 1:17 PM, William Allen Simpson wrote: >> I'm concerned about the performance impact of declaring this a SHOULD. >> > I'm not. We've been using high performance MD5 for such things since the > days of 186s in a cell phone. I think it should be a MUST! The performance impact isn't just computational, FWIW. It's also state. We had been discussing before on this list that some implementations don't keep TWs around; they just keep the first/last in a list, assuming that TWs are monotonic. If that's now monotonic within only a single socket pair, it increases the state needed to avoid socket reuse during TW. That's the non-computational performance impact... Also, when we talk about performance, we consider not just how fast a cellphone can compute the sum, but how many connections/sec a CPU can support; putting MD5 in the path will cut that down quite a bit. Joe From fernando.gont.netbook.win@gmail.com Mon Jan 10 15:34:21 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F99F3A67B2 for ; Mon, 10 Jan 2011 15:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA3DtVRZL9md for ; Mon, 10 Jan 2011 15:34:20 -0800 (PST) Received: from mail-yw0-f66.google.com (mail-yw0-f66.google.com [209.85.213.66]) by core3.amsl.com (Postfix) with ESMTP id DAE133A67AE for ; Mon, 10 Jan 2011 15:34:19 -0800 (PST) Received: by ywi6 with SMTP id 6so4378363ywi.1 for ; Mon, 10 Jan 2011 15:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=HiVeB6DhRaEHMPtX4DuHeLxqSw+ByhWuGwaPUAcyHCQ=; b=uRHl6a4XGQQ7/XiUosLrPv7LKnAFCTeHQjo/fv8/QNqbnsDgTpLLc4ERM7Ult/mfJX REB4c5dzkdMp0fxEflyMHWhEQUOTA1qiKfDjfsbfgo6RVApWluEfH7rU90jETLpBvA8g sOB9Xeex4FvW6xgSYpba+QLagNBQtxjUBCgQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Q97oZU/+iO9zVaCljvpadMoFdZ1WWSu78Rq1jUgqPFH0DL0S8x3qUy2dhu5BtdHTBB l6GQ0JNtlwWK/WbWl4pTSXFxwGCbh+tfWDl+xTkq8dHXi8PymUuSQYYh0kacU1rvu+1l PFc+sr3OrCKND3XYIx/JbReWi9aPHK1F6r+Ks= Received: by 10.150.148.20 with SMTP id v20mr29605221ybd.248.1294702586438; Mon, 10 Jan 2011 15:36:26 -0800 (PST) Received: from [192.168.2.5] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id v8sm17558660yhg.40.2011.01.10.15.36.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:36:25 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B9514.7070502@gont.com.ar> Date: Mon, 10 Jan 2011 20:24:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B67E0.5020007@gont.com.ar> <4D2B75F7.60802@isi.edu> In-Reply-To: <4D2B75F7.60802@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:34:21 -0000 Joe, On 10/01/2011 06:11 p.m., Joe Touch wrote: >>> The specification of the PRF needs to be more detailed. I.e., state how >>> the hash is padded, byte order, and what portion of the output you're >>> using (since MD5 hashes are too long). >> >> How come that you don't deem this one as an implementation detail that >> should not concern us? > > The question is really "what is this document requiring". > > Is your intent to say "use MD5", and figure the rest our yourself? MD5 would be a good choice. But if you want to use something else, that's still fine. > If so, why bother using the "+" operator, or putting the time value > outside the hash? Joe, please read the I-D. The time value is put outside the hash such that the ISNs increase over time. >> -- We do want the ISNs to be monotonically increasing across connections > > The alg you gave is monotonically increasing across connections within a > socket pair. Presumably that's what you mean, right? Yes. >> It's a SHOULD not a MUST. So, if anything "what are the reasons for not >> implementing this? -- Performance"? > > 1) per-connection computational overhead > > 2) the need to retain per-socketpair state for TW (vs., e.g., some > *known* implementations that do otherwise to reduce the state needed to > avoid TW reuse). I don't know what you're talking about. What's the increased state that you'd need to retain if you implement this algorithm. The algorithm is *stateless*! (apart from the global counter). >>>> Anyway, this document is not about the TIME-WAIT state. And proper >>>> references are included where appropriate (e.g., the reference to the >>>> CPNI TCP security document) >>> >>> If the result of this SHOULD impacts TW performance, then yes, it is >>> about TW state. >> >> Can you clearly state what your concern is? -- I just don't follow. >> >> And... What does RFC 1948 have to do with TIME-WAIT performance? > > If you generate ISNs that are monotonic within a socket pair, but are > otherwise arbitrary across different socket pairs, you NEED to keep the > TWs per socket pair. If you want to keep less TW state, you can use a > different mechanism. Isn't keeping the socket in the TIME-WAIT state a requirement? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Mon Jan 10 15:34:41 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293EF3A67B2 for ; Mon, 10 Jan 2011 15:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGgCI-d-BYz7 for ; Mon, 10 Jan 2011 15:34:40 -0800 (PST) Received: from mail-gx0-f194.google.com (mail-gx0-f194.google.com [209.85.161.194]) by core3.amsl.com (Postfix) with ESMTP id 4C7DB3A67AE for ; Mon, 10 Jan 2011 15:34:40 -0800 (PST) Received: by gxk1 with SMTP id 1so4555945gxk.1 for ; Mon, 10 Jan 2011 15:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=l55JcsYA0RsGKLnNKIORLQpAZWuJ53/OX/Ja42YG8s4=; b=aKtYGmTwvEf1T/Z1K4cefkqjKu3s0dWNaTVX5Uiw9e6lmbIIayzmAxKCuDBsFg1YWy 4v1DlmVcSsJjtKXivYwtjKqOYSvk09RupIL5Vr2q/F2IArAp06e03Wk/E4V0hLJhU/qP F7uXfffM572eS1WGHKCOnfPIF+lbKf3QVJoF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=g2ICmFG5chQqOPcshnO6PUmxVEBffp8zHwtm/EikqCLhN1qixygFjMFRfZYZYUxW4R woGHRflyxFRuonYi4QhliHRFjG5Mpct/MReDY1TWYlShrD4IHTB+jDlbBps5sKvH673K w6RwlFG5E9C+5NgrizfsKNfa2gJTuINJo4zmk= Received: by 10.151.83.5 with SMTP id k5mr29106810ybl.58.1294702615099; Mon, 10 Jan 2011 15:36:55 -0800 (PST) Received: from [192.168.2.5] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id v6sm2460112ybk.20.2011.01.10.15.36.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:36:54 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B9646.1020607@gont.com.ar> Date: Mon, 10 Jan 2011 20:29:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B7779.40400@gmail.com> <4D2B79E6.5060201@isi.edu> In-Reply-To: <4D2B79E6.5060201@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: [tcpm] On the TMIE-WAIT state (was Re: Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:34:41 -0000 Joe, On 10/01/2011 06:28 p.m., Joe Touch wrote: > We had been discussing before on this list that some implementations > don't keep TWs around; they just keep the first/last in a list, assuming > that TWs are monotonic. Cane you clearly state: * How the aforementioned mechanism operates * What specific implementations you're referring to * What are the assumptions they make * Whether such assumptions are based on current requirements (IETF-wise) * Whether such assumptions are based on widely-deployed implementations (and if so, which ones) ? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jan 10 15:38:19 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19E63A67B2 for ; Mon, 10 Jan 2011 15:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcFFVw8AqMe8 for ; Mon, 10 Jan 2011 15:38:18 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C226F3A67D1 for ; Mon, 10 Jan 2011 15:38:18 -0800 (PST) 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 p0ANe13M011786 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 15:40:01 -0800 (PST) Message-ID: <4D2B98CF.3030904@isi.edu> Date: Mon, 10 Jan 2011 15:39:59 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B67E0.5020007@gont.com.ar> <4D2B75F7.60802@isi.edu> <4D2B9514.7070502@gont.com.ar> In-Reply-To: <4D2B9514.7070502@gont.com.ar> 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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:38:19 -0000 On 1/10/2011 3:24 PM, Fernando Gont wrote: > Joe, > > On 10/01/2011 06:11 p.m., Joe Touch wrote: >>>> The specification of the PRF needs to be more detailed. I.e., state how >>>> the hash is padded, byte order, and what portion of the output you're >>>> using (since MD5 hashes are too long). >>> >>> How come that you don't deem this one as an implementation detail that >>> should not concern us? >> >> The question is really "what is this document requiring". >> >> Is your intent to say "use MD5", and figure the rest our yourself? > > MD5 would be a good choice. But if you want to use something else, > that's still fine. It'd be useful to say that. >> If so, why bother using the "+" operator, or putting the time value >> outside the hash? > > Joe, please read the I-D. The time value is put outside the hash such > that the ISNs increase over time. I was being a bit sarcastic - sorry. My point was that there's a certain amount of specificity, and a certain amount of handwaving. It'd be useful to explain why the distinction more clearly (i.e., which parts can be varied, which don't matter). >>> -- We do want the ISNs to be monotonically increasing across connections >> >> The alg you gave is monotonically increasing across connections within a >> socket pair. Presumably that's what you mean, right? > > Yes. > > >>> It's a SHOULD not a MUST. So, if anything "what are the reasons for not >>> implementing this? -- Performance"? >> >> 1) per-connection computational overhead >> >> 2) the need to retain per-socketpair state for TW (vs., e.g., some >> *known* implementations that do otherwise to reduce the state needed to >> avoid TW reuse). > > I don't know what you're talking about. What's the increased state that > you'd need to retain if you implement this algorithm. If you implement ISN as a counter, you don't really need to keep TW. If you implement this, you do need to keep TW for each socket pair. > The algorithm is *stateless*! (apart from the global counter). It's the implication on how TW is kept that matters. >>>>> Anyway, this document is not about the TIME-WAIT state. And proper >>>>> references are included where appropriate (e.g., the reference to the >>>>> CPNI TCP security document) >>>> >>>> If the result of this SHOULD impacts TW performance, then yes, it is >>>> about TW state. >>> >>> Can you clearly state what your concern is? -- I just don't follow. >>> >>> And... What does RFC 1948 have to do with TIME-WAIT performance? >> >> If you generate ISNs that are monotonic within a socket pair, but are >> otherwise arbitrary across different socket pairs, you NEED to keep the >> TWs per socket pair. If you want to keep less TW state, you can use a >> different mechanism. > > Isn't keeping the socket in the TIME-WAIT state a requirement? Making sure the values are not repeated for 2MSL is the requirement; how they are kept is up to the implementation. Joe From fernando.gont.netbook.win@gmail.com Mon Jan 10 15:49:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743D13A67E4 for ; Mon, 10 Jan 2011 15:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTkACO-xTXKu for ; Mon, 10 Jan 2011 15:49:00 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id 853F13A67A4 for ; Mon, 10 Jan 2011 15:49:00 -0800 (PST) Received: by gyf1 with SMTP id 1so4256687gyf.1 for ; Mon, 10 Jan 2011 15:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=+Ozks74VIaX+oAlanJS/GAhSuHifl18YEUA3UCA3v8k=; b=JeWwYhMrDPspNPVG5IdleeViDyD7ssPMkyvffXf18YsozKvxsUzbDE1dmRPSGdcjD6 wVOcCKB3ocPyooHXQfaR7r/SUuTAakv4VcLb1N+NRvpYMh+9DA7yMb4IFUoVLPhd/29h ZqqV5D8j1LfoVVQ6f87YXt9IEQgPQnnlhs1Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ChVUv4RzYBo4tZnoDbQ8mHtevC9Z1YWvJrqket0sz//l3WWgEzPQjeJmNjRR0vMGUe I81xNhomEOECGXHQaAFJy0g0WIslgBAoNQUijQj3LUkJp9qCjDy31uY3kmJb0zPw72hX JrgVLOKIIhE4apPRnwfZB4csogb2z2PD6E/xY= Received: by 10.150.186.15 with SMTP id j15mr28898677ybf.395.1294703475222; Mon, 10 Jan 2011 15:51:15 -0800 (PST) Received: from [192.168.2.5] (138-83-231-201.fibertel.com.ar [201.231.83.138]) by mx.google.com with ESMTPS id r24sm2504998yba.18.2011.01.10.15.51.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:51:14 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2B9B69.70303@gont.com.ar> Date: Mon, 10 Jan 2011 20:51:05 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B67E0.5020007@gont.com.ar> <4D2B75F7.60802@isi.edu> <4D2B9514.7070502@gont.com.ar> <4D2B98CF.3030904@isi.edu> In-Reply-To: <4D2B98CF.3030904@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:49:01 -0000 On 10/01/2011 08:39 p.m., Joe Touch wrote: >> I don't know what you're talking about. What's the increased state that >> you'd need to retain if you implement this algorithm. > > If you implement ISN as a counter, you don't really need to keep TW. Sorry Joe: Is it me, or there is an explicit requirement in RFC 793 to keep the TCP in the TIME-WAIT state? > If > you implement this, you do need to keep TW for each socket pair. I think you're arguing about violating RFC 793. That aside, please respond to my questions (now on a separate thread) on the implementations you're referring to. >> Isn't keeping the socket in the TIME-WAIT state a requirement? > > Making sure the values are not repeated for 2MSL is the requirement; how > they are kept is up to the implementation. I see... So actual implementation of the TIME-WAIT state is up to the implementation? Which other states of TCP do you think we could get rid off? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Mon Jan 10 16:18:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1633A681E for ; Mon, 10 Jan 2011 16:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL36r90g3V6f for ; Mon, 10 Jan 2011 16:18:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8AC853A6819 for ; Mon, 10 Jan 2011 16:18:14 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0B0KMFT018153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 16:20:22 -0800 (PST) Message-ID: <4D2BA245.4050704@isi.edu> Date: Mon, 10 Jan 2011 16:20:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B67E0.5020007@gont.com.ar> <4D2B75F7.60802@isi.edu> <4D2B9514.7070502@gont.com.ar> <4D2B98CF.3030904@isi.edu> <4D2B9B69.70303@gont.com.ar> In-Reply-To: <4D2B9B69.70303@gont.com.ar> 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] Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:18:15 -0000 On 1/10/2011 3:51 PM, Fernando Gont wrote: > On 10/01/2011 08:39 p.m., Joe Touch wrote: > >>> I don't know what you're talking about. What's the increased state that >>> you'd need to retain if you implement this algorithm. >> >> If you implement ISN as a counter, you don't really need to keep TW. > > Sorry Joe: Is it me, or there is an explicit requirement in RFC 793 to > keep the TCP in the TIME-WAIT state? An implementation must act as if there is such a state. There is no requirement to how to achieve that behavior (or any other in 793). >> If >> you implement this, you do need to keep TW for each socket pair. > > I think you're arguing about violating RFC 793. No; I'm arguing there are several ways to support it. Some prohibit some new TCP connections that could have otherwise happened, at the benefit of keeping less state. That's an endpoints perogative. ... >>> Isn't keeping the socket in the TIME-WAIT state a requirement? >> >> Making sure the values are not repeated for 2MSL is the requirement; how >> they are kept is up to the implementation. > > I see... So actual implementation of the TIME-WAIT state is up to the > implementation? That is a tautology. Yes, to be explicit, it is. > Which other states of TCP do you think we could get rid off? Well, let's see - TCP cookies get rid of SYN-RECEIVED (there is no such internal state kept), but they end up acting as if it's kept. So are you now arguing that any implementation that uses cookies isn't implementing 793 at all? Joe From touch@isi.edu Mon Jan 10 16:24:20 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AFD3A67E9 for ; Mon, 10 Jan 2011 16:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW8rekRfK1Pe for ; Mon, 10 Jan 2011 16:24:19 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6A2D3A67B1 for ; Mon, 10 Jan 2011 16:24:19 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0B0PofO019109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 10 Jan 2011 16:25:51 -0800 (PST) Message-ID: <4D2BA38E.7010705@isi.edu> Date: Mon, 10 Jan 2011 16:25:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B7779.40400@gmail.com> <4D2B79E6.5060201@isi.edu> <4D2B9646.1020607@gont.com.ar> In-Reply-To: <4D2B9646.1020607@gont.com.ar> 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] On the TMIE-WAIT state (was Re: Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:24:20 -0000 On 1/10/2011 3:29 PM, Fernando Gont wrote: > Joe, > > On 10/01/2011 06:28 p.m., Joe Touch wrote: >> We had been discussing before on this list that some implementations >> don't keep TWs around; they just keep the first/last in a list, assuming >> that TWs are monotonic. > > Cane you clearly state: > > * How the aforementioned mechanism operates As a simple example consider outgoing source port numbers for connections you initiate, and don't reuse them for 2MSL. Generate the ISNs using a single global counter. Sure, it's not going to give you lots of connections, but you no longer need to keep TW for any outgoing connections. > * What specific implementations you're referring to They have been discussed on this list in the past when discussing other ways in which TW behaves. I don't recall which OS they are implemented in (likely things like home routers). > * What are the assumptions they make See above; most assume the overall connection rate is the limit, not per-socket pair. > * Whether such assumptions are based on current requirements (IETF-wise) > * Whether such assumptions are based on widely-deployed implementations > (and if so, which ones) I don't know how widely; the point is that the assumptions are consistent with current IETF requirements. I believe they were deployed, but have only the reports of others when discussing TW to go on for that. Joe From fernando.gont.netbook.win@gmail.com Mon Jan 10 18:12:52 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB0B28C0D9 for ; Mon, 10 Jan 2011 18:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+TWttUm1xd0 for ; Mon, 10 Jan 2011 18:12:51 -0800 (PST) Received: from mail-yw0-f66.google.com (mail-yw0-f66.google.com [209.85.213.66]) by core3.amsl.com (Postfix) with ESMTP id 309003A6931 for ; Mon, 10 Jan 2011 18:12:51 -0800 (PST) Received: by ywi6 with SMTP id 6so4398383ywi.1 for ; Mon, 10 Jan 2011 18:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=UsKgYFzsMaUfutn9DwUkk94e2rbtP/cawn6+CWm7++E=; b=f7hhDQouS2O2YKhPmjx9DDAM20P9YdAKx+LyUIKnB69oH1cgJQt2QATJ3xrZ3DsrmV LhSLMEep4E9voqhZcA9Z8wHopgfL8x5PZHbM8P1/LLGHBk5EyPrtLo8MjmLAycpJ2hg6 HV5YsZ7bZoxvqcyc60eFYxQYOQD1rg3cpRvrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=wCfdnqxxRDuYgjQf6FXRDPgXPyJWJc1rEI0nohbznixHOld9xncihOtoFwuopZg1zv 1imR2yTtmLkeCIN6s28FgtOEAr8Ummii6T21Bt4HQ8Kc2nPqs4/ZFuECd00pKC4ERyp3 YvMjo3D1cnmJVx3i0fCFfbgH8oG2z3QolPWEQ= Received: by 10.150.91.2 with SMTP id o2mr10778985ybb.122.1294712106151; Mon, 10 Jan 2011 18:15:06 -0800 (PST) Received: from [192.168.0.122] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id r41sm15131372yba.4.2011.01.10.18.15.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 18:15:05 -0800 (PST) Sender: Fernando Gont Message-ID: <4D2BBD1C.3030702@gont.com.ar> Date: Mon, 10 Jan 2011 23:14:52 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch References: <4D27A097.3040606@gont.com.ar> <4D2B5958.3090304@isi.edu> <4D2B602E.1060408@gont.com.ar> <4D2B62CF.7040307@isi.edu> <4D2B7779.40400@gmail.com> <4D2B79E6.5060201@isi.edu> <4D2B9646.1020607@gont.com.ar> <4D2BA38E.7010705@isi.edu> In-Reply-To: <4D2BA38E.7010705@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] On the TMIE-WAIT state (was Re: Fwd: New Version Notification for draft-gont-tcpm-rfc1948bis-00) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 02:12:52 -0000 On 10/01/2011 09:25 p.m., Joe Touch wrote: >> * How the aforementioned mechanism operates > > As a simple example consider outgoing source port numbers for > connections you initiate, and don't reuse them for 2MSL. Generate the > ISNs using a single global counter. Sure, it's not going to give you > lots of connections, but you no longer need to keep TW for any outgoing > connections. This is so broken that it probably does not even deserve discussion. So a server that needs to go into TIME-WAIT relies on a *client* for that???? How does your hypothetical server TCP implementation know how the client is going to behave? >> * What specific implementations you're referring to > > They have been discussed on this list in the past when discussing other > ways in which TW behaves. I don't recall which OS they are implemented > in (likely things like home routers). This is hand-waving. And, FWIW, many (most?) home routers these days are based on Linux. >> * What are the assumptions they make > > See above; most assume the overall connection rate is the limit, not > per-socket pair. This is flawed and broken. -- And IMO, unless you prove me wrong, not real. >> * Whether such assumptions are based on current requirements (IETF-wise) >> * Whether such assumptions are based on widely-deployed implementations >> (and if so, which ones) > > I don't know how widely; the point is that the assumptions are > consistent with current IETF requirements. Consistent with what? A server implements TIME-WAIT state by relying on a *client* not issuing connections at a high rate? And this also relies on global (and predictable) ISNs? (which are widely known to be insane) I'm done with this discussion, Joe. I have no more time to waste (nor do I want to waste the time of other participants). P.S.: If you get wg consensus on your view and proposed changes, I'll be happy to trash our I-D as indicated. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From wes@mti-systems.com Thu Jan 13 19:36:13 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF563A6830 for ; Thu, 13 Jan 2011 19:36:13 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot+DMQW0Eh45 for ; Thu, 13 Jan 2011 19:36:12 -0800 (PST) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by core3.amsl.com (Postfix) with ESMTP id 154E33A6818 for ; Thu, 13 Jan 2011 19:36:11 -0800 (PST) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0E3cZLe024942 for ; Thu, 13 Jan 2011 22:38:35 -0500 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.90.4] ([174.130.90.4:42890] helo=[192.168.1.104]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 69/9F-22185-B35CF2D4; Thu, 13 Jan 2011 22:38:35 -0500 Message-ID: <4D2FC53C.4030304@mti-systems.com> Date: Thu, 13 Jan 2011 22:38:36 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 03:36:13 -0000 Based on the discussion of section 7 (programming considerations), the document on clarifying the persist condition has been updated by the authors. The document can be found at: https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ We think this is ready for working group last call now, so with this email, I'd like to start a two-week WGLC on the document to last until 1/28. Please send your comments to the TCPM list by then. Thanks in advance. -- Wes Eddy MTI Systems From timothyhartrick@gmail.com Fri Jan 7 09:39:19 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA873A691D for ; Fri, 7 Jan 2011 09:39:19 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPNq65hGipjh for ; Fri, 7 Jan 2011 09:39:18 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C930B3A68C5 for ; Fri, 7 Jan 2011 09:39:18 -0800 (PST) Received: by iwn40 with SMTP id 40so18513290iwn.31 for ; Fri, 07 Jan 2011 09:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:reply-to:to:cc :in-reply-to:references:content-type:organization:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=QHVldoq1f603dBJjXyW76J0pyW93SqhnXW45O9nIHeI=; b=Z/pfauSyG23vRyYLdlhqxQ9sv0O15Sh6lubYnSkLn2vv/305kkcdln3O1ZcCaJc2uV vTy6J+SuOTgerFTPc8za13AAg78NbdFN1onDMfkXdP3bwheb5idwng7rEnCJbgYth9TA H0amKQD10imnCAd0ypcOa6cFVv3833I7z6vEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=YV2Q4Bx07fYp7+EjQBiV2Ux51XmBJUPqYd91suqxKuNC0EGKoA8Q0JAJzp+cqL8o/m Wdms+ua87FDxvv9jsn3VhFul3CoMcSp0Opo1I/iAo2VIoBOnpy1W2G3qWTL2ymik6mtw QpS4CNczFzorVmBKSmdg66bt24S6v/TOfn3YA= Received: by 10.42.171.137 with SMTP id j9mr1140423icz.232.1294422084769; Fri, 07 Jan 2011 09:41:24 -0800 (PST) Received: from [192.168.29.48] ([67.41.221.225]) by mx.google.com with ESMTPS id d21sm23157544ibg.15.2011.01.07.09.41.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 09:41:23 -0800 (PST) From: Tim Hartrick To: rick jones In-Reply-To: References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> Content-Type: text/plain; charset="UTF-8" Organization: Tim Hartrick Date: Fri, 07 Jan 2011 10:40:29 -0700 Message-ID: <1294422029.2314.0.camel@feller> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 (2.30.3-1.fc13) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 15 Jan 2011 18:27:20 -0800 Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: timothyhartrick@gmail.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:16:30 -0000 All, +1. Tim Hartrick On Fri, 2011-01-07 at 08:23 -0800, rick jones wrote: > On Jan 6, 2011, at 10:19 AM, Mark Allman wrote: > > So, do you prefer ... > > > > (A) To increase the current static IW definition to a single updated > > value. > > > > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > > explicitly not asking about IW=10, just IW=some_X.) > > A. > > Paint it yellow and ship it. (*) > > rick jones > > (*) http://greateasyjet.com/funny/paint_yellow.html > > http://homepage.mac.com/perfgeek > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Sun Jan 16 12:55:51 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BEE3A6E5B for ; Sun, 16 Jan 2011 12:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgO0SfFCDaTF for ; Sun, 16 Jan 2011 12:55:49 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 6A5923A6E5A for ; Sun, 16 Jan 2011 12:55:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,330,1291622400"; d="scan'208";a="234776170" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 16 Jan 2011 12:58:21 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0GKwJp8021569; Sun, 16 Jan 2011 12:58:19 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 16 Jan 2011 20:58:19 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Jan 2011 20:58:18 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C5BB9EE@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <1294422029.2314.0.camel@feller> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] informal poll about initial cwnd Thread-Index: Acu1JUV8+xpzbTmISAKIbFCOMsgqnQAmsYlg References: <20110106181946.F0ECD2A38D2A@lawyers.icir.org> <1294422029.2314.0.camel@feller> From: "Scheffenegger, Richard" To: , "rick jones" X-OriginalArrivalTime: 16 Jan 2011 20:58:19.0297 (UTC) FILETIME=[1A7D7910:01CBB5C0] Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] informal poll about initial cwnd X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 20:55:51 -0000 +1 (reasons mentioned earlier). Richard > -----Original Message----- > From: Tim Hartrick [mailto:timothyhartrick@gmail.com] > Sent: Freitag, 07. J=E4nner 2011 18:40 > To: rick jones > Cc: tcpm@ietf.org; mallman@icir.org > Subject: Re: [tcpm] informal poll about initial cwnd >=20 >=20 >=20 > All, >=20 > +1. >=20 >=20 > Tim Hartrick >=20 > On Fri, 2011-01-07 at 08:23 -0800, rick jones wrote: > > On Jan 6, 2011, at 10:19 AM, Mark Allman wrote: > > > So, do you prefer ... > > > > > > (A) To increase the current static IW definition to a single > updated > > > value. > > > > > > (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am > > > explicitly not asking about IW=3D10, just IW=3Dsome_X.) > > > > A. > > > > Paint it yellow and ship it. (*) > > > > rick jones > > > > (*) http://greateasyjet.com/funny/paint_yellow.html > > > > http://homepage.mac.com/perfgeek > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Mon Jan 17 05:45:58 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEDE3A6F27 for ; Mon, 17 Jan 2011 05:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.339 X-Spam-Level: X-Spam-Status: No, score=-8.339 tagged_above=-999 required=5 tests=[AWL=-1.706, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE6E4-zP+uoi for ; Mon, 17 Jan 2011 05:45:56 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D59493A6CAA for ; Mon, 17 Jan 2011 05:45:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,333,1291622400"; d="scan'208";a="234861846" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 17 Jan 2011 05:48:28 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0HDmQ9W026354; Mon, 17 Jan 2011 05:48:26 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Jan 2011 13:48:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 13:48:22 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] RTTM + timestamps Thread-Index: Acuw86lm0NT7H57wQhaXrheqf3sEDwFOzq6g References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Scheffenegger, Richard" , , , X-OriginalArrivalTime: 17 Jan 2011 13:48:26.0665 (UTC) FILETIME=[374BE990:01CBB64D] Cc: Matt Mathis , Mark Allman Subject: Re: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:45:58 -0000 Hi group, After having received some feedback off-list so far, I would like to = summarize what I learned so far. Also, I invite everyone to discuss = these points. There are benefits for the research community both = empirical as well as theoretical, as well as mobile and high-speed = network operators and implementers. =20 o) one-way delay based (and delay variation based) congestion controls = would benefit from knowing the clock resolution on both sides. Some = research in that area is done by Mirja Kuehlewind and Bob Briscoe = (http://bobbriscoe.net/pubs.html#chirp_impl), as well as David Hayes = (http://caia.swin.edu.au/reports/100219A/CAIA-TR-100219A.pdf) o) RTT variance during loss episodes is not deeply researched. Current = heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) explicitly = exclude (and prevent) the use of RTT samples when loss occurs. However, = solving the retransmission ambiguity problem - and the related reliable = ACK delivery problem - may allow the refinement of these algorithms = further, as well as enabling new research to distinguish between = corruption loss (without RTT / one-way delay impact) and congestion loss = (with RTT / one-way delay impact). This appears to be a rather neglected = field however, especially when it comes to large scale, public internet = investigations. Due to the very nature of this, passive investigations = without signals contained within the headers are only of limited use in = empirical research here. o) A side-effect of Van Jacobson's algorithm is that RTO spikes when the = path RTT suddenly drops. With the decrease of the path RTT, the variance = grows. As the variance has a large effect on the calculated RTO, this = leads to potentially very lengthy timeouts even though the RTT is much = shorter. This particular problem has been addressed in some stacks, and = the lessons learned from the deployment there could be used to update = the RTO calculation specs.=20 o) Enabling of spurious RTO detection (Eifel, D-SACK, F-RTO) in the last = years also make it possible to dynamically identify instances when the = RTT estimation or RTO calculation where mislead, allowing to use a more = conservative algorithm for certain paths / times. o) Retransmission ambiguity detection during loss recovery would allow = an additional level of loss recovery control without reverting to = timer-based methods. As with the deployment of SACK, separating "what" = to send from "when" to send it could be driven one step further. In = particular, less conservative loss recovery schemes which do not trade = principles of packet conservation against timeliness, require a reliable = way of prompt and best possible feedback from the receiver about any = delivered segment and their ordering. SACK alone goes quite a long way, = but using Timestamp information in addition could remove any ambiguity. = However, the current specs in RFC1323 make that use impossible, thus a = modified signaling (receiver behavior) is a necessity. The first central aspect of the above mentioned points is to resolve the = retransmission ambiguity, and the second to give the end host a better = understanding of their respective partners behavior. I strongly believe that much about the retransmission ambiguity can be = solved by exploiting synergistic signaling between the TCP SACK option = and Timestamp option. In particular, the receiver-side state required by = RFC1323 to choose which Timestamp to reflect when a non-contiguous = segment is received could be alleviated, when the TCP session is also = using SACK. (The presence of a SACK field indicates some out of sequence = delivery. The current stipulations were made, afaik, to ensure that no = unduly small RTT sample is entered into the RTO calculation, when ACK = loss occurs. But again, SACK disambiguates between a in-sequence ACK, = and a duplicate ACK). For the second aspect, the single most important aspect to convey would = be the tcp clock resolution. For this, no signaling exists yet. However, = there appears to be a downward-compatible method to extend the Timestamp = SYN option, to include this signal. According to RFC1323, TSecr is unused in the SYN segment, and most = stacks appear to ignore that value. An enhanced signaling could set this = initial TSecr field. To convey some feedback from the receiver to the = sender in the SYN|ACK, while maintaining compatibility with stacks that = do not evaluate the contents of this SYN TSecr, a simple XOR between the = SYN|TSopt field and the clients respective settings could be employed. The sender would compare the TSecr value in the SYN|ACK with it's = initial sent TSval, and if they are identical, conclude to deal with an = unenhanced client (no SACK+TS synergy, no one-way delay/variance CC). If = the TSecr in the SYN|ACK would be different, the negotiated heuristics = can be enabled for that TCP session - decoded by an XOR from the = original TSval.=20 SYN: +-------+-------+---------------------+---------------------+ |Kind=3D8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| +-------+-------+---------------------+---------------------+ 1 1 4 4 With TSecr containing, ie. A 16-bit Flag field plus a 16-bit IEEE float = indicating the TCP clock resolution (duration or frequency), or a 8-bit = Flag field plus two 12-bit floats for negotiation of an acceptable clock = range. Also, perhaps a CIDR-like prefix bitstring may be of interest for = future extensions, ie: 1 1 x x x - future 1 0 1 x x - use 2x12 bit floats 1 0 0 1 x - use 1x16 bit float A few potentially meaningful flag bits discussed so far could be TS-extension flag (always set; this limits the senders initial TS = selection...) Reserved TS-negotiate range (w/ 2x 12bit floats) TS-fixed rate (w/ 16bit float) Modified exponent offset (-21 instead of -15, for very high speed = networks) SACK+TS synergy (always reflect TS of last received segment) High-Precision (use HW late in data path for TS insertion, = exclude much jitter) =20 Note that binary16 allows a dynamic range (with some lost precision) = from 2^15 down to 2^-24, while a 12-bit representation, omitting sign = and most significant exponent bit, plus least two significant fraction = bits, would still allow a range between 2^0 to 2^-22.=20 Binary16: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |Si| Exponent | Fraction | |gn|offset shifted| | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 12-bit subsample: +--+--+--+--+--+--+--+--+--+--+--+--+ | exponent | fraction | +--+--+--+--+--+--+--+--+--+--+--+--+ =20 However even this dynamic range may not be enough to allow a tcp clock = to run at the sending rate of minimal IP frames at very high (100 = Gbit/s, 1Tbit/s) speeds. Using a different exponent offset shift, and = omitting one additional fraction bit instead of one exponent bit in the = 12 bit value should be discussed. +--+--+--+--+--+--+--+--+--+--+--+--+ | exponent | fraction | +--+--+--+--+--+--+--+--+--+--+--+--+ =20 From: Scheffenegger, Richard=20 Sent: Montag, 10. J=E4nner 2011 19:25 To: tcpm@ietf.org; iccrg@cs.ucl.ac.uk Subject: [tcpm] RTTM + timestamps Hi group, in order not to spam the whole group, I would like to learn who is = interested in the heuristics and signaling around round-trip = measurement, timestamps and possible synergies between TS and other = option, as well as some empirical measurements around currently deployed = tcp stacks that diverge from the IETF specs in these aspects. In the light of some recent developments (ie. LEDBAT, path-chirp/chirp = CC), and more efficient (end-of-flow / non-congestion) loss recovery, = improvements in that space may be of interest to a larger group of = implementers too... With your feedback, I would like to learn the extent of possible = interest, before going further with my work in that area! Best regards, Richard Scheffenegger From alexander.zimmermann@comsys.rwth-aachen.de Mon Jan 17 06:32:48 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D168828C0F8 for ; Mon, 17 Jan 2011 06:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.67 X-Spam-Level: X-Spam-Status: No, score=-4.67 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gEIW9GezoEd for ; Mon, 17 Jan 2011 06:32:44 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 41EF428C0F0 for ; Mon, 17 Jan 2011 06:32:43 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LF6001D38ITUQC0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 17 Jan 2011 15:35:17 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,333,1291590000"; d="sig'?scan'208";a="88996967" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 17 Jan 2011 15:35:17 +0100 Received: from [137.226.12.53] ([unknown] [137.226.12.53]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LF6003018ITNSB0@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 17 Jan 2011 15:35:17 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-6--859863766 From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> Date: Mon, 17 Jan 2011 15:35:15 +0100 Content-transfer-encoding: 7bit Message-id: <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk, end2end-interest@postel.org, Mark Allman , Matt Mathis Subject: Re: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:32:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6--859863766 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard, some rash thoughts... Am 17.01.2011 um 14:48 schrieb Scheffenegger, Richard: > Hi group, >=20 > After having received some feedback off-list so far, I would like to = summarize what I learned so far. Also, I invite everyone to discuss = these points. There are benefits for the research community both = empirical as well as theoretical, as well as mobile and high-speed = network operators and implementers. >=20 >=20 > o) one-way delay based (and delay variation based) congestion controls = would benefit from knowing the clock resolution on both sides. Some = research in that area is done by Mirja Kuehlewind and Bob Briscoe = (http://bobbriscoe.net/pubs.html#chirp_impl), as well as David Hayes = (http://caia.swin.edu.au/reports/100219A/CAIA-TR-100219A.pdf) >=20 > o) RTT variance during loss episodes is not deeply researched. Current = heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) explicitly = exclude (and prevent) the use of RTT samples when loss occurs. Eh... With RFC1323, you take RTT samples when loss occurs. > However, solving the retransmission ambiguity problem - The problem is solved, isn't it? Eifel? > and the related reliable ACK delivery problem - may allow the = refinement of these algorithms further, as well as enabling new research = to distinguish between corruption loss (without RTT / one-way delay = impact) and congestion loss (with RTT / one-way delay impact). This is not new. Ask Michael Welzl ;-) And a citation form Sally Floyd to that topic: "Inferring congestion vs. corruption at the transport level. There are = also papers that investigate algorithms for the transport end-nodes to infer that certain drops are = from corruption rather than congestion, without explicit feedback from routers. My own view would be = that the burden is on such approaches to show that they are not ignoring legitimate congestion = indications from the network." eg: S.Biaz and N. Vaidya. Discriminating Congestion Losses from Wireless = Losses Using Interarrival Times at the Receiver. IEEE Symposium on Application-Specific Systems = and Software Engineering and Technology, Mar 1999. > This appears to be a rather neglected field however, especially when = it comes to large scale, public internet investigations. Due to the very = nature of this, passive investigations without signals contained within = the headers are only of limited use in empirical research here. >=20 > o) A side-effect of Van Jacobson's algorithm is that RTO spikes when = the path RTT suddenly drops. With the decrease of the path RTT, the = variance grows. As the variance has a large effect on the calculated = RTO, this leads to potentially very lengthy timeouts even though the RTT = is much shorter. This particular problem has been addressed in some = stacks, and the lessons learned from the deployment there could be used = to update the RTO calculation specs. >=20 > o) Enabling of spurious RTO detection (Eifel, D-SACK, F-RTO) in the = last years also make it possible to dynamically identify instances when = the RTT estimation or RTO calculation where mislead, allowing to use a = more conservative algorithm for certain paths / times. >=20 > o) Retransmission ambiguity detection during loss recovery (what we already have) > would allow an additional level of loss recovery control without = reverting to timer-based methods. I don't get this point. > As with the deployment of SACK, separating "what" to send from "when" = to send it could be driven one step further. In particular, less = conservative loss recovery schemes which do not trade principles of = packet conservation against timeliness, require a reliable way of prompt = and best possible feedback from the receiver about any delivered segment = and their ordering. SACK alone goes quite a long way, but using = Timestamp information in addition could remove any ambiguity. Which ambiguity do you mean here? > However, the current specs in RFC1323 make that use impossible, thus a = modified signaling (receiver behavior) is a necessity. >=20 >=20 >=20 >=20 >=20 > The first central aspect of the above mentioned points is to resolve = the retransmission ambiguity Again, Eifel? > , and the second to give the end host a better understanding of their = respective partners behavior. >=20 > I strongly believe that much about the retransmission ambiguity can be = solved by exploiting synergistic signaling between the TCP SACK option = and Timestamp option. In particular, the receiver-side state required by = RFC1323 to choose which Timestamp to reflect when a non-contiguous = segment is received could be alleviated, when the TCP session is also = using SACK. (The presence of a SACK field indicates some out of sequence = delivery. The current stipulations were made, afaik, to ensure that no = unduly small RTT sample is entered into the RTO calculation, when ACK = loss occurs. But again, SACK disambiguates between a in-sequence ACK, = and a duplicate ACK). >=20 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-6--859863766 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk00U6QACgkQdyiq39b9uS6yjACgtEmxWVFe8Y/VxP0uVH8iy01+ jpEAnj9zkq2ubqT3gSgwkD0zn3LraFcI =r48k -----END PGP SIGNATURE----- --Apple-Mail-6--859863766-- From rs@netapp.com Mon Jan 17 07:46:07 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829F53A6D51 for ; Mon, 17 Jan 2011 07:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.959 X-Spam-Level: X-Spam-Status: No, score=-9.959 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-u70U59LY+c for ; Mon, 17 Jan 2011 07:46:06 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D4FB13A6D4E for ; Mon, 17 Jan 2011 07:46:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,333,1291622400"; d="scan'208";a="234885097" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 17 Jan 2011 07:48:39 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0HFmc8i019466; Mon, 17 Jan 2011 07:48:39 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Jan 2011 16:48:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 15:48:34 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C5BBF04@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] RTTM + timestamps Thread-Index: Acu2U9UVmNueUlS5R3C5adkHUBlrEwAByv3w References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <687258D3-D8AF-4F33-BACC-A6F0F8468E80@comsys.rwth-aachen.de> From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 17 Jan 2011 15:48:38.0761 (UTC) FILETIME=[020A6D90:01CBB65E] Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk, end2end-interest@postel.org, Mark Allman , Matt Mathis Subject: Re: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:46:07 -0000 HI Alex, > > o) RTT variance during loss episodes is not deeply researched. > > Current heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) > > explicitly exclude (and prevent) the use of RTT samples when loss > > occurs. >=20 > Eh... With RFC1323, you take RTT samples when loss occurs. True, but these samples are a worst-case upper bound, since the last in-sequence delivered segment - if you are running "stateless" on the sender. With a stateful sender, that keeps sending timestamps independent of the TS option, and matches the (S)ACKed packets to this (potentially very lengthy) list, you can - to some extent - circumvent this issue. However, it does not help you with re-retransmissions still. Probably my wording was poor, what I intended to say was to get the best possible RTT measurement with each delivered (and (S)ACKed) segment possible, without incurring undue overhead (state) in the sender. The deliberate withholding of TS info according to RFC1323 - in order to address the problem of unreliably delivered ACKs, and - at the time - non-availability of SACK, was what triggered this point. > > However, solving the retransmission ambiguity problem - >=20 > The problem is solved, isn't it? Eifel? Only for cumulative/partial ACKs, and only then in theory, because IPR restrictions prevent Eifel from being deployed in any commercial stack. (There is only a single OS compatible with the IPR requirements for all the Eifel algorithms). For segments that are delivered out-of-sequence, it still exists. >=20 > > and the related reliable ACK delivery problem - may allow the > refinement of these algorithms further, as well as enabling new > research to distinguish between corruption loss (without RTT / one-way > delay impact) and congestion loss (with RTT / one-way delay impact). >=20 > This is not new. Ask Michael Welzl ;-) >=20 > And a citation form Sally Floyd to that topic: >=20 > "Inferring congestion vs. corruption at the transport level. There are > also papers that investigate algorithms for the transport end-nodes to > infer that certain drops are from corruption rather than congestion, > without explicit feedback from routers. My own view would be that the > burden is on such approaches to show that they are not ignoring > legitimate congestion indications from the network." >=20 > eg: S.Biaz and N. Vaidya. Discriminating Congestion Losses from > Wireless Losses Using Interarrival Times at the Receiver. IEEE > Symposium on Application-Specific Systems and Software Engineering and > Technology, Mar 1999. Thanks for the reference! Still you need some way of getting most accurate RTT samples back to the sender, right? > > o) Retransmission ambiguity detection during loss recovery >=20 > (what we already have) Not really, you'll not get a lower TS back for a long delayed segment, which was already retransmitted; also, if the retransmitted segment is beyond some (still existing hole), Eifel + RFC1323 still fail to disambiguate between original and retransmitted segment, when it's delivered. >=20 > > would allow an additional level of loss recovery control without > reverting to timer-based methods. >=20 > I don't get this point. Ok, this revolves around lost retransmission detection at the end-of-stream / below RecoveryPoint. First, LRD is again not widely available (only one particular stack has that feature), nor officially specified. Second, it depends on the ack of a segment beyond recovery point to find that a retransmission was lost. However, if the sender can infer the exact ordering in which all the segements (original, retransmitted, reordered,...) were delivered to the client, it can make a more informed choice if one particular segement was lost (again), before going beyond RecoveryPoint (ie. Retransmit as soon as the segment re-transmitted (!) dupthresh segments later than the one in question, is received; For emphasis, I really mean the re-transmitted segment, not the the delivery of a delayed original segment (because that would be in indication, that there is a good chance of the still-lost segement to be delivered via a slower path; re-sending then would violate the packet conservation principle). >=20 > > As with the deployment of SACK, separating "what" to send from "when" > to send it could be driven one step further. In particular, less > conservative loss recovery schemes which do not trade principles of > packet conservation against timeliness, require a reliable way of > prompt and best possible feedback from the receiver about any delivered > segment and their ordering. SACK alone goes quite a long way, but using > Timestamp information in addition could remove any ambiguity. >=20 > Which ambiguity do you mean here? Hope I made this clear already: For out-of-sequence delivered, retransmitted segments. Under certain circumstances, the sender may re-transmit one segment more than twice, and it should be possible to discriminate between each individual instance of that segment by using SACK+TS information. I can send around a sketch of such a less-conservative SACK loss recovery scheme, using SACK+TS information, for detailed discussions about it...? Best regards, Richard From Michael.Scharf@alcatel-lucent.com Mon Jan 17 12:49:44 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1392E28C0D7 for ; Mon, 17 Jan 2011 12:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwxBg3gdBm2H for ; Mon, 17 Jan 2011 12:49:43 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id D432B28C0FC for ; Mon, 17 Jan 2011 12:49:42 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p0HKq2PZ002406; Mon, 17 Jan 2011 21:52:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB688.63D4CFFD" Date: Mon, 17 Jan 2011 21:52:01 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] RTTM + timestamps Thread-Index: Acuw86lm0NT7H57wQhaXrheqf3sEDwFOzq6gABTsMts= References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> From: "SCHARF, Michael" To: "Scheffenegger, Richard" , , , X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: Matt Mathis , Mark Allman Subject: Re: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:49:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB688.63D4CFFD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard, I happened to look at the RTO calculation and RTO spike issue a long = time ago. For whatever it is worth, I scanned that old work and = extracted some references that may or may not be well-known. A number of = algorithms have indeed been developed to address these issues (e. g., = Linux stack), and several papers tried to further optimize the timer = calculation in particular for mobile environments, including amongst = others: R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM = Computer Communications Review, 30(3), 2000, pp. 17=9627 [this is not = the actual Eifel algorithm] H. Ekstroem and R. Ludwig, =93The Peak-Hopper: A New End-to-End = Retransmission Timer for Reliable Unicast Transport,=94 Proc. IEEE = INFOCOM, 2004 K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, = "Round-Trip time estimation in communication networks using adaptive = Kalman filtering" A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", = Springer LNCS 3421, 2005 I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", = Computer Networks, Volume 51, Issue 8, 6 June 2007 etc. And, BTW, a young wannabe-TCP researcher once tried to systematically = understand the RTO spikes resulting from RFC 2988: Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to = Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, = pp. 76-87 If a better RTT estimation or RTO calculation was indeed needed, these = papers might contain some interesting starting points. Michael ------_=_NextPart_001_01CBB688.63D4CFFD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tcpm] RTTM + timestamps

Richard,

I happened to look at the RTO calculation and RTO spike issue a long = time ago. For whatever it is worth, I scanned that old work and = extracted some references that may or may not be well-known. A number of = algorithms have indeed been developed to address these issues (e. g., = Linux stack), and several papers tried to further optimize the timer = calculation in particular for mobile environments, including amongst = others:

R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM = Computer Communications Review, 30(3), 2000, pp. 17–27 [this is not = the actual Eifel algorithm]

H. Ekstroem and R. Ludwig, “The Peak-Hopper: A New End-to-End = Retransmission Timer for Reliable Unicast Transport,” Proc. IEEE = INFOCOM, 2004

K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, = "Round-Trip time estimation in communication networks using = adaptive Kalman filtering"

A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission = Timeout", Springer LNCS 3421, 2005

I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work = well", Computer Networks, Volume 51, Issue 8, 6 June 2007

etc.

And, BTW, a young wannabe-TCP researcher once tried to systematically = understand the RTO spikes resulting from RFC 2988:

Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of = TCP to Sudden Delay Variations in Mobile Networks", Springer LNCS = 3042, 2004, pp. 76-87

If a better RTT estimation or RTO calculation was indeed needed, these = papers might contain some interesting starting points.

Michael

------_=_NextPart_001_01CBB688.63D4CFFD-- From rs@netapp.com Mon Jan 17 14:55:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363353A6F56 for ; Mon, 17 Jan 2011 14:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.26 X-Spam-Level: X-Spam-Status: No, score=-10.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhd41ogBm+hy for ; Mon, 17 Jan 2011 14:55:06 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id D00393A6D87 for ; Mon, 17 Jan 2011 14:55:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,335,1291622400"; d="scan'208";a="231959696" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 17 Jan 2011 14:57:40 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0HMvd4b007121; Mon, 17 Jan 2011 14:57:39 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Jan 2011 22:57:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Jan 2011 22:57:34 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C6C2F81@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] RTTM + timestamps Thread-Index: Acuw86lm0NT7H57wQhaXrheqf3sEDwFOzq6gABTsMtsABXUzEA== References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> From: "Scheffenegger, Richard" To: "SCHARF, Michael" , , , X-OriginalArrivalTime: 17 Jan 2011 22:57:39.0116 (UTC) FILETIME=[F07CE6C0:01CBB699] Cc: Matt Mathis , Mark Allman Subject: Re: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 22:55:08 -0000 Hi Michael, again thank you for these references! I wanted to bring this particular issue up, to discuss if an improved = RTO calculation should be brought into a hypothetical I-D talking about = improved signaling using existing options. The one currently used by Linux has the merit of extremely wide = deployment, and being conservative (only improves one particular aspect = over the current standard calculation). For non-technical issues, "Eifel" algorithms offer less good choice for = any such future I-D work... (restrictions on IPR prevent the use in = commercial implementations unfortunately). However, I think most of these scenarios would also benefit from = obtaining good feedback about the RTT samples (with the additional = side-info, if the RTT was obtained off a reordered or retransmitted = segment). But current signaling doesn't yield that feedback back from = the client. Best regards, Richard From: SCHARF, Michael [mailto:Michael.Scharf@alcatel-lucent.com]=20 Sent: Montag, 17. J=E4nner 2011 21:52 To: Scheffenegger, Richard; tcpm@ietf.org; iccrg@cs.ucl.ac.uk; = end2end-interest@postel.org Cc: Matt Mathis; Mark Allman Subject: Re: [tcpm] RTTM + timestamps Richard, I happened to look at the RTO calculation and RTO spike issue a long = time ago. For whatever it is worth, I scanned that old work and = extracted some references that may or may not be well-known. A number of = algorithms have indeed been developed to address these issues (e. g., = Linux stack), and several papers tried to further optimize the timer = calculation in particular for mobile environments, including amongst = others: R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM = Computer Communications Review, 30(3), 2000, pp. 17-27 [this is not the = actual Eifel algorithm] H. Ekstroem and R. Ludwig, "The Peak-Hopper: A New End-to-End = Retransmission Timer for Reliable Unicast Transport," Proc. IEEE = INFOCOM, 2004 K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, = "Round-Trip time estimation in communication networks using adaptive = Kalman filtering" A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", = Springer LNCS 3421, 2005 I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", = Computer Networks, Volume 51, Issue 8, 6 June 2007 etc. And, BTW, a young wannabe-TCP researcher once tried to systematically = understand the RTO spikes resulting from RFC 2988: Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to = Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, = pp. 76-87 If a better RTT estimation or RTO calculation was indeed needed, these = papers might contain some interesting starting points. Michael From alexander.zimmermann@comsys.rwth-aachen.de Mon Jan 17 23:51:28 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101133A6E7C for ; Mon, 17 Jan 2011 23:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLG1py1kc08Y for ; Mon, 17 Jan 2011 23:51:26 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 31AA73A6F6C for ; Mon, 17 Jan 2011 23:51:26 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LF70048DKM1AFF0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 18 Jan 2011 08:54:01 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,338,1291590000"; d="sig'?scan'208,217";a="89086038" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 18 Jan 2011 08:54:02 +0100 Received: from [137.226.12.52] ([unknown] [137.226.12.52]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LF7000QVKKOHR30@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 18 Jan 2011 08:53:12 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-12--797587112 From: Alexander Zimmermann In-reply-to: <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> Date: Tue, 18 Jan 2011 08:53:12 +0100 Message-id: References: <5FDC413D5FA246468C200652D63E627A0C4E3E0E@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0C5BBDCC@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F629F@SLFSNX.rcs.alcatel-research.de> To: "SCHARF, Michael" Content-transfer-encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk, Mark Allman , end2end-interest@postel.org, Matt Mathis Subject: Re: [tcpm] RTTM + timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:51:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-12--797587112 Content-Type: multipart/alternative; boundary=Apple-Mail-11--797587149 --Apple-Mail-11--797587149 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 And don't forget also Mark's work Using Spurious Retransmissions to Adapt the Retransmission Timeout http://tools.ietf.org/html/draft-allman-rto-backoff-05 Am 17.01.2011 um 21:52 schrieb SCHARF, Michael: > Richard, >=20 > I happened to look at the RTO calculation and RTO spike issue a long = time ago. For whatever it is worth, I scanned that old work and = extracted some references that may or may not be well-known. A number of = algorithms have indeed been developed to address these issues (e. g., = Linux stack), and several papers tried to further optimize the timer = calculation in particular for mobile environments, including amongst = others: >=20 > R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM = Computer Communications Review, 30(3), 2000, pp. 17=9627 [this is not = the actual Eifel algorithm] >=20 > H. Ekstroem and R. Ludwig, =93The Peak-Hopper: A New End-to-End = Retransmission Timer for Reliable Unicast Transport,=94 Proc. IEEE = INFOCOM, 2004 >=20 > K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, = "Round-Trip time estimation in communication networks using adaptive = Kalman filtering" >=20 > A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", = Springer LNCS 3421, 2005 >=20 > I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", = Computer Networks, Volume 51, Issue 8, 6 June 2007 >=20 > etc. >=20 > And, BTW, a young wannabe-TCP researcher once tried to systematically = understand the RTO spikes resulting from RFC 2988: >=20 > Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP = to Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, = 2004, pp. 76-87 >=20 > If a better RTT estimation or RTO calculation was indeed needed, these = papers might contain some interesting starting points. >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-11--797587149 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 And = don't forget also Mark's work

Using Spurious = Retransmissions to Adapt the Retransmission Timeout

A= m 17.01.2011 um 21:52 schrieb SCHARF, Michael:

Richard,

I happened to look at the RTO calculation and RTO spike issue a long = time ago. For whatever it is worth, I scanned that old work and = extracted some references that may or may not be well-known. A number of = algorithms have indeed been developed to address these issues (e. g., = Linux stack), and several papers tried to further optimize the timer = calculation in particular for mobile environments, including amongst = others:

R. Ludwig und K. Sklower. The Eifel Retransmission Timer. ACM SIGCOMM = Computer Communications Review, 30(3), 2000, pp. 17=9627 [this is not = the actual Eifel algorithm]

H. Ekstroem and R. Ludwig, =93The Peak-Hopper: A New End-to-End = Retransmission Timer for Reliable Unicast Transport,=94 Proc. IEEE = INFOCOM, 2004

K. Jacobsson, H. Hjalmarsson, N. Moeller and K. H. Johansson, = "Round-Trip time estimation in communication networks using adaptive = Kalman filtering"

A. Kesselman, Y. Mansour, "Optimizing TCP Retransmission Timeout", = Springer LNCS 3421, 2005

I. Psaras, V. Tsaoussidis, "Why TCP timers (still) don't work well", = Computer Networks, Volume 51, Issue 8, 6 June 2007

etc.

And, BTW, a young wannabe-TCP researcher once tried to systematically = understand the RTO spikes resulting from RFC 2988:

Michael Scharf, Marc C. Necker, Bernd Gloss: "The Sensitivity of TCP to = Sudden Delay Variations in Mobile Networks", Springer LNCS 3042, 2004, = pp. 76-87

If a better RTT estimation or RTO calculation was indeed needed, these = papers might contain some interesting starting points.

Michael

_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander = Zimmermann
// Department of Computer Science, Informatik = 4
// Ahornstr. 55, 52056 Aachen, = Germany
// phone: (49-241) 80-21422, fax: (49-241) = 80-22222
for tcpm@ietf.org; Thu, 20 Jan 2011 18:27:08 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-6--590348885 From: Alexander Zimmermann In-reply-to: <4CEC9DAB.3090502@mti-systems.com> Date: Thu, 20 Jan 2011 18:27:10 +0100 Content-transfer-encoding: 7bit Message-id: <5C545D19-802D-4C8A-8C6C-4D5447A79479@comsys.rwth-aachen.de> References: <4CEC9DAB.3090502@mti-systems.com> To: Yoshifumi Nishida , Wesley Eddy X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: tcpm WG Subject: Re: [tcpm] NewReno revision (RFC3782bis) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:24:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-6--590348885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yoshifumi, some *late* comments on your draft = (draft-nishida-newreno-modification-02) * Page 6, Case 1: - I wonder if the case is also possible when the sender use Limit = Transmit. I'm to lazy to replay the example with a pen and a sheet of paper = ;-) - You say "Since the two segments in line 8 and 9 are usually = transmitted almost at the same time, the receiver may send back only one ACK for these two segments (line 10)". However, according RFC5681 this is not recommended." To provide feedback to senders recovering from losses, the receiver SHOULD send an immediate ACK when it receives a data segment that fills in all or part of a gap in the sequence space." What TCP stack did you dump? * Page 7, Case 2: - You say "However, these duplicated ACKs sent from B have zero = advertised window because of buffer overflow." Are you sure about your statement? See DUPACK definition in RFC5681, = rule (e) * Page 8, Case 3: - Again, is this example valid with Limited Transmit in use? * Page 9, Discussion: - The first paragraph, I understand. I also notice that Linux call = "open cwnd" after FRec. However, what do want to say with the first sentence of = the second paragraph? (Or the whole paragraph) I don't get this... Alex Am 24.11.2010 um 06:07 schrieb Wesley Eddy: > We had previously polled the working group on revising RFC3782 = (NewReno) in order to account for the reported errata and Yoshifumi's = modification. >=20 > Since TCPM's charter already includes maintaining existing pieces of = TCP (like NewReno), and given that there was a small amount of support = on the list, no resistance, and all of the authors of RFC 3782 plus = Yoshifumi have expressed interest and energy, we asked the authors to = submit the next revision of their 3782bis document as a WG draft. The > prior revision is: > http://datatracker.ietf.org/doc/draft-henderson-tcpm-rfc3782-bis/ > which will be replaced by the working group document. >=20 > Since the known updates are fairly simple, we set a charter milestone = only a few months away (April 2011) for submission to the IESG (still as = a Proposed Standard). >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-6--590348885 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk04cG4ACgkQdyiq39b9uS5ttwCfdQNcm5+gqF5nX2zdQ1oZdAUh tiIAniA86NWbOExqZWo0Mn6+dd26tkjs =5Lza -----END PGP SIGNATURE----- --Apple-Mail-6--590348885-- From Internet-Drafts@ietf.org Thu Jan 20 18:15:02 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977D63A6897; Thu, 20 Jan 2011 18:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsbjZtuQWxjU; Thu, 20 Jan 2011 18:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBB23A680E; Thu, 20 Jan 2011 18:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110121021501.15010.59548.idtracker@localhost> Date: Thu, 20 Jan 2011 18:15:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-security-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Jan 2011 02:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Security Assessment of the Transmission Control Protocol (TCP) Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-security-02.txt Pages : 114 Date : 2011-01-20 This document contains a security assessment of the specifications of the Transmission Control Protocol (TCP), and of a number of mechanisms and policies in use by popular TCP implementations. Additionally, it contains best current practices for hardening a TCP implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-security-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20180906.I-D@ietf.org> --NextPart-- From yoshifumi.nishida@gmail.com Fri Jan 21 01:34:37 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97093A68F9 for ; Fri, 21 Jan 2011 01:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xABdaX6WQjwT for ; Fri, 21 Jan 2011 01:34:36 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0EBF23A68F0 for ; Fri, 21 Jan 2011 01:34:35 -0800 (PST) Received: by wyf23 with SMTP id 23so1641770wyf.31 for ; Fri, 21 Jan 2011 01:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jKzjuSn4L3I9x+5bMszJW+OXlUvoWlIvEgaXrZ32+aQ=; b=xlkI5n9VD1aVh1X1wsade6ekKQ17b1AUHetdYlae4aUW+PkqC8h7803pkeYPGYL3iY ZuUlCUfWnAAwJdqNitaPPeDKn3C1SfNuqdgjAD2G4JM+AvuNVN4obvMq0d7pumlZAWiM 4SQBX++67/rg737WXVNwA8dk988KQ4oHKgq24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=n67k46Y2dR9d7uiyJGdO9JUCSa4U3xCU4tg6e79fPJtND8jD7bZ4ypQE5pcgeBZuoI 6UvykHSwgm0T0Qwgpvxee19u8cyLnjL2rhz1iqREqjqhXoA0ARUKpoC+F6OIcr99sZOO FheM9QGsoZzvALX51PfyPc8yHUwrO1REjGbgM= MIME-Version: 1.0 Received: by 10.216.213.15 with SMTP id z15mr328823weo.61.1295602640232; Fri, 21 Jan 2011 01:37:20 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Fri, 21 Jan 2011 01:37:20 -0800 (PST) In-Reply-To: <5C545D19-802D-4C8A-8C6C-4D5447A79479@comsys.rwth-aachen.de> References: <4CEC9DAB.3090502@mti-systems.com> <5C545D19-802D-4C8A-8C6C-4D5447A79479@comsys.rwth-aachen.de> Date: Fri, 21 Jan 2011 01:37:20 -0800 X-Google-Sender-Auth: YGgiYgH7C75w0h_b8p9yPj806Yc Message-ID: From: Yoshifumi Nishida To: Alexander Zimmermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm WG Subject: Re: [tcpm] NewReno revision (RFC3782bis) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 21 Jan 2011 09:34:37 -0000 Hello Alexander, Thanks for your comments. 2011/1/20 Alexander Zimmermann = : > Hi Yoshifumi, > > some *late* comments on your draft (draft-nishida-newreno-modification-02= ) > > * Page 6, Case 1: > > =A0- I wonder if the case is also possible when the sender use Limit Tran= smit. > =A0 =A0I'm to lazy to replay the example with a pen and a sheet of paper = ;-) How about this one? 1 10:41:00.000001 A > B: . 1000:2000(1000) ack 1 win 32768 2 10:41:00.001001 A > B: . 2000:3000(1000) ack 1 win 32768 3 10:41:00.002001 A > B: . 3000:4000(1000) ack 1 win 32768 4 10:41:00.010001 B > A: . ack 1000 win 16384 5 10:41:00.011001 B > A: . ack 1000 win 16384 6 10:41:00.011001 A > B: . 4000:5000(1000) ack 1 win 32768 7 10:41:00.012001 B > A: . ack 1000 win 16384 8 10:41:00.013001 A > B: . 1000:2000(1000) ack 1 win 32768 9 10:41:00.014001 A > B: . 5000:6000(1000) ack 1 win 32768 10 10:41:00.024001 B > A: . ack 6000 win 16384 11 10:41:00.025001 A > B: . 6000:7000(1000) ack 1 win 32768 > =A0- You say "Since the two segments in line 8 and 9 are usually transmit= ted almost > =A0 =A0at the same time, the receiver may send back only one ACK for thes= e > =A0 =A0two segments (line 10)". > > =A0 =A0However, according RFC5681 this is not recommended." To > =A0 =A0provide feedback to senders recovering from losses, the receiver > =A0 =A0SHOULD send an immediate ACK when it receives a data segment that > =A0 =A0fills in all or part of a gap in the sequence space." I don't see any discrepancy here. Because in my interpretation, "immediate" does not necessarily mean don't aggregate other ACKs and there is no clear definition of immediate. > > =A0 =A0What TCP stack did you dump? > > * Page 7, Case 2: > > =A0- You say "However, these duplicated ACKs sent from B have zero advert= ised > =A0 =A0window because of buffer overflow." > > =A0 =A0Are you sure about your statement? See DUPACK definition in RFC568= 1, rule (e) Hmm. To me, line 7-9 and 11-12 still look dup acks. You could argue line 7 might not, but I guess this is not your point.. If I misunderstand something here, please let me know. > * Page 8, Case 3: > > =A0- Again, is this example valid with Limited Transmit in use? > * Page 9, Discussion: > > =A0- The first paragraph, I understand. I also notice that Linux call "op= en cwnd" > =A0 =A0after FRec. However, what do want to say with the first sentence o= f the > =A0 =A0second paragraph? (Or the whole paragraph) I don't get this... OK. Please let me explain. My point here is on the arrival of the first Full ACK, a certain TCP exits FR and adjusts cwnd, then call opencwnd to adjust cwnd again. This means the TCP adjusts cwnd twice on a single ACK reception. But, I prefer that TCP calls opencwnd on the next ACK arrival. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp > > Alex > > Am 24.11.2010 um 06:07 schrieb Wesley Eddy: > >> We had previously polled the working group on revising RFC3782 (NewReno)= in order to account for the reported errata and Yoshifumi's modification. >> >> Since TCPM's charter already includes maintaining existing pieces of TCP= (like NewReno), and given that there was a small amount of support on the = list, no resistance, and all of the authors of RFC 3782 plus Yoshifumi have= expressed interest and energy, we asked the authors to submit the next rev= ision of their 3782bis document as a WG draft. =A0The >> prior revision is: >> http://datatracker.ietf.org/doc/draft-henderson-tcpm-rfc3782-bis/ >> which will be replaced by the working group document. >> >> Since the known updates are fairly simple, we set a charter milestone on= ly a few months away (April 2011) for submission to the IESG (still as a Pr= oposed Standard). >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > > From alexander.zimmermann@comsys.rwth-aachen.de Mon Jan 24 10:15:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DEB3A6ADC for ; Mon, 24 Jan 2011 10:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.706 X-Spam-Level: X-Spam-Status: No, score=-4.706 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCc4TdMmzwM6 for ; Mon, 24 Jan 2011 10:15:13 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 7B6443A6A83 for ; Mon, 24 Jan 2011 10:15:12 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LFJ00MA7HI7IS20@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 24 Jan 2011 19:18:07 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,371,1291590000"; d="pdf'?sig'?scan'208";a="89979548" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 24 Jan 2011 19:18:07 +0100 Received: from [137.226.12.53] ([unknown] [137.226.12.53]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LFJ005W1HI7JGA0@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 24 Jan 2011 19:18:07 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-9--241691779 From: Alexander Zimmermann In-reply-to: Date: Mon, 24 Jan 2011 19:18:07 +0100 Message-id: <184FECCA-A7F8-49E0-A62A-025732555D53@comsys.rwth-aachen.de> References: <4CEC9DAB.3090502@mti-systems.com> <5C545D19-802D-4C8A-8C6C-4D5447A79479@comsys.rwth-aachen.de> To: Yoshifumi Nishida Content-transfer-encoding: 7bit X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: tcpm WG Subject: Re: [tcpm] NewReno revision (RFC3782bis) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Jan 2011 18:15:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9--241691779 Content-Type: multipart/mixed; boundary=Apple-Mail-8--241691782 --Apple-Mail-8--241691782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yoshifumi, what I really miss to indicate last time was that I support your doc. In my opinion your fix is one right approach to tackle the problem. My comments below are only related to your examples, so not that important.=20 Alex Am 21.01.2011 um 10:37 schrieb Yoshifumi Nishida: > Hello Alexander, > Thanks for your comments. >=20 > 2011/1/20 Alexander Zimmermann = : >> Hi Yoshifumi, >>=20 >> some *late* comments on your draft = (draft-nishida-newreno-modification-02) >>=20 >> * Page 6, Case 1: >>=20 >> - I wonder if the case is also possible when the sender use Limit = Transmit. >> I'm to lazy to replay the example with a pen and a sheet of paper = ;-) >=20 > How about this one? >=20 > 1 10:41:00.000001 A > B: . 1000:2000(1000) ack 1 win 32768 > 2 10:41:00.001001 A > B: . 2000:3000(1000) ack 1 win 32768 > 3 10:41:00.002001 A > B: . 3000:4000(1000) ack 1 win 32768 > 4 10:41:00.010001 B > A: . ack 1000 win 16384 > 5 10:41:00.011001 B > A: . ack 1000 win 16384 > 6 10:41:00.011001 A > B: . 4000:5000(1000) ack 1 win 32768 > 7 10:41:00.012001 B > A: . ack 1000 win 16384 > 8 10:41:00.013001 A > B: . 1000:2000(1000) ack 1 win 32768 > 9 10:41:00.014001 A > B: . 5000:6000(1000) ack 1 win 32768 > 10 10:41:00.024001 B > A: . ack 6000 win 16384 > 11 10:41:00.025001 A > B: . 6000:7000(1000) ack 1 win 32768 LTransmit/Retransmit/LTransmit is somehow weird. I never saw this in real life. (However, I dump only linux boxes) >=20 >> - You say "Since the two segments in line 8 and 9 are usually = transmitted almost >> at the same time, the receiver may send back only one ACK for = these >> two segments (line 10)". >>=20 >> However, according RFC5681 this is not recommended." To >> provide feedback to senders recovering from losses, the receiver >> SHOULD send an immediate ACK when it receives a data segment that >> fills in all or part of a gap in the sequence space." >=20 > I don't see any discrepancy here. > Because in my interpretation, "immediate" does not necessarily mean > don't aggregate other ACKs > and there is no clear definition of immediate. IMO "immediate" means "don't aggregate", since if want to aggregate = something you have to wait. Linux for example goes with Quick Ack one step further = (but I think you know that) >=20 >>=20 >> What TCP stack did you dump? >>=20 >> * Page 7, Case 2: >>=20 >> - You say "However, these duplicated ACKs sent from B have zero = advertised >> window because of buffer overflow." >>=20 >> Are you sure about your statement? See DUPACK definition in = RFC5681, rule (e) >=20 > Hmm. To me, line 7-9 and 11-12 still look dup acks. You could argue > line 7 might not, but I guess this is not your point.. This was my point. > If I misunderstand something here, please let me know. >=20 >> * Page 8, Case 3: >>=20 >> - Again, is this example valid with Limited Transmit in use? >> * Page 9, Discussion: >>=20 >> - The first paragraph, I understand. I also notice that Linux call = "open cwnd" >> after FRec. However, what do want to say with the first sentence = of the >> second paragraph? (Or the whole paragraph) I don't get this... >=20 > OK. Please let me explain. > My point here is on the arrival of the first Full ACK, a certain TCP > exits FR and adjusts cwnd, then call opencwnd to adjust cwnd again. > This means the TCP adjusts cwnd twice on a single ACK reception. But, > I prefer that TCP calls opencwnd on the next ACK arrival. AFAIK this is not the point for Linux (as you wrote in you draft). Here, = the "Burst Protection" is insurance that you send more that one segment. = Pasi wrote a nice paragraph is his Linux paper about that: "There are occasions where the number of outstanding packets decreases = suddenly by several segments. For example, a retransmitted segment and the = following forward transmissions can be acknowledged with a single cumulative ACK. These = situations would cause bursts of data to be transmitted into the network, unless = they are taken into account in the TCP sender implementation. The Linux TCP sender = avoids the bursts by limiting the congestion window to allow at most three segments to be = transmitted for an incoming ACK. Since burst avoidance may reduce the congestion = window size below the slow start threshold, it is possible for the sender to enter slow = start after several segments have been acknowledged by a single ACK." I attached a nice example, which came my across. PS: Forget about the annotation in the plot, its plot for my thesis. I = know that know how NewReno works ;-) --Apple-Mail-8--241691782 Content-Disposition: attachment; filename=NewReno-Recovery.pdf Content-Type: application/pdf; x-unix-mode=0644; name="NewReno-Recovery.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJdDUxdgKMyAwIG9iago8PCAvcGdmcHJnYiBbL1BhdHRlcm4gL0RldmljZVJHQl0g Pj4KZW5kb2JqCjcgMCBvYmogPDwKL0xlbmd0aCA2NDcgICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp42u1WS2/bMAy+51fwmBysihQlUcd1j2LbKV1uRQ9F+tiGZF2LPf7+KNmW E8MtekguQ2FHoiWS+kh+oIJg9UHAxAadB3Sic4D1dvYAMwtnebjTwbgkHv5CXl6WsX2xc9CgJJNS UsFxNkejG91vV15vYd/1Q/WRx3zweOHk4xbh3f1smZ/hyP7E7sBlD0z3jVeN87NBfrx7dmu5Fwt6 awImIG/IuRcE85TbmhzHbKJnTU5wxoWUfZ6uZicfNNViUggMq1votXql1TVczG9/bzYLdeDmbxaU 5m8/Ly5Xn2bvV9X52KpNxVCXLphmiKZmyhoqZTAxRYu5ukOdL4BMEhFX58sS8vUz4WYkKQYBEsPJ KZ80P+hUgwkZKKnATLCB2ZcCoLFawehD9hyd99DsCO3OhHmb9YsKCOE7lBjK9zbbYkqksLq5QRW8 L1hTjLpAGida0mJS8qgud3VKCup30y/0Ns2EUVM91zMHED2yNXyFU2izfyiqUjQsisk7QyEchKuE SpgIjbCR+ARTO51WpfD059WCZP64wPmvRYPzbypcZaGQlzJ5ZYq8e47G1O2CG2I7GnMzDJ9S0ERq SWPgmKnryXgRzukNhoNnnKBuoWxwHvq57kyY/z/UPUIFJJLXRqUNCy1qF9FcpWQso1fkejGRYwl7 FZBkhdULB2c5465CuzNh/to8dm4Ow1E7LOkUD9E6SPt+wHrpuOnm0Wv1SqV9nN+s7//cPI77w1h3 1CG6CJohhGPxM+Ng0fsTvRbLalfSnDQUjNPLyQ+rLTuPAiGqqE1E9iAgsfERBccQcr1G5ZzQfe1H TyQ7UwpFtB0F9ROtVn67s6oJtOj131att74/yvgPTGUvdQplbmRzdHJlYW0KZW5kb2JqCjYgMCBv YmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDcgMCBSCi9SZXNvdXJjZXMgNSAwIFIKL01lZGlh Qm94IFswIDAgMzg4LjI3MSAyNzYuMjcxXQovUGFyZW50IDkgMCBSCj4+IGVuZG9iago0IDAgb2Jq IDw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9Gb3JtCi9Gb3JtVHlwZSAxCi9QVEVYLkZpbGVO YW1lICguL3Bsb3RzLXBkZi80LWVUQ1AvTmV3UmVuby1SZWNvdmVyeS5wZGYpCi9QVEVYLlBhZ2VO dW1iZXIgMQovUFRFWC5JbmZvRGljdCAxMCAwIFIKL0JCb3ggWzAgMCAzODAgMjY4XQovUmVzb3Vy Y2VzIDw8Ci9YT2JqZWN0IDw8Ci9JbTEgMTEgMCBSCj4+L1Byb2NTZXQgWyAvUERGIF0KPj4KL0xl bmd0aCAzOQovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNor5DJUMABCQwVdQ0tzBV1j MzOF5Fwufc9cQwWXfK5ALgBtbAbACmVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKPDwKL1Byb2R1 Y2VyIChwZGZUZVgtMS40MC4xMCkKL0NyZWF0b3IgKFRlWCkKL0NyZWF0aW9uRGF0ZSAoRDoyMDEx MDEyMDEwNTcxNSswMScwMCcpCi9Nb2REYXRlIChEOjIwMTEwMTIwMTA1NzE1KzAxJzAwJykKL1Ry YXBwZWQgL0ZhbHNlCi9QVEVYLkZ1bGxiYW5uZXIgKFRoaXMgaXMgcGRmVGVYLCBWZXJzaW9uIDMu MTQxNTkyNi0xLjQwLjEwLTIuMiBcKFRlWCBMaXZlIDIwMDkvRGViaWFuXCkga3BhdGhzZWEgdmVy c2lvbiA1LjAuMCkKPj4KZW5kb2JqCjExIDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBl IC9Gb3JtCi9Gb3JtVHlwZSAxCi9QVEVYLkZpbGVOYW1lICgvdG1wL3RtcDk0dEVUVS9OZXdSZW5v LVJlY292ZXJ5LmE0LnBkZikKL1BURVguUGFnZU51bWJlciAxCi9QVEVYLkluZm9EaWN0IDEyIDAg UgovQkJveCBbIDAgMCA1OTUuMjc2IDg0MS44OV0KL1Jlc291cmNlcyA8PAovWE9iamVjdCA8PAov SW0xIDEzIDAgUgo+PgovRm9udCA8PAovRjE3IDE0IDAgUgo+PgovUHJvY1NldCBbL1BERi9UZXh0 XQo+PgovTGVuZ3RoIDQ4MQovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNqdVE1vnEAM vfMr5ggHHHu+55iPNmp7qLJB6iHNIQp0hRQ2ysKmf7+enQWxm1Sk5cB47Gf7zfgBirVAcZ3hX9aL Kjv7TE4YCM5ZUf0SEj14I4XyCpTToqrFXa7RIj/FffV1SuWXJkAdRoh7F4IQwgTxy1XCIoRwsRHR chU5QoRyYIIRpTQKKByOLAk8FqXy0u/toqTcxD2FuA8phnvbjLYEnHLYnvkJZ/bMLxPLT1VGzBAF 8QAQpJfCoOMuRjx22UsWA2VCYPSM4HJElzP426GSU+A9e9CCdpROeNu87JrNY8NkjM6//0Sl+maI O5Pf8ZJf3H+A282/clFBg1NKKMsgZxKXqu0OPLizzvvUmefFpafXdi1OPKvrVF1D8KRi9ZLn4cgL Lq6DT8VX+ylbHhR7ZAA1iiAFtAXDnhgI88D84OQ8GB9JazAY0lDG4GEmbxxnXzoSV898RTeTDKfL GiuWs5LvfI3Ws1xIWJaKs4fznBcK8/q12UZNDm1Bed9Es043+KPd1M8R8vv4AyAC61nmDpQZFbAZ Us5ts+540x9nlPFejzIud93u6WFoXw/TOi9kyC+/naSRB7R6nrdqhu3Dpu/aYWjqWctImznM00/X j4gAF35z/7uyAv4Ai+ocPQplbmRzdHJlYW0KZW5kb2JqCjEyIDAgb2JqCjw8Ci9Qcm9kdWNlciAo UHl0aG9uIFBERiBMaWJyYXJ5IC0gaHR0cDovL3B5YnJhcnkubmV0L3B5UGRmLykKPj4KZW5kb2Jq CjEzIDAgb2JqCjw8Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9SZXNvdXJjZXMgPDwKL0V4dEdTdGF0 ZSA8PAovUjcgMTUgMCBSCj4+Ci9Qcm9jU2V0IFsvUERGXQo+PgovTGVuZ3RoIDE3NzIKL1BURVgu UGFnZU51bWJlciAxCi9UeXBlIC9YT2JqZWN0Ci9Gb3JtVHlwZSAxCi9QVEVYLkZpbGVOYW1lICgu Li9wbG90cy1wZGYvNC1lVENQL05ld1Jlbm8tUmVjb3ZlcnlfZXBzLnBkZikKL1BURVguSW5mb0Rp Y3QgMTYgMCBSCi9CQm94IFsgMCAwIDQwOCAyNzRdCi9TdWJ0eXBlIC9Gb3JtCj4+CnN0cmVhbQp4 nLVZy5IcNRC8z1f0FzR6P76As71HghMQvqwPwIHfp94qaWa54MVBuFKVmSVNS2q1/OcV7ngF/CN/ //b98dPXfn37+/HLVa8Yrl+h8fdHvFO9/nkQ8/r686O2fqWQr++PPHuj8P3xBhqmI3dR6hx3FY7R UVmKtb+9rIceLWZgSSEGr0opjYspz4msoPd4XTKG5GoKelXUiFzVmF5ndTefDwqXXKwsxi+LMklK MmspVrml/6DYIJ6WY/SyoBKlpDK9bpX1Pq8Lp1RdYUEvp48SZQYp0+vWPPI+HxRubZXF+GVRJklJ Zi3FKqf6XqNMaIoyd4JiFnCY+dnHmHTSfzcgGoUsM6TKMvtSClClQFEqUuXoYSkFqFKgKBWJMqWS TalAlApZaUiVLery51BVBETDsSrmDKqgUBUERMGxKHJuWfcSCkXBQJ4Wx6ro2XYfClVBQBQcZ12r uo/lEuaVSkvXX39AM/5O+j9siA2TOU9a5/RXmoWZlGI/+IVbGf53eqM9NaJFLAWIdXaihYY0RNqJ CP/hdEoRiyB4V5DS4FnXyguYSwMwensCpckMCTm+wnVEwT2dqM1Jc3a0PR6xMQt+MNoPTjwCz9gj nnNg3CqxNpRCZY+cQjxRnPrUaz2RrtF0b28v+aWTPhL5rW17RnIP/SoV99OeOXqntjyrtGGETyBp G0TGA6ca0y1cQ5ozZ4nJZ7VTbIoartojew2NpV1rjLD4zdXGePHx7ZcD8yXWdlfhdppWfY4QqwYs hDYmtI7JkbSRP7Uxr3dtw8h4vXTyRCbHH3iKivXKjAG2jkHPDR5gKAoko+aUWZqcXAaA10AwmmoE rIyrZJAdtyxDUVakzlQoMxRYRqsNX60nlyFgmnHNkaTOUKAZrTKM37O1YqjsSI8SxsFPNMISWtjy VonTSz2azzL0YtgXYgislFjbXcnkNaO7HCFR5QS7Saz46GOuEls7V+F24Ze42ik2Pm2KUZ58LnFh XO57C7t6hjqsvih6N63mdu9YaDXF1GWG1Oiwy2tlzZt+1i2veOlhnLDXsVZibXdVo9fM5nKERNUy xpNmTWsSWztX4Xbh11WdY+b3SaMolQ8cydDKSRXJiW6E6nOMTAf+MBDu9UiGNGfVomlgYa52jFWR YF0DosMOnCpiNmQ5qSQ508Xmc4RUl3hetDTpPDQMrZxVlOzS8rJcecaiLvj8GixuyJQisbVzPW4X Pq4QbaeY+ZX279gLP3s4XTi88lJJsqrlmao5Rqbs+KvzA4MsnngFac5qUm7pcGatHCLTyRlltEIn v2DI5bSiZk0745ZXTOpMu8NMfHDsEms71+N25eMuo+0YLz66zsHzIcvOMOWc9Ha0sKtnmIP1RdH7 0kpu9wZlgpNQCeprSHK+ZvK62rced6dr9Ckzcd7kNiS2dq3FGdO05nOETHXjiawOUSlauVVLETv6 HCPTwThTbNoTQ5qzamlp8ACv7fRVuSlgRnq3Xn3ug0rLxTxVB1MOPwRorowssbZbLcosTQo+h8ir 8szLbeb/rKJa85l8uxJuOFJPeI7hHiH0gYG02IG41OCOw4jo7RhobmU5kuARW8/6LoTvrNud8g/I R1w657tQD5lyyj8gHx9lp9kAH3FygC8ZF9pLk47+B5KFjN8DWyxLrfHGdyBdMiPOF3gtAb7S2hFN Zf3wgBfUuPEY3O4cIr2N4BWSrwZfHE2YypGmxRGR5/xvn1nLnbzPhFU2dh/hLB/hnD599+lnf4Tj ffrRH3jlzq0/CR7f0R/lmI9yPsMntX1csDjPcSln+QjnM3xKPMZV8tO4hLN8hPMZPrXnfVwVzjPH uISzfITjfXrCWjMH9ekFa01Yu+YjHGlaHBH9UJ8x8Fk4nzHxWWw+wlk+wtl96t4f5IzTp+79EY7z ybipJLzPyTe9vkJNEMCEjdC8MajFMUhBDLwR6c4jBeyu91CGeijDPNYVFbw77oRHhgZcOVfPu+M1 HLzRO19WLRa3eRbrdtYP8Jq1YtZ5TdjE0+FlLPMy1ubVjn4h6+yXsTavo1/wk4a9X7DbhLNfi6Ve i/VJXqkdY6TjxzHGxTIvY32SV0nnGEt+HqOxzMtYn+RVoa/7GCtuA4eXsczLWIdXP7ye5upiOa+n uQpfTOcYe3keo7HMy1if5DXGOSfGfJ4TxjIvYx1e/fBqT/0ylvNqZ78yXjRt/YINM5z9Wiz1WqzD qx9e8ezXYjmv+LTn7DfTWS9n5Cie5eqGb6Zhu0bIl6JxdgXvlqHrVs3QyRk2p+gyDEgDH/3+Tg++ +hdcWbpJ1ByduRP/a4Bmhr8nzHi5aldMObS0rp8kJxdaktOzOl7XuhwhG/vTPz6f/yJzfXt8efwL 06D8EwplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjw8Ci9GaXJzdENoYXIgMjcKL1dpZHRocyAx NyAwIFIKL0VuY29kaW5nIDE4IDAgUgovVHlwZSAvRm9udAovQmFzZUZvbnQgL1FIVUtYSitMTVNh bnM4LVJlZ3VsYXIKL0xhc3RDaGFyIDExOQovRm9udERlc2NyaXB0b3IgMTkgMCBSCi9TdWJ0eXBl IC9UeXBlMQo+PgplbmRvYmoKMTUgMCBvYmoKPDwKL1R5cGUgL0V4dEdTdGF0ZQovT1BNIDEKPj4K ZW5kb2JqCjE2IDAgb2JqCjw8Ci9Nb2REYXRlIChEOjIwMTEwMTIwMTA1NzEzKzAxJzAwJykKL1N1 YmplY3QgKGdudXBsb3QgcGxvdCkKL1Byb2R1Y2VyIChHUEwgR2hvc3RzY3JpcHQgOC43MSkKL1Rp dGxlICguLi9wbG90cy1wZGYvNC1lVENQL05ld1Jlbm8tUmVjb3ZlcnlfZXBzLnRleCkKL0NyZWF0 b3IgKGdudXBsb3QgNC4yIHBhdGNobGV2ZWwgNiApCi9BdXRob3IgKExlbm5hcnQgU2NodWx0ZSws LCwpCi9DcmVhdGlvbkRhdGUgKFRodSBKYW4gMjAgMTA6NTc6MTMgMjAxMSkKPj4KZW5kb2JqCjE3 IDAgb2JqClsgNjE5LjggNTY5LjUgNTY5LjUgODY0LjYgODY0LjYgNTMxLjIgMzM2LjggNDY3LjEg ODg1LjQgNTMxLjIgODg1LjQgODA1LjYgMjk1LjEgNDEzLjIgNDEzLjIgNTMxLjIgODI2LjQgMjk1 LjEgMzU0LjIgMjk1LjEgNTMxLjIgNTMxLjIgNTMxLjIgNTMxLjIgNTMxLjIgNTMxLjIgNTMxLjIg NTMxLjIgNTMxLjIgNTMxLjIgNTMxLjIgMjk1LjEgMjk1LjEgODI2LjQgODI2LjQgODI2LjQgNTAx LjcgNzA4LjQgNzA4LjQgNzA4LjQgNjc4LjggNzY3LjQgNjM3LjIgNjA3LjYgNzA4LjQgNzUwIDI5 NS4xIDUwMS43IDczNy45IDU3OC4xIDkyNy4xIDc1MCA3ODQuNyA2NzguOCA3ODQuNyA2ODcuNSA1 OTAuMyA3MjUuNyA3MjkuMiA3MDguNCAxMDAzLjUgNzA4LjQgNzA4LjQgNjQ5LjMgMzA5IDUzMS4y IDMwOSA1NTUuNiA3MDguNCAyOTUuMSA1MTAuNCA1NDguNiA0NzIuMiA1NDguNiA0NzIuMiAzMjQu NyA1MzEuMiA1NDguNiAyNTMuNSAyODMgNTE5LjEgMjUzLjUgODQzLjcgNTQ4LjYgNTMxLjIgNTQ4 LjYgNTQ4LjYgMzYyLjggNDA3LjMgMzgzLjcgNTQ4LjYgNDg5LjYgNzI1LjddCmVuZG9iagoxOCAw IG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMjcvZmYgNDYvcGVyaW9kIDQ4 L3plcm8vb25lL3R3byA1Mi9mb3VyL2ZpdmUvc2l4L3NldmVuL2VpZ2h0L25pbmUgNjUvQS9CL0Mg NzUvSyA3OS9PIDgyL1IvUy9UIDg3L1cgOTEvYnJhY2tldGxlZnQgOTMvYnJhY2tldHJpZ2h0IDk3 L2EgOTkvYy9kL2UgMTAzL2cgMTA1L2kgMTA4L2wvbS9uL28gMTEzL3Evci9zL3QvdS92L3ddCj4+ CmVuZG9iagoxOSAwIG9iago8PAovRm9udEJCb3ggWyAtNDQ2IC0zMTQgMTUxMCAxMTU0XQovRm9u dE5hbWUgL1FIVUtYSitMTVNhbnM4LVJlZ3VsYXIKL0ZvbnRGaWxlIDIwIDAgUgovRGVzY2VudCAt MTk0Ci9YSGVpZ2h0IDQ0NAovRmxhZ3MgNAovVHlwZSAvRm9udERlc2NyaXB0b3IKL1N0ZW1WIDg3 Ci9Bc2NlbnQgNjk0Ci9JdGFsaWNBbmdsZSAwCi9DaGFyU2V0ICgvQS9CL0MvSy9PL1IvUy9UL1cv YS9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvYy9kL2UvZWlnaHQvZmYvZml2ZS9mb3VyL2cvaS9s L20vbi9uaW5lL28vb25lL3BlcmlvZC9xL3Ivcy9zZXZlbi9zaXgvdC90d28vdS92L3cvemVybykK L0NhcEhlaWdodCA2OTQKPj4KZW5kb2JqCjIwIDAgb2JqCjw8Ci9MZW5ndGggMTgzMTYKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMjIxNAovTGVuZ3RoMyAwCi9MZW5ndGgyIDE2OTgyCj4+ CnN0cmVhbQp42rS3ZVQcStYFihMkuGvj7g7B3d1dGmjc3SE4Ibi7W3APTnAL7q7BIbg9cuebuXfm vb9vsaDZR3ftOlUFFCRKqgzCZvYmQAl7OxcGFkZmXoCcvKqxnTM3gwrQwtXG2AnAysjMzA5PQSHq BDR2AdnbiRm7AHkBXC6WAEVTl/fM9whmZh54CoAk0A7o9O40A5h4AuSBLsZqng5AFgC18V9Ayd7Z hcHE2PndDbSzANkBad5TRO0dPJ1AFpYuf2qwMTD8qfQnW4QRIGNsam3v7mwNAhjbmQFkGOUZAQr2 7u9GEIDa3g5gArQ0tjEH2JsD1IBaAHVVcRVVgKSKorqSKg3je2FVVwcHe6f/4yKqqqYuSQ8QE1ZQ EwcANegBkuqqan9+qgHt3vlb0AMU1N79f/q8B/5JlxdXE1bTVhJnYfqzBgALwA3o5Az60/Z/uFG+ MwP8Te091dzJ3vavBgBqSxcXB14mJnd3d0YLV2cXRnsnC0YHm7/4qVmCnAHu9k7WgPdPJ6AN8C9h XO3M3uV0sQT+q8CfPQHIgUyBds7AP0kS9v9y2r5L+Z70bnf5D7F3IVz+1LT5VzjAGQj8rzaWxs5/ 5copKckBbI1Bdi5AO2M70/dAF2MXV2eA0V+292+gGdW/CAIBoq5OTn96yP/b5fSfNv+mLmL/vjI9 G29fY/f/3TFjO1dnr39o89/LNrW3cwY5uzj/qyIQYA6yAf5h7/xnz0B2f9nkhRWkJcRV1Rjk3gfP jkHe/l0dO0YXD5e/ov/UExaT4wVwM3MCWHjYAczvQypuZyZqb2v7ztoZ/o98YqB3nVzsnTyZ/nes re3s3e28/19mc5Cdmfkf3c1cHZjU7UCOrkBpsf8LfjfB/22zALoAmAFARwDQw9SS6U+zv2blj5nl j/ldBF9vB3sHgLmxjTPQF2QOfP+A93Y2dgMCXJxcgb7e/3T8N4Jn4QKYgUxd3sf8/ajA/1Vd2s7c HsDzL/M7k3+7/m8AqP86pjTvZ9TM3s7GE2AGNIdnUrB3eR8H6v9/Ttn/9JJwtbFRMLYFUv+Pov8b ZmwLsvH8Z+D/BGgC/zClVrB3sjW2+R8fyFkC5AE0UwK5mFr+S9Z/2aVdjN/nXtjOwgb4viV/mdT/ HCWb95l9v3dAf64tAAPLH1H/y/c+jqbWdkBnZwAb518u4LsI/8P3Xfk/bAFMylLqsloydP87MH9F iduZ2puB7CwArBycAGMnJ2NPeOb3KWDl4AB4s7yPsxnQ468xATAx2tm7vKcAHFxdfAHm9k7wf7aS kwPAJPzH9C/ECWAS+RtxAZhE/4O43iNl/0Y8ACbF/yBuVgCTyt+IDcCk+jdiBzCp/Y3ea2r+B/G8 I+O/EQuAycTpfQKALjZAc5e/7Wz/sf9rlv7jeCdh+h/EwswMYDL7B3wvB/wPfFeHCfhf2RzvZc1B bv8IeV+Fub2r0z9KvIdY/AO+SwD6B+QGMNn8A76zsf0bsryzsfu79vtK7d73/R/+d3r2/4Hs78n2 /3Czv9N1ADqB7P+xIJZ3No7/gO/C/oMryzs557/7/UFAN+A/GLyHO4M8/pHw3uIfarzTdXG3/4f7 nbHrP+D7Yt3+Ad/5uv/N9t3pBXT6V/Z/T7HSnxv8r+uJ+e+x/r+n7S+s6uJkbw3UBJm9P+v/CJE3 ft9sD13m97uF5d3+/vXv3/T/qwHF39fiP7JFROw9vBnY31VkYHvXiYXjfTfeFWL3/a9c03+9Mn/d a+/n79/4zxUPAAI9gKbwS/P2pnwhVilNoWV+4gVT5dAUPIwnlVgCWjJxUEvpU9/xccRyt0mBgoWB LQEZlIX2clK8+n5JgXbFWhQhmDav662JVZO/zZSFdoz95P3wkcSFR3M0GNWDMuQXA8o7SWmOZHLy tUvYpzPa4tqIAOqjv0R5vnc9xLBOvKFeJZPqlbet5kG7F82yNGM42aB5LKLgdeAvTnWAu7w9YMRG G/cKL9HOGOWHYo3KwDj0dKEfVBpYonGzfSCCkEvhRWE06EwLXdKCeVrJmsXvHD4KdzUTEJ1Ne6vb jdU69y9KFW0Zg2OobnKDWjqTu2rxmYYgvV1NjQoQjv3yvQ3m2NV91XBKklf92aS1YaWixR0kbGpi OTh7B1V9OaRNtT3VzfG56aP+6pQX8T5aONSnV0nvE0E8hFZz81nFoFBJ4dAOF0gfwGcqdD046JT1 IYKcVP1FufB0Xtb6AN104KdAGxV+jFsS3QgDTRR4RtEqALu8eGUI7hH17mrKVm0dtQZEHf99NkZG ZopOhaYOtjuD7KLx0DLBbUIlV5vmmHLraJAG7OSGMLv3VLLUQYqoB1keQ0HF8qmAAIrI74bvJ/CZ dco+YJInK8tKbmA33hcPfGxuCpKNmhTOFIIYPL0J/aM/L3CeHxIL0Jkd8CVaD/k+YW05cP66uoBl 0BuLrEs4wQT5OHWnaOgHdC1DVCVoivoZPWle489vOUXoI6GhWchhgBdMUKQdTMycw6O6IpnQaA2F 7YWCWdDi/eY9y1vqqAZh+Bl/MkZC88kM/FpUf/NQMDpQVkyI63DBfPrRRHC+fEf+J6M/Wg0ElEgv T0CQuzp0QtUhmKxq4zNCLflNBNBFJwiTKdXo0f4tsWuD2iu2F9hUI4w3eV4E2IVYxi63toWDWlyt LbJLfrYicAYrFDe0f4gsJjXlmnsGZeDBgV1Ii/NPCo4PFeykdKMOT+/pI1KL03jLKWn7aw3RQUpV 0sQ5reFiY/Y8B2635YBNW/Mzp4KZk067wCPVuPARTVQdPoB8/D1IgUXRsr5R2BJqJ/58LZUjCzTY H1GQ9SvlmseQzl3mTc4eJCEO4rnGm3aWrwYMdFDW5hjrOHup+tYrWAz0dj3DYuYRRnA15AuNt0/M K+YPGpLoSXpndny8U7D1NCxX5MzGCXoFHTnXkczEOAfcQwrGtq+XVa60WiqzOKu+JHrdaapTTM+L U1N/hA/CwescPxfQz8uO5DiDfZHISk3GFAO2S1HGH/ZL+RG7kvoCJ1ES6amw0eti05C+IpIEBMlW d+w+uSVku7OMU6WSZfYPKxgLj/hXLlmvPHMJEBGHhRMvfOf1Tr0+NalkQWuMrRAnUXbvDdBMfukV KnnLgkjXZNjR588SEFBP15UrdIB3nFJGPJ/BNiw9KJ1tobn0VA8kwcEUPXHE/tXmrbWf81yVVKkr NCVYmnrxSA21WTtSs5bxMMN5ZaCZ1s5OAO5++TFFoPrg7n6e2gfKcudbWq/7CVMFe75jjDuFRWNt mtf06wdwbDytVtENpKJqbZRbFn1Rhm/dmp83jQmDCuxzuj8ixl8T0UMlmn4LvFPdvjctv9kOdcaF 4WZncKnNjQsP8SahPo5CTzesP70CcD3PEdrcrBLREZzqZ4Aq6l0s3d1xUPjDetR5odHjLsgtQOdp xekNX7u9clbVep+ITVWP17qpZuJ1ZxgiSNLdoz7JKqUBeQvjvcTgliixB4nb+/LZtE+CKo21MQjb g8OPTPintw0JltN5EcpCdVR+/J4hkOYXiSX0yUpWOs8wJ+Ax3GlFuD6onboGlM3e35c5MBv8QmET Ow3XGnpGMlcs9jN4Ko4LRiDZSdKVFrfzE6Qp+JJcm/A5yb0i1GMWkU9rseRWP6MwG0Ky13X7dHi7 500xWxnTGo+zaOpic+S57Uokklurnc0fyVLkRD/zoz5FcmWnn0xY4FQDikB7fME9OLb3esaa8Xb4 UffPl16fuy88FDDld0VD+UQwkP6gEGAdL1gfy7iXaHexH3mMUcr1kgjbEyTlerCK0ZBGhqh3wqv6 QmaSiOhuNoN/R++klzTVojCHKPjpJnzHRNQyW6dWJ5NfHyaxUnuW3kerybZHdJlzTBC2PLrRIGoh 8sGrUvSKpw7fy5iFR4IVC/wPTFLthY2q9ie0pEFsbZoCo2fp5ouZ2Q+W1YdnrPWwQFGJ6idjsthF hFv27SOrD2weKM5iLye06OSnHhjA6R/SyJO9BM0QCgyxUrBTVMO2oKcflDYD3NN9fXTCBsk2lf0k S5vzeDMUpOWQ5o4ZsiUMBbSPUCC6DaWM47eG/lxFj1ye9J8csXqRgXL17kOPYgHD+XKOXMGtUNpa 5tH2/ss4JQwo6J+Ppn5h41aui4LT0pYTO6pDAGo4msqq6YLPqclpZpknOMoxP4LoBQqh3TPXESTa Q2c+zdvCZLZIFmBSMsUqokrBr/4kCJB03W1ISRlzhOHGAEGwWVLGEW5jG1gEDNYN0cMgr+AjZT/N d6wQKbRAOTD6OtEcp2mGT33EuBzNvoQ2ykFcJFRE9pOeoSFzMOOWojhxTNS/4IOGqGaVJLGNTT5e /HmCMxt7THNk+d0iTvW4aLeMqITdvVmVTfmjcLakn69JVsFOL2ppNta6LiIXY+kauJl3EouIuHAH PHMlyuapjFaUi+CPvQ9fSJ1nvI9LsHISMz5QyKSqpk5m7Vd7uCZ7BaQJnoyfXhk//N7bYJvTZr8N SUonCM4rXD/U0ZmioiSqVnEuxoJKkK1NjnxcuQcfrwAyWOIPOPfafnJ+xds+MqvXLOc9WmSSx6iG E2X0q+M/vJZSU2BxsN68XrgVjS3B8UmEQeaOGe5P6ukueIriayDxfB9iRrUekOV8Uxvu6acbC1H9 RvnDm70MkG/LDDbYQYYDcqE9zsEy0A3uYUKsKP8Yv6XX/ujCgasb5huaRR4dRnLkzi+eW4ZFv0/h ygrfyN0FxD5h2KPP/qyOjs5aPJNnx16Lypc2E2TeFzvwj124sJZGU7xqWDOF2dFUgKTuPTRbD5x9 /STRVC1Vfmh1ZZ7dmslrqR3I4GsjgjGHhO66SpyrX0atwuC77rZtQwULjiMAJplIzzxlKSwP7962 HePnkg1OzCVDHSPbCKkloD8l/uidtK4jWTJyngizjJXXYa043BjJUMSgO31RV8bTT+7WhHp5QwsF UUTH8wmd5oH4dtOAik+/JUmaRf+nltvkgIJRqr2hjpV+7Y+OLAo9xym2I+qweE/7sUqpJZUY62K9 EXeDXx+zAfJdCO3CAqVK+addM0lXxZNEIUrwhpvDUAQt39iOhn4mTDwodtN71h/9qnAyyL/Z/Z5Z LnZy+BI6Yit5FQ2YaHzhM+SKKPEmKWxsMbhO1GnE6vS24Y6bZuZFIpyXPpOdJIq+ZNX/tO6H5Xpz KcAdyGRp/uuhO7AoDyuNU4UsqNjqdJdYduBHPgXLHEYcwnOkP6QS4Houj7Py57AHfO6VYRksKD3R UpiiINBaoJVC0T2w2rnfRVugNcSCTfW3CbytN0jVFfrs+qHvg/oAG8OaVn5ATppEOcPZdEaqmvoV URKpvm+hB8KBVnQSbiQ0fw4nQwwF+ldJ4g5uVBUPQZgNPfiE3k6juDfknjuN1809PF7llEqDudyj YHQtw7svRMmUExyciZHb2sSz7uhYuFW84rcf0kUMmdfPDfAiOxbhCjI6TR8/3qVJKMnqL9DQyTkj qvUkTUlxQ7BEqzT3yg1Xezjy6uPAOM/q2uDl7kzbaBwvL4uaS+duydTItJaROjoiRaZk0HxXSGCZ DLNnCWbjZqwAiBt7P3NO+UWgwiOJTeZLwGAeo3SO7GTQFnqvmAfa65GLsdvT2zT6GX+dOZYZiWTY HDd9gzsxTQzd/+bi9TPQXDhsHZt92FHN0yXbg0YUIpJZAWkv9ANgDddOYdsUO7yxLn50Groj0m/H CRPs+1S4Oo+ngqb4DOiX/TI+SRHU18uEKROGAqJ5CtXR7PoSSZlzH/ctu59Q2EJeA7lreQe+XJXB F2l4CrWMI0D+WqhtHYNEmw6OgEzeqXs865WncNgsf98jZc8wQxKfjxaUcAHxx+RmfSmwqPJzkmix n2RkyKkbcVRmlwPIldeoPC5xCN3lI+XW4DXDho1fydSq7UeEVU2gkUbTfXhbKmxAXnMh+lpz6ZK8 QJZzRTKJWM0plTrKMuPc8MIs05va9S4dMliSPWwltGCL3HKnRL3EOPBQvA71eNTBH2UeSQN83gn7 GNOpZJZZnSbr95k7TL1mSaSpelSJBFq7NwhJmgP5xDouX3U6k5ipBawHaY+xz4In8b4/VJ3c5K5R tgxDoJEiTimb6HIjBfXl+Yg+do8/CuFuDUZFu6nu8dXhxoyEmgGkrtoHB5icyWsKL+aTFDVProSe XFPZg1uOrgRgFlY9tQn4GbmsVSUzqwgngioUv/gGINgOgJASdQ5Djb89toxss/AeoUwalfSa42rJ iEvDjSKoSX4FFoKwzHacG3tlBeptmufureostibBP7TGORjnVOrhbzQilLorY6iWqSyIEXehO8xz LdgICNwmM7bSKBbz3IsotiZ+7u3wNezhYMeKWSkUClbO1LK3nrSqFVYlmy4nQo8w2sl/cp9IqXSv j9zrAhUoY0y1zK08MhEU9YXS8MCQmvhPLGTP0w6ZJmirxUrfrJl6wPwgFFYdmiIIOlMnC6gf0IJJ zloXQxj4sitI/fHBZ7ORXci9emw8aLI3YhaoosHHuaxfzfOb3bL89DMxQT9UoKmcuwNO7979yS1m bKGLmh3XCygVx8x3Rl1MKad9UW+z9euGcWkEOQIjrg27UvtyFnisCcpBhxTAOCGz2J7NtbFvjGdJ AxEcHt30jjIRjzBlxDf+g0ujDhNPl2Syhg3naglGDaTXKvdCmUHRghGBG9UqXkIZlD2Y8YyGPEDs qGXhGE5RBVGnGp2WqgUOHMutBExjfal/hDVX42Na2DO+uBDXYDuLJ2s47SFp/Bs5T+ztCIrnc8wY ZuCHTvBaSUnObEhvL2eBGvpURBl6ZikowSu+2pY+xbTODdYZIxSY+5Nh5vWTQapAGKPPPbw3jMxV TWGo+1tILT2PdBsf+hmU4f+8QdIpdGACPamrG9LCcG5toV3iOPRzUl/4Urd/mzzfNQzTfinr3oSK UNVXuh7kU1KdO34U3eeNfhuC8Hrq0rsa6lpdp03duNuu4w8kk6BUVX+6+q31TKe3RhGnQlk46k13 YdeHKZFubsWwrkKuEO8yP+P4Urtxjf2Zk9JS/nucrGir6vSJRhjQb5JIk8pWypR//Ng/i6SedUI6 qHjTZpxR3NR+xLEdaoqVXZxcWWrMUt+hrii/dq5/IL/tNG1MvcXiK1S9vqsMTjFmwTTvuIeZfowM QZ18tw9Thue5OTOCYKITEzy+vMbVwCcDAhbfmWqxXUuw1yWfQgiVgFirs+m1Ph8fHsuh7OIM/rf9 zWdxvq+vhXkjsaXZhYNP0nrXFkY/R3Q0Rv3qU0YBghZZ+SY/MPETv6jkIHqRQDPhUU+wszy5EE+p viE7+R0U08vIIcaglLEzDz7ODK0IfKzyhRPHWxo7RYpgRU6zSxtCU7m0RvJaqkFg+7kAS7zfhAKP 2UZuYZQoC6FUywggi1cZWZNL4XLGBOnFD1331yB1j98hh3gYV+v8mrPRKkXi4zVWN/PxNpfOTmv1 URae3tQttdFW1WNvSzH067x5zDcdaCb7pqDL3gCdmyfAErt90KtXesQwzja45vxUXUUr0FclppzQ FiQhtzVQH94K/sCVn3arx4qN81G2o9THQVwll38DobOc+pBPLxFb/ykbNX+YMHyJ6aqrxqYUoyqB HW44Nbhc/3PkXDr89sgJOvrCrBZqzwXpd970p+BCAgn586gxM3seLnISQ1XDo7h4mNBbTbno9WDU XojV+HzTsWtoCAILxUH4GCLd9BX8EJYiEl93Gv29X25MIeEE9BSTV3cpvYoT9Fg3UZ/VLLI/r6lc cxG6R+HoVeeW+gdKFggnO4UJsC9if8Miz5N0qdiAKAmX2WWzFzyeivJOaFQasyX6CahEZWPj+qZ+ nWlAMzfLio38vTZDjmaCyE8MJ19u2TFXsdSfBmwjbATEeEwLx2u614uG2yoaGv8DfFDPpC2kGZJd mXFqnl/58CFcUTedSRA9EdKKkzvi4Q0eisA50c5tYdK8xayLumZfcx8+ligt1mYQK6HzZ18ioKvg NDewnCueZUX/ExstTctX0Chak720Z96gQObuYd1p2jFgA0OPCDrffCui4GHqnHdhQ9RIr+GcYUOK lZIjOslZRWrTKHRKuOspCWOvhTyaQVrXJEmREcjOtK4aZrq7ttAKbiAXEXaM4hIbuLFO73dT/0OE Gua4cHpDjccgDlAaQNL8sSW7v3VARIuhzs8GTz2S/NFAF10Y985W+0OrKlwWPHZFLW+GZugv/dSR Vm+HTETF03ifLJ4GIs6eLG7OC6adRTUdP2VQaiW6PDme8wxReeTJfj2rQFHoCL5S60BEZSAvN/fT RQdKibyQj2wXiK+jOMTv6T5HoooNr9vg/gN17I3W1Om8PwdipjD0vcV2uSBK3wKU4VIbLGLpbw0m VkIw+FV2ATpcls+iGkGDovTDY9VchV8lOhj60TuvTAjPB3boFNxNCw4w7noLyYqDlRwlFJk1nwJo ZoN0JsesPxjmuxtHEndkBEV90V9HdYvhQCNYanMoHUxSj2DSV5Q/X9LeB/VOXJ9vFvtq2O1uQzgx ztHd4RArOyywXJI+HQROpGzABCP3p3bUOFfRF51w1i9/QbszM7E+fuBkpJimzbSawOlLjY7lKtzG woMqKapi2TmrE2fyYjQTFFkkHO7FZqHceZn0dSSs5EZShApQ2nni86XE1LZrxYQXotfjgB88qwia V0w3aMo3cfTghMMzMbrCXiJUyL9qegrb3oT60QtbwFFSamEV/GhHU171EjSgZfBBNgwTwGZZEYGX C2b1sqt1FR1uIuvz87XfAriBQM+cRCu/REq4me7eagEdy23GdSrUvp/wVcYpH57Yx2EglKqIw8yh 4zSu2jb1npWt8syjPBGdT3CH2vGYT9lzB2lW+wOOhdCwMMByoq0Rc0PjkE9FnRbbTUxLV1eT69WD 6wO7gUPhyvyP71a07e4WeLxqNwL+S3X+X7HoDrBK5Y05digjoC7iY1J6SzwSl1dIjKErxYhdJTVu nUPBuh53di06y9r3KSIBSzuM2MLdje24dS6p02Z7eWknjOM03bYENlJxfvZd9SOzy8JIoB8iIwOy wNsWmu5Iqft855TTFu2yh3zNAvNJ6kiqa7r2hg/+WduPyVxrlqm3HiEdjr9gxO+z0UZXM4GxOJ+w pKb7goxYSijE2CtfJHY3+8zvrSGj5+BEx+fqaZc1buCJJC/V0UfHzVFhnkIQvkYcjbRd74gUh+Dz q0BJwE8t4RSAQfcRY3tgsVm7VEelsXR2d2/cKEviDIHXCRz9NOhbRsd8sUrq+218zEt8mlQocDHc Fw/dAa+iipX4yQ6r2qSsjUYFLJ+UUTouHUC4LhZjjZC119pf8YK7Ttp2LdTEoNN7JPyhVOMeVjlD 7Le3tHR949Yqid/fk+q6QGXXAyVxgAw759ifdumaW4IfCSSAhLapN84QUlZXXRF0vPhFSZKQrb6N zE39EQl3DwNi+CyUqXau5rzBxgKA1//dt4BDJTVtWV+ZFQ+PE/Mud51zv7lVaXckACIoEiEW4JXD VoU/RqJNapwXWI1epyKGuu7Abp1HzfnlByEyqtVWDkVrFmzadsKpESbJByB97QLNtWH+ZwJQgWxB +ZMWjUgO5iP+9fJ94hHP3q9DUHe0gBdRI/UBSSn9SvIk3cLmSeOKE8mRg39xDhXC0e8GQmj1/fol 0Ba9Qhg+KarPUfQjSrFfDzc1+iajL89xKdqPjx8gG4v1ugNmMa6L0cOBnWlyNi6kXzrOc9v5m0BD u1zR7u6gX8PncE9QaOIO0z5YUVFQahFSWZZIKNNJN2I7z7d+RZvNGzNdtb7s3V87q2in0ziPJgZ5 8oRI+ur+P/463LcXi0gxo06V8X0cnXmlLv36qYGx5qThjZrHzyXveZpIM6JMb6G3bs0KghUxLu/b wrFkWoKnwYglbMYgS8rITdNBj79HSzPmzaLEFSlyVyjBIJZ1V9w3Z33VdYKaZOrE0WXWNzqHOrzf P7U27yRUrOdZN8M1JjgO0U7rbJ2XxA7JRIYxmMIMi7jg64e/hrcJGKSp9caqTWwM0mKgZlYLi382 Q2+xlrU3neKNLqDrt2bO5Zlk0SfXVhr75MXcMYb186XASeSy2NRQo3TaliHwCZqFmzgc7Nnruxon uk/TydUw0Cbgf/9/iB+F4WJ0rd7F+fUwrkmonZvlejkn+EpIC7rAaoZYPDf5OVLA6cy4d+PBDKB8 Osg91LMWp31DZY2lVgo1FDT3J0bQ3hkXuVaw9xdl/dzIqp7PmL9rgsPZHcSClLBZOVJHscC2RcZM j5gBrZDCbRl6jpBwo74x1OuscYH2GwSZ/HmxM/NXG1M+YF05iv7qdI84kJtcdkBcqpKdrRQ8X+Os L98bZ0+y2atmDcBX6Ge+05JAbvrI02Qtv7qTI6D9gUwbcWFQtzNK6+zWK9hTjjQWhjKG+kz+OST1 7RWFaKU95uuKv4Cxi3vmBqH/dKDh1/g+iQDDj49EER3G8r5vSvRCUQoULFNUkved5rZd1u4Vnyif EooZ9F9zvRADukupC70bY5IF+qyMbJB6GbC/ylRjCIGzZtYH2RWkdBjI9879IJw8pM7oizSqM3fl hX89YUNJbsHGVC8Ia8rvcUgY1joyGuws+OFPaDke5wAuYFExiYbuiowDfW0ptkgDeW72JcVXYJgB BX9QRapVs7CoRVmkwH5y7AuhdjgYD09DdOkGNhcz+CLNSbEsomaMplGXFXe88nxyRuR1FSd8dPc8 uTRFIDynTtYXkqUXkkT5qJ9b8CqXIgVGYZZ9kPzwyA1NizkXF05uorKGyWML+07RNY1qZjF7aLav 0JDMwrFlzJ7L+YG/IBa4OVdXilyG7MPxEjWjhaKPoeSnLfjQaWBm76MuadnFPRWHVwTxG6qrQ2Qp vd1Qin9q/uJd9rkV+Eaw3vnzxVYtN2Rm9UfFj41PVUMOZBbKS+ekqGWsjKchrRYTLD8us/CLBKcN XQRfSiusxg2eTnH1LEJQwDiyGBderD+RYsGCfaqucFZiimkTzH3WbXVj9pb7da0LjQzis+oEv20C n/m6vYoK9YCvlmurOaK0ntT4w5TSQr3GhyhZq2U5R2poC7n58qz7cQQSus4ZsiIK3JqUyyaaTTeq 7eOWFuFvbAx1AjKNFQZbpLO7fiGgUs++QZFE1SIuqN3bzvUVcYTQ4OE2o8NWn++M8cqdv5oi2xaf glGBvV2N607DMf6wE0uXR8RDNL66R0yUx1xFbeKZVjC1WNDv41eUfpbtuQ7KU+abRat6hmFiG1n1 GDaoy/GexA1X4Rn5gmohll8agwm+KQMpFWto5sZr5J1JprQquxrqeSZb3neFOofXZvr2oyiZne5Y ZvbIm5/zX3ieh8RhBo7kzrxuKtXlPaJCO0C0JCl3dSULNuHgJb2WdKrRcYY2sCyTvqzmHBMqVeTf unA53QpasszMCdBjOOKWN2lk+6XTaoRV8otpmKC/zt+7kXKAuA85vSJXPQi/0fpWGnskWd8lItPY Z7UqKzJF8CTrCJGrHthbozFsCphfMK6F0u6hiH6eNG1z3YGnDSbtmlx07m1hKc+/O05iWrgrYs7z Umb4ZjWAMxXiVMM4pbMpx6Dg9cINvr1Lg74JJUXpdrIDyLXEDPgMGUimgajrRtvTI5MlgX+WdJY4 92WMKrRq8WcBnFdXjhDLBM51lYwqZEPV61DNijyjxwGNtWkCOy/eGuqwY4MJ3HSzew//eUVG13P9 a4rQwNJbdJRDHip7IK166c4wDKNK8ap7G45TE+S4KmaV1ph360NEpXlVKPoYzl6BcpLOArDF5XVR Vmy5Zex7w0eLgnakNKLUVGifA2OqVS5m+4WHvd1vywHrEDR0UCK8QphnW3CDmHo4GNndpjelfMEm wpYj4ERlW7krWfA8grdZthyLlz96djz9jLL0lJgH3lhQ2fzcQrBB7j5KjPKzHDLgPscFBV/22wCm xUqjQ36tP3tXusczkwoLRQbkg9g7G9rX6ldHUTgaqrKdO9sB5wGjZM42SPq791Wb4vENQdz+zmpE WDhiIyuK9HDTr5l6ZOm4B6aT3V/zmnu51DO+juJPzh6O1l1RB47Nx+Q1bHmdfSIzXraW5PK31h9j V5tmSXtaKvfXnYPH7togCaX1HbemRBrfZKhYGNXxBEX4ij7ovt2i0vPcV4S2QRW46+E/cxqHasXQ tAzsKSnlNK0d8KCPHYTQpgnwUIbZyKu9tsxl2XsO9E5QkYofqUKGevFg5CvT80J3kdtqafGT1hHj 3z7HpqUsqm2ou6IEjXKHDl+B+PKzrv2MNk/xv++zZxMXXGtXX9ScD4fr6S36e/xUIF2UFJD5+goD B4DAQeFkNKpjHU9yWJ9lqB7ifL3TLxlKL0pf2uO17oX/UBIeCcYrgyIJo6VgBX9Mz79cpx1cKq8K orSzJ2JjtMi6mU40fXKTXgox5Wti8NrGqiNwxtt2O+qDpK/6dbHBOdq+Ur+sFsA2z/m5NL+iIHQ5 T9rX7bb/R4EWe/GUKNdTL+3M4hO5L4+5pPHoq9UzKdZIMDZDBt2evNfREHXaxwBDmyJXKVSYLNLg O84WTGryQpz6Zu5TfW5lntNINPoWoJcfJKJv5D0v4OFmBflOMuH6ByWXxo+PC7rI9iRj0MsEWzxM NBG6ewIiaLA5tbefNvZ/68751oJeOCyHNsVC9Q+Yv0ROYZySCaa2bg+iLGsbx06sFrb05zCaY3LQ gF7rlD6frGRHLqbDLJ+M2Si7YQerhrCT0hWpSEJHym0bRlzlqYsywtKR10v0O8tc/FJO7LAq8nbG m/ZVRe+5lPgGP79wrQxXp291v7M9k6R8vupuMTcKDloPexwu/HlDiDrIhyH2Gr2KzoOXdIEt8OkM uUUb2sUkb1mfCVlEWFOIbTCWVXLgpyah2Cm4XOuY9I+X34a/tC6/QvE1ik8y878kE8xB+4vN0eMb jkyar+Beq6BAMmfOKd0YwZdCWtt+OwE7zG6neREjgb0QrNDQCD28556DhOrXaVunF/XQ4Kwp1z8S BGq/OthtYJSX9WzHjEv4ou6nLaKk8h+U39AGhEOlqkY6CwgDGxBDKFeSbFG6W1pjVIKnu2JXKRf8 yr5vFibSxUHhmoxUjDB+W4wLsc8XCH5i3CDsDpaH+wJAlYbENMQomHZx57Y2x12wXibhh9+AQOg/ 1wnN2gtmTmf+dLzq5OjQVtii4U8dn1qc4xlVvxPbAqm8bXaNxnHXRdhttdj7ViPFshEyu/uIv9in 84N3Zr+3qQr2lWEIfFKKcW3E4Hz8J93sbcFwcpV+817YiBJSS/oGsXTLFe1kjvZq9qIDOoN8v1EY v3mWFZbN69WGR+7sQsCHV2yjmp/4/OIWzYlQCSgo0DmoTKU1J40hLx7ymRtvEbdyhDS2C7Oyxjo2 PZ9KsU25ckzl+qXNGBDqFTMTPG7OJr1aAxT2r7LA+iiev/QQiI6CZAKt/DBDMd9kn3ngo3n40Kru tK1K3ek+bMtXp1FdPHkKVDGlxF9s5oz6PuJgpCasUsCflv5kssO9vbw3z14Ki9ZxGWYVdnpIh7XR JXXgf/FC1sdHU2E1VA5L/JBOKwxJ8fLZe/ICvKSW6jaWBmPP05mCHbH9iNokXpCl5TXTtfsGutPE zH1Dof7R6GwOI5zekwIV81ga4SkzWRslRg5aud0L8fnksNyyI35yI9tuF/Zaxzw1SaVWCXcpdmGW f4PlkCVH2tJvQ/NnNDqiYO+TGvSgcgX1ppuGVazGD+vMHtg8/CVOxRjewsiCcgvtqk/3BTWpPpYm OyeiVgo0bqqXefsHE+xnJTHkAhhwxK1kzoPEghlY0j+uh5CvR3sr4T4qZ+VSz1ovFg9ZxinnQQsm dwSuF5r7XCIg4zdoQn2ZdV5QWExUJz/0J4HUkmOFiFRe2S2NDetu2QtpKFHjtf+y+DmaddckJA5W NozCT3nIxZNn2bFPnHKAF8QMcJwg9OBw6dSNU9Q2eYGnNpnKJ3yyIpAfpqVoURwhmu5E2YlLttQE gz/Z3B5HleXMo5YiRcM4RsYnrcnplSlyBoqSug80KGChfiveZUT6/uUILGbduyctPpPOwfTHmc7e Yi2+SZaOxoLv0bfZk6ZNiOtmAhpNlBBmcmq6T04rZDkLsJ9QSLLkdX1rlccaleglNmRQK4vkSfHF SKVZpw2Q6rZ0tGz7ZLambJWfLGQvKgKqVdPLxCtsGXN4qei8Uj3Ce47mEKHljjJyXJmze98SyBBF eJkHM/UepYaTaRS6za0cQpPhPl29pbGJ35O5BUmolEGRrDUevJR/WEsIv2aWy9Gd9j+y7R3YUVYv 5cvjbnUR1W9CkpIVvnIK5L9rbrMx7z/Hifb8QXT2BD5Ong++Ri6m5+NIP9h54FP1gsY6SWMNrQZ+ Nelp92Mcv8wu5ZYzQiE83ZyozDRrPA9zbys3IcCXsBdB8bOg7txDBiMXW+uHhDPMunjHBJaPcfFN wTdrb0LRr/tvLA7lggmRlCLOliLjDfV2c7YFv8RILThOeJX5wNvba/e20iATpTiYgmaIJWGGVvgH fH9OGmWe6KkCp6yPKgN4k2wF5lzJXqkvPWbRdG7zHrGDgpbwdyDjX9lQ9ujcDbSPyftyx1GrYuLv jL4szHS9thahcULGiKnsyrBfaeI0Y8a4+PKVYrNMITrQRKkqrfBdR5DHDpb52dpHd4R3Yh11z3Vq LEZ2SwufyiVlESbF0pFRT9rTrHdBnNZpc9cAfEWdYS+3YLJARkf1mFxGyf2KYNzafU5TsV+Ez9G+ fMunsdFz69aPYUsUNlGc7PKzhJK4D8+nEXXrNIBYWJVAH/JqC57SPoXhmAuT0jiT/e7kjcRqUKc2 Sd5cnG/84JlWKX1KlF8nOrSzgbb5S0ya/GnQqGiHPsFLlWAm4XORf0JwOZkmdnVIdZd+QAwrdEuW VQwGphUl1JIbNN3IT/tprQJw69sAYWycn59+f64f2dzEZ/XbjoNlyaK62B2r+gHipVac19njG0o5 8S4WM9e4qsAjLuHe0dJ72pCohHvErlU0nuMKYm35SGzmRZbMwFMAz68vml5+t1W2Udi/iWAwse6T Ml+g4lN4VM6nwmQtVmKNmoiXuosLJJiKOFGe1S9SXBQk4X9RW9WXdq56fcQMorNnjFwMeY6kIi4W io89zGE0MDD1xUQ3VWjWTL8fLkTcNOBWpfwtMBjO6oR28Hsp4kWAAbAzRpp/DR6RlFsZaXOYm/Tm j63U84KJfrlM35YJ7W5JZt9dyCwtHOCFEqGemcJEjv+5T0L3kzphbngE+XN0QhNPgG359d7lCWNF 9ouRZteb2sGzqTNPkg1xS+U3lO2zwEp+rOzO3h7SPtVfVR1NtbSJePZBfT0xIsXymhlupWCoEiuo e66c14n9SXJ2zoCBDxTQRMlknxffkLh7z5hXy7lsXODCE94Ur1b5pKp0HkycxrmHSTS9wJdtDtrM PrGepoVsVBv66Y4PXpWccKixx/IQ/CTdJf1hXwjgisUdSeBBHtVuPfsyRGlYzH4jEiChNQOvu05M 03P+FbAmqHxiymPBQe+KooNG6kq00S4Q5ZQU9plJ6lAs62eb71HFr1lrRATIfLUBePiUrtfKn/ga K7l2LCLdWPu+zzz9tSKedW2Cxxv55gSjlgN7Hijl2MK0Qf5a396aKlR59Zbo5YX2SBdg4SgUzhPd hgm0z85t14YPBrA6oigk+xzi0BIiJzPqukLrj4xdz6pmtg82c3g1XkZVtpj5qsWuLrzWk3nOMdGm EyHyGIoRqR42g+9Uyc/XPzAROiRDQljQJmsiPlJ9papKw0U+Kg2ysC1YgDMdi8yQjWeMAGtw300h d/LPfKOuF7A9ZV3dIssRiRbFCi4kCLMKio233+0k68vobSSWFZHaMLr6ElI7U4Ee1C+fAatk/+J5 EBDfeDlxztCkKJI4YhtdnV4tn8Xl99Zb3RcTUvVEl1LAPoFgdAiZWuRuK9dhOlg5ZHU3DT0rbLzT 69K0xB0VpYVSN3ipVOgsF+H4kM8SSAqcV8a5lw64mt0RTLmmePq2uoGMUrk2M6EHsNiBCaAEfPie Qj8XYs0aiWaMMVzFHjW/5h1yGqoEZyzhp+q+4kCUiW5M3FUixLbmyeLPcqfTOqxO7AFHPQCI7Eua 8f1QCd8VkED9w9nXM4toXQdICsfIYSCJ8vm5R0cmH9GPAhnLjxzt1+3QerLzh9MEQ9GV6/IzUlAh AR8H11D2GRFwg7/+e/EzRNptZjUXe6SjoWrGxVK+aMiOy7pZ8yyOg0pSuSuvp71OSRE4cS7Efg8/ /2/2GFqx9GZ8so7UAieEPBp/HJqPiDhfYMwEC63WKptRBFEsuNz3GlE0mE62BaAUXy+WeXENkxI+ NV8f9BRla8fxrk4ylFcFo4BtO8POj9IWn9w80E0+zjStw2qjbtD7u/RFWgCGfu1i5Y5yqfXl3cOk wof4HUhAn7Gfv/rgh5p+CEUr3DHUwlKt8P68JBvR6RaIyDft1m0TccCwtTDnjozADk+1PcE0CKbD H6Nvd5adHPTBDocpV8qILaWT1BIkPiBFMC7ao0W0SgnXxlOTbztm2mpCAe+qdmEr5e+JQuA1r7tQ Wzs1XIBnVjQ09qw/sxrn1v95Z9cNfBIl0s11Uzxn5FnmTIxfqEHOV3G6fx/aO9XnUYB91VqAXDwO iyz/0e10dDWKWYJn6IdmAdQGYGoHDpO8cP3aN6+rKCXkhzyqy0p12DzzTcCoJa7nq8gHqbrgAH6V hTJrA3grURm7EDRzWIeXGmXwSpz0tv65yOXe8Wlo1EAWnfNwhYpmG110BT/wzwdzqQobYjtKO+MQ RPd7BKCz9z/xB5MSsL0+2mpOoTka8MVL8zWBA3SE9iKluMxbPGZ/hx1o2its+aV7Fu/mj54QMSFl U3J+qoS2RlDlCBS6gvuqDDnT3B/15ek3VBf38FN6KcQ1GC3NBGXs0YKO/48M2Df1R6KMl99+pnWP /OKeMBL39Q9SbttCsI2ocgZKfp+tEghGoYuimSdl46B3acjvyJKeoDj1ZhuK3r47IDLGbK3wLNiV chWG1QioLFzuvqzfPZJX9D/NoGV1a5OAQPVtED1j5/y0qKMfMQoQhNK/EzorC0RkO6lArcLizfCh BgPBefW6yQ7YHHRTZs5vhzLauqTPSgvTP1N+viW6Rpc8aLNXUh3vAzeDqeskN8zOH5mVYFMJO5Ku W0YJ+WBcXBHtL+V2Il2jV3lNYwlUZYROGWoWRvITE68G7wHq7Bz8IirI92p+cNjaygjx6Nhy1I96 lFeGDwzscQwECu0T6TDSSCZ5lRV8Qx2rtMHS4TnGiKK4YteeTrPySB4lQRXrghOb7C8k+761a0Fq tVmfAJyUSHVss/9u0071wVAgp/wUfcrOa9iL244FxUQhmYKSvkgzDo8LcyvbyZnrBQsbrcDDawbN oY2mbkCjgbiaIqvAygQItInCDksmUcl7cGsuDARv/qoXBnoL051ewOcTpQt1k5usO0hmpIrd71Wj NBFTCxdbBrqrYybDUbmECoaH+oad9xxxuNN/5VWtqPMT2WaRUppGEZ4PydFhvxjCnv2GOHpKQMki VAPD0N1/gyyp3jCqdmsu18Ep5KKDwKhc2xyAVFtHq1Yny/5530GP4dcUCNJzTd0jT4NFdjCyROkI v4oL3eTZjxFFWDSe75ZnjFV4/lk1p8RYeL+kdwDvlcB/LgRq7HbLec4+hv/T8HCVjbu8/1Ore+l4 C93at6nkuOLnmSeM6lkEofp6k3I+92jJQ83d3kpT/bfib4hZrokPENS1mzpwH0VqpwNhM4muAqR2 sZqvtGdn5n9e1FhwzVxbdl2zlqjzU2LbSQFaZ+5oM5BgqbfFZ42yhayb5tgNDce2QnmF5vlHOccd BXPfIsrdS4WaR6Irax8Bd8mc3yB50q8aiHgwt9sYu+0F4TI85cTJ/BuU+wUaU4GmW3nSuNE8Ql1+ Hmz04F6JqF3x8pu78OQ1W80pcPIbtkTWls16XPqT0vLXZkGtj9x2AMvAKM6Oj2fRwnGEQc5TUPaZ C80qX2pys4SFr+G+DzZRWy/x9aCZYlcukc8VE/ehUfCvlU5yHIRHYJVX4wYzF+0F636cbYPedhvN He82EJ/LuVbbvT/3ONhTvmnr4Iu9Qp/7+l3RoYr3AvUmdyk143RY0onaGFhifpF/FP4MuMya6Egq CqKbpEmDeeqRM/o1ZVamNsLnEQnTxzxziqu72586zrWbcMnV06XJrUxaExINVHVm7daWtX81EBbP p9VbLXAbJ9+Zct2RKsXK8mBix9o/zI4Kl+MvG4KiAbzAANcGmQ659OKeliC1hN2ctFoPND6KcsrR RezAV/h8QzuDrZmHuYv2hbB6CMRbNP9KlTN0U/OAiXn9XEEXTyh9d7XFukH5zE0YE0Y4Pp39KE8W jYNM3VP5lX/eq5Kjlsgk7xkM7mA1WipNFgEbGliVzYk7k5HUNCacEU5YWPsdu7Nxlp2UJG7k43K8 /3XQt44+dHhoioxwA9hGWPCSsmgNjrj6iCYxnbT1lKiPgbttZYxRaHhEuAb7ENuX7FFMCYhMUkzY P2Fry+W441hL37YYnrJCTmuJQodsBJ/AvsuWtDMnSdW1Q8+eMPuswwVRFHrcXP3uo8KuH21l+LQk k07Xn472wXuz5RLWu1GCbAMO9W74XH3WSHPwU63ul9c1bRa5xkZ1xeFL/bgZOVGp8OyKMoyc+vvc MzplNtZIBzEfzCbHGZEnceVdP+QJ4WzSkECgdpTh3sJ3jy8V0yXiGcjbJqd5TmUZq+CHg6Mknv3U EAZJApF3w7siscVfx6uN1Bc/RCgAguc5hZI95X5faLmKF+CVZykjz3iZrbL1l3Az9pNAszcYmz6O qG8p9+WcR0nuwfdfAHsa3obA5G4Kp1Fta/flgjQH76Q/lxTj/kqwRTDhuaPwrDlKcFjOTD+xsSg8 QDiaUr1Nky7dNTuVjPwC6V/LnC406lsR1N/Amq33FllzhX40N6k+SzUMcnrBG5gMjEPZf12f2aeN P8eR845PzicrFi039u2rj4niTJkYiyy8dLlpHp/1emljsjRZbHJzbpyS9Mz+4aaD1tL5kAqvNJNg tOrJn0mJnG7JlQlJIMhMjJOdsqpe4xo9hL55Ci8StIKGo5MY7ZAi9sYZEGCNkHsC1Wd2agw65X9Y +HbysnrQfe21ZWJhfo31qTf4atHl6xs14bFdVfa1GiOMQ5JpL8wBlLyq2E8d+wP+cRWOoMIUVtcm Wf4ALQ9OHuuuEkftdpeJ9JJtCf37dlzUsJ8yPqhaFLzCK7zNeJuDMTmP8/Iusm7DvIMAnaidsHLk ngK6WUwOgUTRELRpIWQ02FTRTcAModJQnmbpQCRXmNDbYHuah1pQkftbxKfJJszrsy2XlMon5kW0 L1wqbvS5FO5TEOB7v2NWYfcYP8M6HZNAuI3X1y6BeT/YFGYhp+uYlsslKtfXYHf3to0XNlgFJ7ys RHoPdwLMZS8V67T6bFX2A6VL51UxpttBM4aCH3JcdXPl9SFLBfeRv3Huv7R8mgiXVopsBfIzQ8xk iAakQNRjhQdnIKZCkS4bR3d183oVYzxOp/voCKyOl9aypnKOGXNu1q0Gxe/Y9osQ1eSKPqHlQn7B 8DyklflyesoIhnBvJnDk9OOhQfo70iOkPsHsoZ8oHnDX47oFleHWZ5B4VCmwml/5KCEx1TWv1JSu Dr3FcLp8R7lcD8+gIrqv0SdJKUJqGcHR2wytQGTsJpK2gKGeRYUudXz4K+PSfo+AKiv6ir2d8UIf 9MKBFOsabWmn07EFMW1AcweJNaslmeuGBVKpXWnUBOFWjMwPVebDAhECwqWTgwaiMbn42q9QO9p5 OxhEw9YrzXdowL5JCwLMUeTJPoVIbIyqxt8DB5uw4tEkcqLCZCU2ozrt5ww4Lgx3IwyomT20rBKt jb9Q7ARvSRdFXR0jy1j2HtGbxFpCzPSrcxSa7qz9qb0SoaSlNEfSFYjHxja4kLHJoy/Iv7AY2YEH KBbPSxwFgNecBdmbfajrvweOh7o4+oXtS2GDvxDhh0H/QOtGCfpUVd1TiV0jGjjgKkr16AP8VolH /YlNAf5Y8/D9ceueB9he1jU7EAAOUfuN5elpZ8qkZ/ESewNx1/oxVawoHNWewpGhGmdnkQO+H5j2 erc2xX4JtkjDq3zu1JYG86+bUvcKnzEBV9iYEVNhy+X/1rq4nHakivX2m5K4oYIFOrLX2/oe11ui sE6EfhHZ01lxFozLsGOy7DvXr50jIiooE9rCtmR2b9ChmCsAuyMBPNQczLzrFNojPAGKOORqYFlU oRj1eGwFeIi9PWYbpLkUKAFefexXpa1jtRBbgICHRb34UgD1eUjYLlDjUCBQzvf3xpb6AFIsepTo 5LEcM5F68tijK+5KbY54Ms8wN6GqjGkL4rfKy51f0V7ZP/qOZ1DuNtY2JumTEQfntnEYWB7s07qT k0t5U6mObCM1uS74JmwkJJxlwVw4XFGUalOczdsDxPMXNFiSFcoKpNDvWDQ8K0gFWFT8uD7byHNs u5ou3v7yGUNySfEZdo7PVSiDS5wh4xfziw1T8eG4Hj+ST2ZOaOypdLEiM4O/XP7GbPmhWClKKAJx jCSV2VexVlu7Bc02zvD2ou8cwTw306xgLq35s3heuQLbuSDG6cnkIlOa65Ko1ao/vwygzzziLctV 8HdqAsaWcTyJBQRxnXmR6ox+CJi5IjHj+5sSlfvR9XFCeLa7mpPSbq0WGqTLKC0Z5ld7nftKLHQq cx4C7V+p1Es1zT+S5JSS6OQtlAlbve0uhe9Ru/zqKUwJ7dtBL8FkDI2dBRGeBlsnCDZ7m7vUrKCN X1Ug1YGpqk1quZPQlSsB/evhO38o6o6RB+t8cHMD7f7ec8FAVRD8l9mUL3ZsH4v0OVC3uC9OLLIJ TA/JuWF5EBjQhsRwOWz6tOZ8pOWXYLf2V785ZeEWP5wyzusdPBPWRp17yTNUlfUm47l2KQuOzWoq 58bNiCSHjxalqgoYMXJ5nrsk7lL9uImF7wy7AED2uS5Ttie6qQMKNL39vxQXL/PUtKcyuVZes8Dd f/Nal1abqt0KAKCM8AMXTd1eeWjAHnFfX6e43D7ik4zXDlxSr0s0Fp4V40qXOrtnEPU3a8KKRrur 7h6nNARQG3APML7eJ9t7oHB+k8DtFwNHOZh0P8+OOJicG9zvCTlod+PyU2xT3cITPaklhKW3nEbH 3xrs/9S6QQ5lI9xYV2W9qZgHCoCgbtvZn4WCx5OoO3nuGyyZNiI50cTN9hxDgY5voIdsYG0JsGXv 2A6t9pCQz+mSDxBlFRWJqctqcQT5EzbtGTK2kxGHdx2FM3FLVl+OmPBe3XP7Lo6IFYltwtIES4nV tYrRhn2nM3SvFj0U0vpOQmIF7My90ZCAL7kF5GsrUKsz7ZkRC0oIin5r1isyi0TtZ0O84FDxqYs+ 8smsrhQ/GuXNMpRPHs+FDe2doIqlbJxDzozqGKyf+ykWmrGXgwRh9HJrxT/yCY4WhBbfVQmXW2wd yhsGBzkNOXyZNjQnK2FkCbsGSKVuCGPm2t0XYE0IhvuV5FgPn+Oy3UhFdde+krakWqPedKn6UQ7J gFvC350S/xSjHegEplCCDRZae4ZoiiKzYYQi2UQOC3eyrg2xjC5e890yTueTNKpTlHYw5HgjEz// RxUusK8/QTEj0DNKBp6qTXGzpnX5dub97txUCnhPDaZleBUpo2UuBMpH+qNonnOsHhhNAqLgD4RH Li1rrtDtOUXpZ9tz7RkojVFHH3fGsr1WrGwMsakm55oyqrXihOj2aOUQ0I0YeRiS14ymh+7gizRM fqK5Mzn1gZA/MmpbqQ+4EKQpHqWmGny4dJFQNH1QSYsWWAwlPzGlK7V2CdURnxkCaCV5BDcuyL6J HMP4f8OOGWFhW7kNuq25dzQNj4RmthhPSphF5krdnhP7sVV7EjkreP8iUM0txosLkz3slVV5Y6vF Hjq7SwNdcEww67FNCnvG7PsbWVE+XkP9O8SgGlexfLpraFt+y7zw60lqTYwYZbiV7CDN/uZEX57J 1yPF3cz7RkZ3cWGlhh2u/iD+rNxUEatzBl1wPWUsfwoz0zqqyGos/OlK8cG5ezm6cZjWO/A1huGP HqwTDU/TVHVcN055MDC6YzFDbP75we2iQhgYT+rmnQFbiQJhpure+WslMkmzlscvVSaI5R6WHWpA 8SXmoA/JY2iZCQO2HkrcOzU1nJtgV225B0z5EF6eLSaRF+2cqoU66kDq9LJdsN/4G9WpkzpiJDYJ WYIJCo3w8JNZzRbnWih0FmQhY5TdhMo0kUqkP4QPC6tC5Thp3h5/Bjnr9+HTk/NabYbIokBPgUoT NrgHLPvJ1a/jJIcsfLeiRR/74FKv/58A/gUB+qPSy458M38CFVOunjV3W+KQQ/STq9NYX+cky5/g MjsOp79XAep2Kq1SYBW/8UHK0LGtclQW5lq3RLb9JVkdeDHAZbCfgakQxK+S00VhvOJ1jQgyz2cF CypUp2DIcbaYnhV8UI5eItefA7n0tnIJ6vAAc2l53oWJFKlYgnimH2Zyh5ldsMy2bfKK8X52B8PM 9C9KbuQMPjZoVq2SodDZ3isf+iAaus74v1THb91oJ82Pdbl2U8OyXYDFbXe9jI0zLQvMbT8Ovz7B BaJ7xGqGz1X1s9K3bbtzQIeHovTmY5AAkpV3CbZT05ReRxfbQ9JLWV1pp9e5a3mgRFN2D0bGmFIC q42+L+XwnSVLK6mzm9+UcCMldlfF/i4mtNQWeRJpkFz4QzeSQQjDLnwA17i/stoWVpWD7W4XxDl1 f3lUGgEcMmRxhwQz21FHyp/RNFBcOzhDlkCBvOjif/f+Ojw019SdxFwNB+K/4eOyKFf5BRKy6ncH uFyJLB2xD+FQd5zlI+wLSPsSqS+VWcpTu/3JAagdsaS6yDV10dYCtQTXu/M476w0Zo1vEUdwJD++ pXH34UeEVdlOtPOHLtK7vv19PFGq6Z3yTaNPXUAmSUYmETSdiXvKoo/9Gd+UyLYfORGEU3aW1Iim KvtSqR4T8rDtsLfYrpklyfuYIROgQUAw898ln2hq8Fi/dYiIFJRPT3GSk9Cw7lhrzzwJDa2F9Q0H Xl8J2FN3ZoyW85qrh+7c9xtWbkDv+qs5Xmk9b/i4GBE0y4hHbjIPW2YtECWDdGIllNYARPfny0jd HRbpadnTePLNDqz7uoJt2WbrE3nWBD6+nuMV+6+XTWECaEdzLqysUbnKow2AUERvrD8W9IKmsFwy t7VqVos7KQ2hNqINqRKUGlIzb4XjyAVvxiMgyZTQv6iI3rlyJEdkA/pZGm8Wc4NuYgfKq+6Y/XCu n81O4XH96xOc210vdwDAbFj/oRUEHM8pf/8EGh7v0vKcR9lawK+GjWJXkXU2nlV1vy3M7fCmcjJC Daeo3SrsKQaCCyinG3aTcbI2z+yHi7G4qTZUisVKsfJ921ba51eSPGA1mxE0kgU/moLCYCEWRk7a WYXLdd/G7xrzJt8s8oZhIp+hEtHLoPooWEbXvKE3OKGrjDUoVqbIb0diTGXgfHIvVr1dOS4LipK7 5TBsS4mUEqiOqn5jkTT+Gftv1VvEu3pEVO9EGBRUAE8Yo0gWnWYhoWOjJb28i+u7ZK+0OsKUujN2 iAq56L4iUAHweo1VAust1iIZMNdQGwFSQ9PQgO/s4zQnmgk86jLzDSmyToAqBKkRjVQSzqiRemvK WrhBJdtQJFt0cYD/6BDwdtAHrBBlyTpY26bLuZN4+fhEh/8lBEgA4DbgjXWJFXhO9VQLOYTBLNrL w5GYD4Ro3M2acPK9KjnwfABTV2YyyWVG2MBTm0F5LmKT0qorIdkvsgUxMwOGlH/u/Ou10WFxWxqo aXpQDJSrGg8hCemgpND6TFag8yGtTGL3ySpyc66k+zUFFoFD8GkcI36hfl9xlKnvMsKknxPWTiDK z4Rlz/Dp7xzCbK9TcyrTiQ7i0feTzDq/ta9HQ1R2zQuFA2tXRt3irguTgPK6jnD1WZPQNwoJLx6S KX4cRVWyT/u84d4MCDizLyA4v7sOwEeY2uPhtzcDmRWCzciDgz6QBdEmPm4tc4XgPi1DSqFr8CLQ nN25sb33QdbB+y/tFqJe6iVXZ0WjD1C7ubpHqBk9eR6VULp2fheq88+ZYO+skrmIv4ILgHaAojD+ Rn5v0bUpHlo8SvfkHfK7w4ynYbZxl5hN8iL5kQ9Ps6YhORl1XEi09xGJCYAEkTW8jshM6J3klYId sGaLqtZFlru2EBHEeAi1ykjEXhAnSxd3wF0dzp9tU/vjVxcuSvGCV4kvcexAE1MYIpt7GVgohCrL cVIPhDUB5nQaR8IhtLLWH8FREoab7fWAnyxvFqMK90FYKH9JRf06miDYJjz6W+7nh1Ing9aMzIrW OpdCIosCQY4MTk5TXRLn+v+V89K0gl1ywYsrCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iaiA8PAog L0NvbG9yU3BhY2UgMyAwIFIgL1BhdHRlcm4gMiAwIFIgL0V4dEdTdGF0ZSAxIDAgUiAKL0ZvbnQg PDwgL0YzNiA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0xIDQgMCBSID4+Ci9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdCj4+IGVuZG9iagoxIDAgb2JqCjw8Pj4KZW5kb2JqCjIgMCBvYmoKPDw+PgplbmRv YmoKMjIgMCBvYmoKWzY4Ni43IDY4NS45IDY1Ni43IDc0My4xIDYxNy4zIDU4OC43IDY4NS4yIDcy Ni44IDI4NyA0ODYuMSA3MTUuMyA1NjAuMiA4OTguMSA3MjYuOCA3NTkuMiA2NTcuNCA3NTkuMiA2 NjUuOSA1NzEgNzAyLjIgNzA2LjggNjg2LjcgOTcyLjIgNjg2LjcgNjg2LjcgNjI4LjEgMjk4LjYg NTEzLjkgMjk4LjYgNTU1LjYgNjg2LjcgMjg1LjUgNDkzLjggNTMwLjggNDU2LjggNTMwLjggNDU2 LjggMzE0IDUxMy45IDUzMC44IDI0NS40IDI3My45IDUwMi4zIDI0NS40IDgxNi4zIDUzMC44IDUx My45IDUzMC44IDUzMC44IDM1MS4xIDM5NCAzNzEuMSA1MzAuOCA0NzMuOF0KZW5kb2JqCjIzIDAg b2JqIDw8Ci9MZW5ndGgxIDE4NTEKL0xlbmd0aDIgMTc1ODcKL0xlbmd0aDMgMAovTGVuZ3RoIDE4 NzAyICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnjatLplVFzbtjWKBHd3KCy4 O8Hd3Z1A4e5uwYK7W4Dg7u7uwYK7u7t8ZJ97z9lnv/v3tWpVq/rQvsYcY87VqhU5sYIynaCx7Veg mK2NEx0TPSM3QEZW2dDGkYtO/quVub0zEMBMz8jICktOLuwANHQyt7URMXQCcgM4nMwA8kZOH54O AGZGRi5YcoA40Abo8KE0Bnx1B8gCnQxV3O2ATABKw7+Agq2jE91XQ8cPNdDG1NwGSPXhImxr5+5g bmrm9CcGCx3dn0h/vIXoAVKGRpa2ro6W5gBDG2OAFL0sPUDO1vVDaA6gtLUBfAWaGVqZAGxNACpA DYCqsqiSMkBcSV5VQZmK/iOwsrOdna3D/3ARVlZRFacFiAjKqYgCgGq0AHFVZZU/nypAmw/+prQA OZUP/Z88H4Z/3GVFVQRVNBVEmRj+3AOACeACdHA0/5P2H9w+fzAD/Ifah6uJg631XwkAlGZOTnbc DAyurq70ps6OTvS2Dqb0dlZ/8VMxM3cEuNo6WAI+rg5AK+BfhXG2Mf4op5MZ8F8B/qwJQMbcCGjj CPzjJGb7L6X1Ryk/nD7kTv8m9lEIpz8xrf5lDnAEAv8rjZmh41++MgoKMgBrQ3MbJ6CNoY3Rh6GT oZOzI8DgL9nHG2hM8S+CQICws4PDnxyy/6ty+Hea/6UuZPtxZzpWnt6Grv9cMUMbZ0ePv9Xmv2/b yNbG0dzRyfFfEYEAE3Mr4B/2jn/WzNzmL5msoJykmKiyCp3MR+PZ0MnaflTHht7Jzekv6z/xBEVk uAGcjOwAJi5WAONHk4raGAvbWlt/sHaE/VM+EfOPOjnZOrgz/LOtLW1sXW08/z9iE3MbY5M/dTd2 tmNQtfkjkxT5H+MPEex/ZKZAJwAjAGgPALoZmTH8SfZXr/wRM/0RfxTB29PO1g5gYmjlCPQ2NwF+ XGA9HQ1dgAAnB2egt+ffFf+NYJk4AMbmRk4fbf4xKrB/RZe0MbEFcP1L/MHkf1X/0wCUf40p1ceM GtvaWLkDjIEmsAxytk4f7UD5/8+U/SOXmLOVlZyhNZDyHxX9p5mhtbmV+98N/2GgDvzDlFLO1sHa 0OofOnNHMXM3oLGCuZOR2b/K+i+5pJPhR98L2phaAQF0TMz/Eqr+GSarj6792HnM/2xcHyoWpn/o PhrSyNIG6OgIYOH8SwX8KMM/GH/U/g9fAIOQlqKqmAjNP1vmLytRGyNbY3MbUwAzGzvA0MHB0B2W 8aMPmNnYAJ5MHw1tDHT7q1EADPQ2tk4fLgA7ZydvgImtA+yfxWRnAzAI/hH9C3EAGIT/jTg+dNL/ RpzMAAalfyOuD0vD/yAuAIPRvxETIxOAAfg3+OFp8jf4Edb8b5ATwGD1H8j04Wv7N/jha/c3yApg cPgbZAcwOP0NfpBy/hv8iOzyF/zvwir82Vb+mhnG/1T6f/bbv7Cyk4OtJVDd3PjjrPmbiayhk4O5 mzbjR8Mzfcg/Xv/7Tfe/EpD/Z1b/5i0kZOvmScfKwQKgY2FiATCxMbJ+UGRj8/4vX6N/bX1/DdtH S/wv/rPvAIBAN6AR7OK8rdGXQIvkhuBiH9G8qRIIci76kzJMPg2p2E+LaVNteNgiOVskQP58/ya/ 9M/5tjIS3Lo+if42BRrkgRhWb2vNCeWTN8aKAtuGPrI+eIiigqPZavSqAemyC34lHSRUh1LZuZqF rNPpLbEthADV0SNhrrbOx0jmiXeUqyQSnZKWlR8Qrj9nmRrRHaxQ3RaQcdvxFqbaQZ3eH9GjIwx7 BBepZwxygzFHpSDtujvRdkAjfvI/L+SzYZ3qQ2BGkBxY0f0ijz8UC1EkU+ZXOYsbkhmfJQjJsEF0 2AQraIn6ikmFKIRY0JuDmNNg7Qjh8N2cH+5Z6VKf1GigCuLbK995lMxIYZrlGP3dIClRtVCqc9Zl cVPv18jUsUyV5Z+xpJNNTSBNbqMVX63uIMpuOJigxXupPhep7JYJBok0yMoSJy2Z+XcaFRLvQZVM kDe/kRJGB2Wur+8cN2v5yUCjMZf6Cf2MtGkgYBi/z4h7ZHHK8T03oh86IYcNqjvG+enH8H5XXOyk UqK9yG9ra2EiWOO6SF57+E6+kmEkSEXRToXs5kWaf/5iC4BrwCuxFrLvPxxD3c6A6KMq8ZJc0HO4 Pkok6dZlpi9r19ejyUpylX8fssKAFkOaa7DJdK2IoDvkStWZK8StBmW9/F2eTKGCzw+Z0M/jMtAj n+MkB5JWKUQHGVSB5xVlB66vSNth08CtEkncTdeoNVMDT7opp4ufc6DEsNB+snsVsrAVoxfCgjlt erHoEvm9pGman7eE075hAzZKs4Bq+iBONob6W1Q48w+IO7DHCW5Rq8QprRzS0Xx/99Gxp7yGRzAs JfQm79Ei79Q4461pK68JZgd8hiWf09dPiZhXKnpmy6Dxe64DV+odq5u+tD/3DHfTBy98FNHfLDlN Oo8vXEYPzW57ABnjyOSlGp17l3ueot89+ZQxkjeY92+i3iFYo/iWwY/Q54flG7302rt45HMQZxCT ekPAQjGJwxw8vnmFo6e98HI44F3tsH4Xv3DzuLmawpjwDgYyz6CICouepTyKT4H3sPjF4Undxmfu c9peJ8Bv0V6qetKX5EO6R1Jx7871lrFBmoZx2mFY8D9fUnaW+sjSElHtMK1SiQsAgcTRuV88CNPh MLycmH4oomHdHCeh9o9Ne/vX75YRQozdYSWnxu9ehQ4gGijUaoDmUWRTHy4PesAMCE7FW84GnQ+t icw/iBw689rwzLCRp7xhhu8RyD8qMv8eBIdFqmA6YBz67aX6JDYJJ/VT4vL2zPcXAVHNVwXzXXuq 3YfSpYfPnofK3U9ayYPHOIHbiIPcG4jJZ3XS/KPKflGIIlodqtaT1pzprENksxC3nGkW/OfFdGtz HSxnB4DHyvA1XGn7Cg7DeU9I0W8vGAsxX2qwvO35rTJtMnH1otuu6QCISJWeMZX1WFgRmW+aE+Hg Nl8gPdnlkLw37RfbfEZ8j2g8Opg8SvFTGD6Tud0ODgU0drrfAvSz0ggHBSmnRfyj/a3cVBUy5py+ X9hDLyaGehxlAmr7nP4PbztlvQRY5PM0Lzlodc3rGHBT1b7OQ0fbr+cjhF8Jpwt0TdaXASmhnkOi e/wi24SxSojRMfI3vzgVI+eM0WFLZRJMyew5yCRIKxU/jR4qC/YFu7DS4nt3dEgVw3XrG2SydKGA eUHrNKei/DhdENZHiXDPYK2HFthYo25FKCEzOvFmeseNk2421G01DV4HktRV3szahCsB8GcR8FNc 5K6VgmLPILtzdjuwsvh4CmC84q+wHhSLtxT7oPZUh7sYhUEeVyG5QIdNiVyvpYyuDfvVs/o34DWX TtarwWXB0W8EjU08v8djRDkwwtIpLEC7qR9uOsjz333vmqjcPoxUjVkCk48Ql4qqF8fIlsWz2oU4 /tmotacAssqqR4uiU1kQSakcIUsNdfXAHUV+c2nup+p3c/we0kyNKCDweFuApxpKyKveIb0ZUGdw UMjAZulSgOH9hh13DpUW3g+cnmjcbkrS5HVA6DQZrzETiXah74fKa7FftMV+Ab44tknImMtkQyvt DEXaW4DKc27T1sdh79kPa6U3U3K2yYAQq+Px9AvgKCCsuIerN8xHHuvl8KNnfu9IdHKGlrP23mej uTn1OtQ9LtxjYFlAq56hcS6dsLCsYrSLGxOEgKjioazPmarqUhp3cX9/18QV6kPAjpZjlBFDfvIa u1BkWCUbZa/nkB+nurHjqU/l9Y3wN7ZfdlLoGlnqAzvW6fKaQcvV50Ykd1VMjtKGy5iZlqsCLSQ9 03SUwj5GHfdSWS5+6HOJxm3fkiq974Qa6k+9UHzAJspdiqrNO8sGRZSJ74oezwkC+sQtRqWzbBbe ID2ecUO6WFcPahT91mJGse0W7vEmLOReljrKVyub5C9+1UHw3sLx0YnBaEOz7wzThgvQbRaoQdXB fAwgCxcNs2zhkboTJb32xbJlVttKmabrvxwhkE64WKT2CBPBhLtPUrzYMn7Asuvj7mVbkAR0sRzX 37/n5eFqEYJvPlgnsRyN0blbFozgxT9RfOsOs/Nv1ZAMxMpNY8lOzenI7uW2o/MLK419lYSuZvuy 7ihBWKrAVuibbjWkOVEUMaEla7Y7Mo7Fr4VSNPtodqi/ZhVhmRMjWPRDbytK3cHU+uHqDvxahH6T HicbCY3jdzkva8h7vqXKDKOWGFJwxILedABxKDuwF0/ZcPUbrSIbcv8jlNKFU61bFUTwQ1GMCGfy jfttj2dZHChDdRWJA/Pe244hmvQawmORuCRcwBn9x2lb+L6RkowWQeEKgbyoa51a6zDNSk+0dlrK xlsu1ojN1TOIYOX7my/GNVGUlwEDnatmAl833IU4coc3n5QtuRxtHltdMdV1VbudyZMV7Bf+rH+b bfXjZEKPuFjv6w9f2sAwcRQNzs/UfGI3LTNFFLMMT6AY4GCgMGr9gMKbinQcc5eAnYqiKNpMjq/D KJXQLcgzkOGaXg5KE6ZCgl8OVIxj9jt9jISpKkyMnwBTHufWfb3T2oiWBUR2MiX8vwZg9CFoT0Ab Z1KnklvG7oY3EXXQ18Zw3AWl0fHg0MuO4BFWKubNTXx+8v9OP8W928nVHrsFEeBi5jDXjutHjwZZ d1Fty1P2tYeOVp9JUkvoWma7wVGcwf8Wk/QJsPACYflp3w5s4mUEDOVgQTGwz6j58ZNA7AOCsB6a yWm7Fp0lq+limRT0a2jrJeF1Q3Gd7nxaGBkJcDoPKWMtVQ+yiB6RVxYS8+yMP0SRbt+lePVOXOTh SOzCsyl/g+IlTtqxjNcrUxnVmLmhdhXr9S2HVw4+zhssOQNzQVEmv3i+exKGzYmTjllN5P2pCHf6 EFtsLqOlKc6sYRTqmxlyKpz3wQ91FfGx61YLA44cpMuoo/5R9gexcS+Ii74G3u5uRPDmGRlTipJJ 9FAmdnq3YI2uMYh6uDlFuORJavL+ggL1xJU9Mk1oYk0B/whEPM5vXNLF8wEs8OyvBk+gCPtV8Gb1 DDwgtjL1J7jtzqvvibfGxx6FGvjPkHnBWKFUWQfrZHY0G78z/DW9JTvBqOmCcMVzlyKFs/0yMZZc uZ7qFza+LFx9ezZjHjodq9Y1+3yTwT7yGs78/nyeXMy9U8Ygytg42uPkkIFODflLAHzAvlKa9vvm iCft+UKbMIlZGV15T+KJLIqKEBBBh+cC8ZMK3QEXOqmcsdCXTMEIERh1ZPETkmJ2zXA9hZfIlchj 0jBylTLDn9DPU72cJ6XKg7J9B9/8+Bkan5nueuTCQ4iCJvxlTxNqN4iqDBp3vQtPlEfIR5G5cIb1 nuVwFJP4H8PaiJS37cKQZFhAdSIFveBZjlUac+vJKZbJLJP5hZGBq/QDbWaZ0vLIOtGJak6l8lst 4TTlXgymcIvQvs5Mkp9gpshHPHaNQ7P7OXzhrMqcbxYsk+36aR7znlo6fBO6NrKsszsfdwCxJNq/ aixCb8Nxsu2Haw0tkJwdm6jNCFBl989YbBzQXgI5hNBlxL6EzgQ7tXvTJ/h/TW5n8H0zgDllFXEv MtRhYONWQTozImC65zcDLZoV6fNtSPltpR4JkhBUeb90cI4NIioZmfm+YHFdqr1JXIjhIWRKY3mD fV7gWCC4kyrs/Tvl81NqY/KEajO8UYucQEuUDqy14qlN2y88BbORUb8fqTvfxLnZ0jrhwWCLsrOc Wuzs8LBX0yibT9UuFcrVQBDITl5cx8M7JaS7LqMq7nZlGRv5h5/d2BI7KykQdX1uXRaTdHsFjFmh a8Z7Y/y3zQMHlLXEFOqpB3g0ENM1GJznRhqrq+oZh8Z0BHGRLB8VJbgqWIlZMyRDorhE1yhBkWcw 8Ycv7/bNlMMJLgxbvyjFLPdvfPuxQYZfWQ53Bp5X3oyTbC3beYlHZvHY8xZH/b0zBjUAcLvPekS3 9zAuRH6cMCtsTr6+wWNCqdGL37p6hDQGeP09FsBGra8rYqMXt13gVUOgETNAuwT1fQdaicXgNPi1 GcKyXVkysD090skKGyR/aEAcQgtJ7/l+4sWA6Ii/B2xIPBwRX6RqER6wNLsem8cJWxS4P/o5V/h3 iaSnffeW4IWSZBVXYHGtOWTjGayjTIyxi3G9URPx7QUGd66RYIlWz8rWnkDcykI+H6sdQovp6b5x WOpvbXgbNeA6DjPLsxjLW70Z6kpr4ddVHFdpDq+VPmtxhcyto2vC9lrlJjP39U1s7QtpOSUvOxsU Ic3HBDo4RppP5MlWqEOIsmmhXzN3fJS2TeKX43axZD0x5OpsAreDitGZUMwomaj421KXTptAL9A1 VRDxWnZBMWJDVFydE59DcrbV7q6tnV2h66j1yGOU+yMit3KjCtBQ1mIhD/EigzOy2tYvCLrz3qD9 fMHfnSU+QXGYru/W/N43yKbXfvJ8TWle/8r1gjrTXmlvn69tzLqId2G3SSsy7dv0fEvxHO+OP0ht soPVaQOiSeRGVgB8hgGJS6N6oeyHLmTGbAlJ1FrorNQxlEWqwsE+aAk5Ji6p6UsYuHun0MXaT0zH 18cRE4NK3Kin0v6m23m5zB6KGYTsrxZc6Pb9mtb7S/7iPvoj+5bv4i9u4K27DsLPZXRNfnVoH4PN 8AAWTk9DqfhajSulVgWIM1vxNd3vlGiVcDlOD+BKwUlMNz/Zuk6F2btPXpyug3XaM6/bw9hPeIc8 ZPlrZ45QzxQLoQeO+LbF61bmO7yWa4RhkBqR0K1EGFJilWLPLoPqF22y6f1IUu/cIShRgx5i3t0G p1rjkRkV8n06ZOe68wsFJvCvBTqhwYgGEYjMonDkDBkdLfK4lW3tGa+f1jSdkL7TLGD8VgMq6fUs v7lHWZhpIM0Ou3vytqKqQpQ98X6L4h0xE260TOf36k+vxaA/VWxG5c1ZQhEeScujpxSSdtReP7Z3 EzRCwh9uouHSXtkM1SLQZxWs4u6lPajO7TLAV79trLb3ErVZTBpoXsvCcuJ2D+JkznmqI16FT3gr gr+oO44T5uf4sWkOpMze8g+uPOvTebgtBZdbd18mIM0ZFxZlUZrrL+Xjl5XVKU8Uzitv5wej9D3k as+WQsXBw1AJ23I+2vmyR2X8bGdxXIwdr+kRbEuZ7twwQLratUXk9/4ulscP1wUNbpMHwy3lnmkl 7UrHy2zbDuTzhtAOjRNtNTE0zfZ5xDGtJLLyukcpURbtrXHDAfvW9lN9vMHEV0FQPkRa4BjkREWK xol4eXXvu0uHwgyPQF1NczwK0TmnIw8bhaIqJ6hteEG5xCJblnbASfh3CoI020KVYhJFC1PaQ/Mu 8Wsmcw/Up7t4bFe0bzNXrGmDb/HK2dJU2GioPTHmHQUKKBDDpd83hZyjHn/ceD7AQrIjXiz4JYLp emDI+ZaYHe+k1E3NH0vUnwOzseOKhnBffkjYyXQzMW/9gtg86dVkZeV/dwnL8DLvXqmDtiWMGpaG dZeFxFfxicZKKZBPxXqPiUz+VQRCcUCt5bAlpHnosvfM4v9x0H3to+KnZSjWRX4qkn0/hCVDvHEq a82y/CQRw1H3NYspTlaO4Kk1JbjJVgQNRbqmNpSJwXW9SjwmRsG1dbA+Q0dopOYgkpSvPKCnk/XZ 9RcUkGYuC4RWrXZV6MshqVGDg3X9htrldUPZOJStKYumIehnuXlIAdAcZjEF8J9MiJ9Arbh3IVMG +BjHsdhgqlkV8Raq+Z/8Ou3dWC7M6emqpFbfCaV+GXZ3b3pcA/gepliYo3Cc0uAslE93RFdR3sng cO6erRRlSQvzbwWUnCHV12gt9sC88btqlN6z5i6mjxtlyXNlYzhG5iMd4TUfYq2nsbZ7eSVwnA7L ruvC5/O6jmxHIRmCsAMUmg/JHaHyT3ZoaWr7/AdcalvB4s2MKMx6UsLjGRsrDqoLIve2p419wkcX 35xQpJXg6vG7svK3qF/7avXQs32qtHra3gJmqGbylX/h0kJ2n7vv+NEK68I05f+OvVc7qhW905ll 2PGNfW7sujXoFfcyYe5444ymFZC7prHsf9GBBdzy7hc9iZ4sZPQQdMipc2JHyL/M20z+Zis2ywSR ZCndPQfvVfNNEJRvYpEReivVqGIwPRztDlI3CgRAKoQgwaVxkaKKCWQbaziQjual1ti2WbVSQOvz ZZecok3ZeAx7cNqwvJy6BH3ZDF6rokr7raK+Q1jaxWY4nolLd0pMna4XPEpC0Or9qJbfgWFvqHcQ CaHXNFvNuD028XNNOl54r2hwq8A21vTAMseQ4RpzWTBInaVqouX5nradZyvVTMWlQ7zcvSn8V4OV Dgd7jqdKnW5yeMJohpz0VNPjQO3AM5Q+dlj2zdIIHHTHiWyHi/v9PGzDapckZz5tgl/812zV3evl wiuUXljZrnAyRxHqKnB2Sn2r0p868p6CUlxVZ/mQTzhuTyXDKuyKxcreKIQopNbJSotmltDxrBDL DVCTuJ+O7t1qcx8d7Capi04qB9Nbl00m8HGFmqRPKImrE3uVdSbcV7maQz5FRXewmkdJE8XiJOxo uDlDPEZwnoy0ct0RV8IJcuN6+CFawmsGvKLvHGLOGG0Bmemeq+6Uzvb339KJWbfPZZ839sW6Y7Ut HBce43pMI6ag5QmeEHsqwoMcNQa6i6meMlLANfc3xLZiAy4uft3PQWgLWeKfhgdTNS+53JSVZfk6 D9nsqkP5lPSkjh9ayTzii/pbpnWjW+I1lhTKPzIIOVbNR2znpGIIaNb1zpjRA5BD5sgFTXMJcyHz UrlHD+5VwXrnVRcvqSJcFwZEno6+pquokUOPu69L7qU0mWMZ/3q9J10aD5z9YUlz8riCbQPH6n6i Jte892V3gtank3D1IhQOfyr1xfwSbAn5K+G05A/pM8bhLpA7BS0vrUPdLFaFfdpUAZtR5vf5DewD 09dc5U6MzfJWiAsx9NVCyNUUyUFxFy6G8tLBQnJQEkNsIO2RKDYdNpa629FIrgRE1WCc8FLstB1+ Y35xOmqNbJcXQ7r7uQkjHH+CAwMsnqzaJYY/GEZofBi3vln9yp64uws8Ohb8YIszyhP3xhdRYq6b /V+7Ka/GaCMEWuSefVK6TbNfSeShZXuEGxyHI0PRIFvyfaIrZtBZHYnDbRQf6DvuLffHwv0SfKqz kVDLJFLjCCa/gTRhc/LvKtSu45RHc4W/zhu4JYkz4WIOggaeyP12TgUpsE3VWUA6KGwYQnhbzs1h Rm0IrfWs9Kqo4CmAZb4wbPK0cnRvfViH5/elTJOPH9/rmLGp6af5EXXLtAZTT2MX/zvoho/spbFp BdqJKm8+FrOZ5drkPh7pxNEokO+rWp4A6iHUrYd2jOc9hD/NgKeRJGAr7JBrFeRYET9Pym5RRI2I 4Bg/NyklsPY1OHHMR/arqGMBW4Om4gq7rctz8R1rCvcoLtvhMPmFnwGGmCAWIYggf5Cm7E/E3KLr vbnWH1tMGcC9MKnWV8RDNasGz7j1aWwphfCfosSK6uWYY6Xu5MypF54+iEy3alsbOE8tygbNAT42 fSIiiIs7JJ/0RfM0Cn98Nc1SCoKlogYxgPT0pjqzU56RGsiga21+B6lweBQCk8vM5Lz8vIUSRjGK G+ruk7mZJ2dT1go7+lINmo8waDanrHesYhplVzlHp21EFSLphmixwMJPmbniIRn/aWXxZ/NT5bGd wFFSXFA5CTUp3wB2ajkJMvVecFC5ZUNXppMn3fLV+M+SJGcTBoKIw0chRfHNJM79gZ1q7DETfelg Ag6TXEGBT9VgegeYRiVqRx33fePbAM0VFvbIl/mW9MZNM6zxgCjrOrjgfA+KLpYtz5KRGM+p6N8N 35RGxnJ/60oYi+2zZ+6EoOHuc7sP6BOu6HQt/ATvwkUnnytQ8mI7LWw2RuGMxnrOCE2sK3XO+/GK 4FWFq6Haup8gnP/9pjZ/wjvStr/T1bpGzAz8l3QYRgQZfyd1haf1tgaZDK1i0rvGCK0paN/Mdqo7 GMP5ReKSBLVctoVCe15yXOUvTyVF7nOLdvSQCGxcgT3DoHquLyE2E33IKC4dRlYNbhXYud1T5j5D qmaik8mQ5JKdQWmsJ2thN697moJxYCuN87tQ5ChHepuUyTVqsWv7JvsP5ccWZBqBYqq0jCNVoHOP S4FPynCR5yJylwUOUldgDPtl+sgVA6zLWnJd4p95bWcdyeq8/CcQsInNyta9zu3Ltpl+XZIrhkt8 QhAYfZQr2tS9v1j0tc+/JFqN5e7YCn8i3PD3JzrC3e4pEesvCjTr8fQByfYZ2JBA6zfITdiB2ecT wz/DOYlNdz5FbB2r4ru9/FLTd3GuxbYApGXURafDNyQUpM/BtYR37UsDxxbOp2yjdj7GbJu2/K20 pl1DMDz40umvy9YMHnFCTM04y0V0SZIlH1gqe42mcUGsMR6YUNGohjFYdCeL9touX1+Rkl95iXtx 77bEuSufTGeB1cx8fjK+xrtVq0RobVcYycSfyvBUyvjzLL8Mrb9y0u2cKDnv+egRHS441p5NLHoD 8lJzhiqdV/jFXnp26UHmTYGEkS7SryKzxxqkdcdbcZ6jKDHxpeuxVP5+qQa3oBZCHF2XRclQgzZm sFTBnhLxhU/TZ3wjVB7JtSRZggDPMRKS4ur5PtlQLUEUnixw+iF7JzTz5+Zcs0jTe8lmOnaEzpSR 0v72HXtXCEQy8c8grvMCuY4Y9I7tb201gaiw35LrfxgYR7uIQO26qGUjo0+O6A457OFfoPL7MNf3 FxhKtn/3ub1Y/3KWO71pEpb3e0nQK8aqxc89vhiTAqQtDVkvC63xZtVoGxTL/egKmcjbIGmbYEpA GxxFurRn2myIpaMaCaDtlRIkkdreeP7NEAINdkuTdP/Ytev1ltLUr9eFN8PFFb/72EdR12e6Og+W F08miBJ4g3WUH5jvCn/ZmdiS8ObtRqlDqgAdCdJv4Y3pa+WBLMsK7ajdVFr+Kq8BpU8v5RpTzDQm LELExABxf3i+RvNJ/ThSxbSLDdXGDVKnBmf486yi0fHdAeFFr59LYNTKmfYSPz+nEMZEFKmN57eR cJZgvY0NXS8MUSWXU6RxeQFP1TBW/0m743QJvBNhClh9v7w49/6nVaKv5SVYohXzBEQ3nHQOCF/I 6joMh6KEUjAo6YxITT6J0gfdZw/pmarh8Tg2Ty8jRdjePQVbjtyQcY51J35x21+cZfpRnyPlWCn1 rQsOxzAtLkdKmLnCGxzCOOfcqTS+js4wR2iRo6Bn1YsUsMIRSOhya2d+iBVRMokK/em38B6b45eN jOXXl3T/8obPoPlhF76rZen1qcV6RPivQKml2zUHvU50CqeAapHdnLYSiXwHEDzBoLnP3D359sP+ GuIDgE+6CGOTk1e9cnaauLjoixZmmnnhSr4PC2c0GzvGFtdohyDEVXzZSqT4R7ZE5Ew0gtXkdfnW +aoINfCfcd5YZvoG99nyykYtBbZy45BlgbaWmGv3qbbOg6k3HPvyiNhac9iNO2K9nzBGCFp6wnuB Py04RdIatQdziUj0v/WZWEKK1QnFE3zPnZfLOH++2HanJs4Uj4zV9r+uDZ8BC94oqt1h8OroNdmD xxa0EhUS5DkwEPP26qq4pTWDi7h0cceYUd87G7pWCvWNrOK1e9yLu/iZhwmKPC4mZTjUnwEzb+Co 4RerMWxRkNFMm0RqUeQQh/lurPjyeoq7yseQQt8BCC/eFFEmVBotqPlk8T3Ul9YgVwozQdHXTZwg Mdx/xpq8TAD+tIXjp85NO5yrAoqBocUIghFoX9/dgpLSD3lwuzr523OdFqP6PfhauQ1KXANI7kJC ieUwtg0dmiN8J5Bt0f3RHwCs7z5lv56Nux+ouKiFYTuGxhDQ1DsySlA+b9RkTHKMiOBkB0Te+xgq sseu2CEr6CDhp69eOnnlPtolB+v8OogD2VntElY76WQhz5WUJr1x9IyKbITStgHqCzz16atYTrYU 75rd1NEq5SV2TEL3tMx65QfeCfg1WruLnz8wSkpieLsO4nLqcLuuIQdEUJdEAtFkJE/HnXARZ7Ru fG+Q6HIa9YqGnh3UjSBfV7J+lO2k72kF1wCPRs1uNKJhnb+ql+UbqFhf3zvN+Iv4vzvgJ4zc8+pO LvV81fxeebCaBYctUo05oXOwcjMYesFcgwK/YNzFaxJe698kdIRvzdHrBmzGloqB5qHmRNS7hYm8 dTpd6b24QYMVqJiDJ2H6XcnfrJVaTEz4zspJloKJKK1W48QEJjuTwWPL+XVzCcN3pk1raiogfa17 hGmCE0rB9lo9YYpigpXaJL/HC/rE0rytnVHQJkQwIbevRFwLwyDJne+mQvlrw8qLKO95ceZdozVM yAopsVuObzvMrV0+WVZogwcOuG1G0T2vytXtyfPNXgPVViVVxueVWSMo6svA/N53VC3Qsg2DXYLq kUYkREZdnzWfO/4ArYhE28hUfHVKmLNgouB78MivPvHsEIeV7+9tP1FcE54RLhZ3jfvkhpmF5Aeh VvZgCOz3q+rNro/LMao3toJ4pHCzziPyHI6J22dsi/tCSS69kO27Bl+SWIRA0yYda9+ticdxPGU8 nRMiN5xriRu5E/GCZEOx4I8ob6WNudM7IGW/xHHg8NPkEFvK8AdC4Y3yF1H4meM1K02njRkyFvjC rJSakfqT6fZ6RyUKWMY2jkJWksjFSATZrqF/snMu2iM0pTZOWkpeNJU0dbesTDKUP3/QkqjNo6DQ 90oT5m6FT6xKHNxQf1u6ZTOckgr6HgG3QaOYED98dq4A7blvRD0wfQgo8dBRrHXneFwHWeEZTT7S zDO2uGpii6m5LOPmx8+KFFOhzNUb7Tu1J0rmRzi0FGW5PWyMY6rMvZq3HbE3p18FEYr9snQaWfh7 CNQaqW10c+iVF1X8rkpLz0NcychtNnSNMQmcHOY7wgFKfR+EAwyzWIwmU+szdSg1z/dochwhTbWW YDR1cosDMmLBb7953eWd7vw2VPgbdTElpwopHek5QIs67fJ6HgEByGYwSgtfbXqj5m2182HMiL/Q 9CRijFXkyaJVPqxQCz9YxDA4QT2OTdLx/QZVYruZw8d35jtftVg5Fl2XBbFnm6Wush+qVhTuysvr wWJp0kUNqgKd0qG1K3brWyL/MXZSrpAB5aVx7+9oqBPL5flodbkWkhiVgO6WLA7uNMMGumQQph9j g5x3bwl04WHJlezhCcZsMhlTW7RnD8wqvQsqYBUmyB5bH5VCSRy0sJhDoTEhyjR1VmrGzbiXp8bR qzhbwhwOiV6xabVWMDLMMccEYg1KGx+Ffy+L9gujelL87QDlGuruQRZqQyOTnPgOhxSyDUeEsIgi ltL6FFjVXKiOI6xDS71Rw5o00qQCCpv54OVmW0pqUoRa7SDCdGhik6f4I3Q6WitatHm7v7IXV/BU fZvEoaBFVLjHhfi1xS/xpwfiXCbRwr1kh8guuifEXalnFvU2T2Ol8+yAoHa6Rk35mq5NQwFPi1sk dlWyNYT/UcmxoOP2JG1jN0Ffj/MyLFT/LuNDcISybJK1yDoYbkizxpU9E5kHo0Wm1N774W81iurV o9QgvEJqGCext0iVicPR3qaweyQrpWUcXCjAgfI7JHiIK0kI/tqPZUpAY3rQclLx6T+evwNfxBem qHeEm1yEC8RYxkw6kUoo2sh39C/q4Ai2VCaJr95ZrvEotNVRXi1JfL8BvSHxW4og4gjkqhuphx64 zX9W+g/LVo7Xo/Fp6cIp4Dxuzn4OZDYG4EvWX8Au4KTogm6qwisZNx0jcLF/l20XMxnRuSciJE4U feLGiGpScXjdxRvfnKfhRA8xsjypPEXnSuNBwzHk7JnrBu1FM1OGAt0E8l5bUA31kssK0IEK3L6f 5nHv8WN1+5+PZ9C3ONQTIdSrdKn9WJ0+Ncv1GuciEwhWMNA+W6M2q29A1g0xwswM9b75Tcypjkrn vACf91vfXPiFtbc5QtndU3lPVkBVb9jGBT5A9Ed5tkLYZSaYcIrzeZwSdPbRTLAbhQuSXaxYJkIh rbDA1X58zmkk+peM+tfvCudurezCzYTgJCo6b8xBlacLXjemyEdQZHcquWFb2Grc30voUNZKONCn luZke5UC2be811vzo4H0l72VozhTOSXpGhOa0Y9sIt1lfjFi1U0yPULjHRK4oHbwqbQLI/38bXgo 1AYng3zFuxqwAeJ5lKq5LSGQi45T+kIz2/aMQhQndrxCdd2QsisH8vyqXKwV+GtXmdvszRFSq76p ndeIlyBntStv4t9u85bxDWAryyMNW+5IKAnjxTnpDoKqeu2ekSXFCOU5NzM/FwrN9fBpVebZLN4X 7S52THYIB25II9iedBNllaQEiZOHUMpUiL2u68xH3uaWwEjr3nS4A4n2s7uAJ+hkFhuGak3rj3L+ 027537jzyx/tjQV7F1s0JDwybyct+OplcLHEblAOe5N7wOGdN3/fLFRcEgMp/SpS8213D1HqufAj TcdnsD3xibNfPgtI9NW91J/WfcVW3/7dTyEV292CWn+Hx4oLOuuh/zJMONu4yQUyCnJoN6oD68Yk ty4vbBhC90QLPBaZGzWh2aj76gMHHiqNwQLdheOhdTEIog8Ex4RbVBjyYhx52cJ3Ok3gljuFx/sy Q+Y+Kru+7q1gPW7E/6DVxKK97UD+tirlESHucC3ZgxiPSlJGmoI/21jjvp0gE6mruA2ndjFlYnjS MPD5KqVccKwt0/cL0U8NIzqUJq6yBPLPZhU58qTMaUlRnEZrCIHRrBITiksHJ8au5yc1pouObttE 2dD85PYcnsN9iuhoMKQaZuTbRiC+NegmEu2RS7+VVZVEVDC908QIxxoMyXNIUnKHL1Jh+emSJw0c lcTOfwkIfWqdsODbFw7WFrcnS++KAxdjSKwFa5q8Z9l2qH3dFN5Oi9IslkTII0e3Zq5zD9OW1EU0 gM5OBtteFILkgzWtVJI8e8ggE60+iGZGR+KMP3+QfJPDKsgG268byCiCsj1RtB5nDEZV2YvM9a7U eZDTs0G5ikhz22E6Hm0HlWyjkkqjMoZ2umxjk4FI/z9+tzqmnS4NEUAMLpJSKng1udLbQWl4Y/Eb oT6yZdtTQsa+Er3mFpokkWf2mqg1PPQsBHR7Ljbmmt3qzAmxkeeAPqucLqpDFLPXsaf7o2+2z/rF 8rl0yCcsXkdtfVdw363u19W+y/JXCDXY/inidGjqV+wukfqj8tN27wWiq4F7YWb6G06SqGZADSOI Igspm/jZGuZRGTLZeu6m4bORAdZ+yTrEtygtVHYRjwRBAfnxzhlxQyuTrz/qxaydSI2uw9bdOYqy dnwq0+Pfp+9FUBiKFUiiXu06a2A2m08nEXjnh7iOXV8komCgVa2Jb0v8v/i/X4RPcRTZBhzQUMEd SJumSdOdf72g0DoSxxG0aDIyDtoUsydvPObJOldDBoXA/XyNY855kZHNFrsqQxWIhSPviAkZLd24 5FKJGpC1AXc8s69NIOxrzWE3d37ITIJf+q1SUDTIGK3JUtrWaIo7Io+mz5Ixh38Trc5iaKwo+xTC 8rCqL0nqwJ9zlOssMlglgE/ZdYgWemJRIe02fnTUE+4z0brPtkA5dxxvhOdYBy9DEi05uilRh/Bs ZcVqR3tB0zlzVOHu3p3GQqTqTU3lIRdIkIf6+aplaSsNBpfLD4JVfwprlxLXH8g11NuWidjOOgxl xGwHafcocQdjzDbekRXgo+R7JlJsoPrDZtJuqaWWvFNxI9naPoEEbVrOE4aiVvB5fhcqPXDp1hGx vz49fHP1+FX1PjfULcPaaxQRscptraQjac1V4vBtln/x9HtTbJpxjsOXEneR0k8OIN5E/cn+zEWz hye1j/tLRroEtZjeJpeB/upsbOxUJoTQjrQDaGQ/64WbrxMVoh+jWJHLC7zBlStFcyYEOGMcyxLO oFfwX7LgxdJhOLVDF7eXGy4TFfI4dlRXOivHAtF+HVeVmtLMs8hUgDCF6jZNNVKD7b/K8L0LLW7o yGeiaDhbjLIKcZ4uBvURFY/yIN6Gbnx+yP0/nvg5KLkYOS2WF8pX0ZNY9E8Ybw83LYbERjghjOOw n64tL+xE52mWekv9liVErrq9ZzzuIM1lVt8yrH/ppp5i4KA+mrws4NjXQJhO8sP8wg1JI8gqjqt9 dk8lNCD0s/6Gu2RYTaTXUzjdPbEpi2va1tQTb8yNGQPUShcKUVHkbPqU9emsmZLcFqkyWaQ1RCSe OS2QUl0iJV8Y2aDra6lZZqqpl5RWcjBCJiaGhrdZfpmHwydR0PuZ7ekER2XjiK9tr4k42Nu90d2B CApgqxyYjejDskjxLgdup458Med8e6Tzbw/KSM8cXmtt/pZZ0S4OAtNB9BHrwkDDcIoNGBbYVhey sOsgU9+aTX0CA6LbgRnJsiydqyL0yNUMJVP25hhsJJvGipGWxeMealUHzxv4UhFza79JUbZc3cSb nlUsNnLHYVBXCXkfJxqQxmEGbFcGUGT5NxcKXtiEoZ41dXK2OW0i1wm90UzMUnnhZIZHdbFEo6nh uM8Cu08HXDHusOuNsxV0m5TRn0x4CnvU6eMWpRk4f2dfgrIfixSthSxRZN/PSQs8qiTvjxnD/KKP +dXaKr0gyLiAuYyqOkousUkIHk0ZcHbTkNKKVSotqzfrz81obI3B7dzXsiF5eaW/NocFp0uwyghH 0nVxCx4PKEr6JAn2vdZ3oMTou/OSE2O1yqUuSWhcOSK/eM3xRuqjz6vCgSZXdpew9VYfwE/bbGFZ LotlVBSVpewqwHpC+8qW3sLnCMxLtBlpiZ/s0L2sMhkNDAPyfS1n1X7Yp+k1g3J2Dx7G+outHpgS j++nTBCL3TRE/3czgkOOX1GqmaUKxa6T4nKbggh2yW66qDCw6GQwQzHz06OndgSl99za0De1hmaE aWzcmviqFRYIn1edRX2FZOQSsKXO95ZB9VPRbg39XLucYC2bcUw2sX6S1+Mxles34A5QU0tfIJM1 +8JQVVaWc4C7oIvd+la682TD1ZGMvUvvf9aLUlk/gtxJ07WiorJ3inP63eIz7jotv0OHd1oM1zEa CiH3mchu6lIQ+HqOjwmLmacBrFK/1/Zo/gwTtIYtroOTLTxaWNoBvBdEkiokJOBM3Hxskl6nnTVd xbWdeNlwERfauGD3oqq6jirSHhbbxmLi8PU3rMP6yvjj92fpA9CRjo3ezCwcn8YAVo0f1lK7bxyQ /BsKQH2LcR7khV1JCMcbDnhfRy23G0+bzEONgG0vKDnlIq26opU9l6XBAEfMKbR2cXZTzoSJ9Gzh s1ci8bVyWe0A+AHhTTj2LicvqQiOSKO2vsQ+MOKR8YROfMKy6N860jlSw5LOm8I1JhEQKo9f+KrB mNbGTCXSSUVnzrcUi2mEuyIdM12Eky36RfddJucrawWq6UIAyI2wrEmzlBgnPRvLO8w7KxwxEqok ZupoyvnS3nMP73tmNiIIcTFKhAgLqwK9LKfi/eUqY5/uxJ5dP62vu31RLQggcjOspnTtC5CGufUF ojXKZ1sRxew+xbg/5W2xY90Vhk7JQaiW1W1vQYwa3a9z/tjsgA+IqoYJhYCtJi0exAH69tdqzb9A VQ4IvXx/m8OOrpyDm/4xlVvHopinFNFsX+n8PpvUTkaC/6PrIgE4xnvONowsyvfqs98h0ocDp17Z +tX5ODhHL9pVfkxrRkFvjJ7vadbqXkNla9QRVz3TYehK7n7KuT2S/XoNmfphJcW5h+T5cZhSNaaB O/CxcrOLWZHeP3sM6xiE2EeZPLdJvTcb0dXzwCuRCygG1yeWMO2DfV3ti99HPCOf0pB908vWrC9E UtTS6GJaTRUXZrdx4QpBaY7SIGaA1DmetIcUtSqRLtDF8OsmYiuavRj59sdulF/ymil1NUdBela9 lNnrqYgaKp0E9wFjBzwqzwYiH+EZFKbg42X5/cMYkXLNk/QsFSzz//E72WJwx+l8f/Bt10v4GC+b ljyPZ9M7KNolhysokiaHbXVFIx30IdWmEayrwhqaVHink5kR8h1bhaHy4mYYBHoonczk4Yx/AHhL ircJQTPlnkSyJrdKYS1ukUIQqvnp7sYLSK5CFvrizw7l0dcNT0w6XFIJNK3BaMjLz9MX1QJ9p3et Rr0EwcnO73uwx10iK0OjCvk/jBlcF/oAnMljcWybJ+5KvRXjjhkZQrowowp1dR2UBJRxk+oETM0e 69k4SXBhRYS41oVmh5mwXfpI7UQ8DFO8AyD4zAaNfuDiQ9nLMvyO2pf9ybY11OdCU3wsS4BY0oat 2spAjJDhLAGSPedgqyHXfkdiMlGr79j6yVRzHWggibMuOMqOoesVvyJb7W39qkILxG9OSpVFDiiS OHOKLO7k4KscVTKujNyaSDY9QIzMAgqzhUMA5Sre8vQH9vsLNh52JYwAyuZXxjILYy/w9dt6YKtk EPciXOqyaoUdi9/kgY0WEM3zNzAnb5Y99ExWe4qx+qd1+HMShs0MQsRySq61IYJyhQU+i/W12MMF KQXtr/XsbxoP+XMZZBB6YyDmPhOxbcZWMDjD7yDZGNa8EKkSe2HW9YBpgg7CWpH9k3HK5uhWB3xA 4kg2ZgC/ZimQkilMd9A4TKzy8OiHj3tu4zIMhzxe/UpSfTPFXfy1grXLMLZ8ZBEmk5aoQJ7OtfjS rCF/bMWeNModNfjbOWTrNVfLCJ1jdpvDYc54JA9/bP9K9xEqCYTDWWh+4iXDom4oXROY03yK3/EG d83m6kg7QQWFnAY+o4oSKNIsIfr5a3HiBkW34Ip1mgTfG1pbU9b3B9ETVbCK9HqZU6w1nYPMryGY nYSMFmVCQ9a7g+Va0UgQxPCL0CWethoMBo9FMNStqoaHlTzpHLKOt59RLj1KVBHjR7sv4zwVN3GR HeCAiIaSX50bRJir5un52+akFWLWy2bHBtgryPiQZR/VdUk/49qTMkMzb74yqMHoI1OafQYvSBw9 4+vBvRx6//KJC+/M5gB6NFpH/LL5xF+EhsRk5et7tsMamUCpCyCLbvW9AEZ5D/tdxbS7BtEFo6Ve oWjj2hp0x0/jt1HnRN3PaSa1L8tHG2mRvG9Oz5/54AQxqw4VGsIUfkk/HbZqddwVUDj0Ik54cgZp b9OJ54eBZxnW3zAEl6zjvYaLrLkdBVH0vi0bWGLgp8XaOwiBS8SKkDTsD/5kScyp9jTr88z+Bjc+ ARDJf09dsB6KRnnVWJzRuxjVRa77NfrlF0WTrL0p7KsC3TV6S4+lWC8D2He/EoVuO/RQPuU05Qgv 0MStH5AmoXSJIzEUVFBdijS0LvyhVkbAZN7V6EmO7s28YXWXm5/DzCNbwBRGCZpnDJPVsXYinXvQ GyKD7hmhYWGSM8HYkSaDk8kayLalzSefQU/+5VvDezsvMWe+ZpLLF1jwfviaOiJwSKs1rFMy3YDj +YWcvQ0VJnEDG5Xv/Sb0lzGHCrQwnryxpFtohhoRjQYsI8yJNPOeNhftRRNW4asN4UdciugmaM/u +n1mMxlN1zvmj78EX3KxEnhKciTPrietHsSS384ubUliOhkTlNP79Zab7S6PKA0rFOykFvCJhCqL elLdBmSHb4PKZlA2W5R9dsjGNq/oW/yYRHgaHjJY85fe7TKwkJcg4OPI0E2ymJswSsiCnGtXwRNf WC3nyGJY5RF1SP2sKCit288lVvb4+SXMlzJdR45lu9MBAUn0XjxcuQUWHPqghUaxAZt4JKtRIr// z3+Vx3ZRn5JWem1Uf+5k7X76bgmVDgkDPxlSf2FDlKI7D/WNIcyc5LowlTAsyNrN86Sl01ul6TQ7 AO/wWLHa2xaEUh7SaCj0hwobfNNoVIycM5sILKRKvATSEr46j8ympWtyxdZnBfHlYVBzEH71ZJMO OzhaM6c3lBNl6qAoTIKcXz21zW3vTa+YNuxJBpbt30c1TmAoLdRsD9a0WD916ga4GG+A0TF4b/bk NMVjR13D9Q3MeheDyEKAd9j061gXMXge7O1VRvxSoJwTCCxU2l8TkNB1kCNjN3n//FYHMdsNtt5t uw+wwoQunfPRskl9GZfLDPZwBrS1/7oY/9VVIRsukTsbwguhyJu+asm1x3APa4VBTSwd9NuncNVq E/2bD5UCvusEO9N35PmRkRNgZe5dZ0b22o+njWk9W1Li4o72YA11sgEVEZ16MuTMK1P3Hthy6EKy V2KZSOnHK59fMtaJemSzfuGF4dXrvPL8A5SPHgE8rmBdx1d5tFc8etGiFNSQQq5SHferGZrKpU+c BEjZ2hRxagegrFA+Xvq5OcdjPiFaxpgJJe8tr4ni69XbyIEcm85o+BF9IffnQV9+bZBSX/flaPFX IcR7wKJZK1F+/1q+tkAYl+rVVqOayK8hSutXDqO4AAWh4GdkZDFRCd8P5FNaS7zyiXPvhrgalOo+ 1YjAikAm6usPBn33oRoxy6XVUmQdBYvWEAZZaUx/MKB8UojKCSKuWjtQ4LiL0hqUmkrFyeD0YHLx eOs4oLmEeWbtK81GgOPPGTHI3fXIw0ezf+hxn52GQaYh9MAOylpDz76+8NQ8/clOuzbWBp5znGpY s5Brlknqo6qxvzNRnAe3oIGlsGZ8lSF2sbhGzQ5hpdeMrFrXG7NQQMWA0H34uJ4VS3XwJSUcu7hN RsQfEqoJClSuVBlraa7BiB8WrTmENiIH5jSNXI8t0bpzWf3tq/OvED7o6zWN4KPRd7qfRWnc1NIc 0PsUDEK2dqASq24JpQYSv3lA/L/JVWs51egR6kWSyjbjRbVVAuiqfcwCFj4VnBWm27F2owYGljc+ CX7ueq03TP3OhunIWbp8f7Ba+d47BcI3I0jM/DM9Uy4hsnJgzinvS8aehxrXtkxYijzocwgVdXps fg0n1DF84NMTvKlfteW3DCfRsDcxbPDTkt/ht/eFnC42XniU92RjPS+XOfURTRki8qLG3SdtMnmj pvu/peQch2vp8+P3oEIqYRBHnVc26R7D3ZqbsN3KyodKbctk7ll55vffvNRfYgST8lJ63+aJsdtz xLrWpN/Tch/t3YKQTQK1rOAMG+hdQU+wMs1nOcTq0xCXVEX5EXWtDkThiGcq7Gt6Mwr1wb8xllV7 3N3EbYkZbQjREK9Sg+qVBmOI4dBAx0LrfKObxww3cQQVK8F2/U6M90sbdfIK2IN6/kuu+xtVgKum pEZMtJrZu0c4g2f61zMUiGuP1Dzo/SW/PNCwg2dEs2pJUOmGg71Wsfxz80yoTcxewdfo+uGk5Fzk Z33hFu8nD0sRAqoNcfa2IKGCAmEDc5MjqSy8fDyLLakaMBojZeFhMpPUmLQug5U+A2OVGPnm/bbs sZ8dR/n8u/zICNtUV6n006vhO1xWMYhCRBb5JndoolNijoTWRZBuJ6mYrcYHAk9nOqYwxJJDjOa9 dSEShRezq+196Y96Lselm8OSqT+lewxMiGZXdjXVnsg/axvSpyiruyb9Yu8XmUP28HFyUvXe85KJ vRZdqwY2JTUuGdmrzotdgGwz/j7YmRQO4cwWX1vN/+FHST1UH3vV5Kp9X7uSWlNOkJenB04TRQAw boGjPwP5kSyCh5SDyCPt/i34MLnVIjqeAJSmZ5LR+w2qoVdlFOhGZjzdIdS1gH70fPDd5l4HPLNr I06dKXmyqvE5FcmXi/trfRd8eZrOtC54W7Q7YYva5VX+tTA96/FWYcDEWRqE90j+JfyVJv5nNB9J zVuQuyQLHcXyek1tFm7IoRMpoYHxlB/4F68QchUO+7MV04gN3GcabkxDoxz+UXaXQytVwz+vg3qs 32OGw9hPtUD8kLd7/XQQBTxhtP+PM8pTAWtoVjyF+gDdTHcJp57BytWR5/qpkZj/c0qmZnciYHSf JNRuGjMslZGHE+aGJmvAO/aeKq1MLYBntiPOGnHnYBwijlOk0ytoFkXJELrD04GNUGIbyWbJpiVW dojvC8eUjzqOeluXQpOgq3QPbImRMoyysaaknZWkxc8o8TqpjFt0GLNdel1f8de0RZEpsY63G6qq H8rzLrdzRZ3lb+O3YarywuwIOwkDkZV67soNsfMDBeRvj9MTWkHAkFB3veMA4OCVg+23Cmcuiyx4 59ubSlItl+qYxiHAarT+GoAbrf/WXRv+jadJqSXCt4xLT8ZEmLra9iCLcKSGVuOHaVQx+52fnNvS 0cstIdiUnyAx7HSJjQoT/l23fx26kINOH5hIdy+qZc1e3ZFiVmYO9AI0CXyoJIugk+GI9gRxKCFI 0TY4mh5IBStnQDlU0txYS8GV8a1vaZ5IqYkgfooyHu3o4ZtbG+7OLLkozdPMBo694vnzVG+ZDHuS R8L/C7QHS/gYJb6rbjmoXEMLGmApGEDen4CfzzUx/rtI4d5OxZ53y2p1UDWxsF8choM+7AL8gTFG bOPRz0Uf/e9n+pfVgIaxuzm7GvbAvCidPmFgp1ojCTL2yFqdLmetMDY8OW2VmTuB0yt22DxOTqeb KpF+ApDzjWZEWN0YIfnIZYLeoGwfTyFfs8OSOuqZwD79JsZYswkFtWzO3jfzcWf7z6LMmvEikK0e hOBocCNLdTPB7niLPZahUARAzD1hfSIynr9xbKd3Kcaq79jm7TyxQrKnZdACZnL32zKBngkA5/kK 6ToNil159cQ111IhY7KHHdt2SXVwyQhh8+z8A1gPksDfzHNWvWzHQUxwGh1KrPumIIhglglOHg/C jxjPvyZW0KX4RT9Ft5zFWCz2feNr0BOgXbQbAVQJYxWePvu5/SYJxNVNZrXd5rZKJ1kObMI0xPZr +Y/pBnaoYbtf+LdO4lmBwk6MNr+mf3RvwrwgWMQH8SXuJWqVHYz4laROAG+3vkxqPOA/+e4cQpOg QlhsfV3zBr0Doh+DdERZIDaiQnhQ69bBfvFUXu5FfqFjv6Ke9Vxq2qOytJsX8pd5P9ooB0CpTehK iJIdir3cVaasdufQP/oqH07B706ANGM4udtvg/5VcTTBQUSlVMYkYSccm3y719Ef/spMMm2dizCg Hd5ldHr9+wLF38a5BTJEjKyZOS3qvNaBJG1b0gZCZFPefGYe1dNHepXCSYAHPmPdnJQGPhtc52vc 66lRthukj8Iq6m6uKyFmOtj5AAkKA37h2vRsIyYBr9P60jgQO43xVqOIaWnRflfqeK1eDc9v3NdL IEg7JMXVyqgAuklhc8SnoF7xUKjnAmpqrjtvgBQbqUOpomSJgwSkkUUP0UUr0fjVkaLEvKa5C0pc Xkf5mdwpGw8AKg0VUrRfYTr6GiXQj9E/xnaxSUUqoL6vlAIYGgjcwFEWJ/lsclli6zoDyO34M0sa VAZmYQOM8sk7742D4UNlawDNIYl+1BszGgJuPXKp/A4V7lH5cUESWnTGbO6fl7u0Fj9aQ6CGGpAz 7Xa3Y6jbYfVEtPONdqKB5YG0OR0PykGDjOtIjxB1s/9tIc0Ze0x7dZSN4HWzIbc6lRuAQ6S07l39 B6z/sY6N/eeFiTte/WAZogJ8c+4xSkK+ttlIYVIwpYFlx6D5cuoTQdyXKWI12ynPCvYorDwwsR8V gLJfwMa+fgqZX+HyPtGuGYTXjvI5noYqJ16HwTNZBNoiNJqEet48BgrsacKYfrb7TSYcuEmwf1d3 sGMkfNDx11EC1761Zcs9yq5bbOsrKjwqUIW7Doff0LkKxWsK3KfI/4K3zisqNMfgNZ0O1H2Lx1d1 QJSMouh4vqS8mc7VspbxkWxO+qxhwpdUmB18mZuIWI473qg0o7D2RZLEj8mnmcaN10WaITNgeRJs FyYfIBtXQcUr6K7DNYmhP22+r69pt1O8DalAF6069cQrGP0MrCqkbmzWgv1p4Y/GtoLKYywWEro0 87FwY9yQmYkh5ofyy26imKy9/0QryR/UfhupOwyLS/TChaLY7sblyr6E4L0esclbv/pUDmX1NGgj e7SKxPZuEZXLuZdek+o7iZ52LsDQEcB4eoauMeURZF+0hfdPO8oVI4RxpkSRovvlskEyTtFrJoBo u39N+eIsBt4eqFJWBsNURuL6q4R6VYKzh9YUawlRr2wPloM07CZSQzKYdOyEvjbAWaymiNMluPtv cGfU/NdNNhUChlIVgsPEy1ckGFE8xPQoe3U0bDhkuUb6WqA9v4Z9BnwU1Q1OPqenssPPkg8XTDnD feVrombSjuPgoyx7uXTLKC4AIQ3gm8PVA5EBR51g7gXf8+ii0LxlstZx+a0ADmROFrx/wYSBPq2m dQs51Zq30XK9UqyrlT7dBeUdfOd8pyYfl83fI6fXsqTJH57NtXalupTwreimymQyWhFMZLcLwOJ9 /h7cQ/hCo/Y+WMnAlkuMAY8Ok4W577TVqlkV/9IFCie6LrANXpDILeeSFO7ttCQBw1fSOUVQyglS rftXlv5AvmMvmBOoFuOSLxy33lV2dp1M8E4SMI4iEfMIk4kGu3OPV+Mtu04SAaen5YhFBy3L7voF FlmrjkYeqEC5Yo77mJ0xdPpVvWVKU6cbcQzQI4kPnELvvFRxCwIm7F46P2fkZNgFfF4W+P+EiN6s 8tQnpUydfmuMR/B05/wi3+SSLgDD7pQ6KCmOn0GNvuAN48bAwLV2L8XuW8h/ChQ7jnJBXpz9LN3q dAmuQrB+eY02KimdoVPRu4JON00BKKr2j0Ac38DCw51H3PudwNwsjJEZBxIII+k3JcMtQBjEzUmb IFNNzxXCdRQP/pR9oG2m7E2xLfVMSNCtB3eJFPiSm2lEwi3MntBa2TnluskbFSlReIuq4BRXn/uO beH5l1S+nQ3LfMJ0a30JtSdd5IAtYRKAI6c3J/4GhbvaX1DF7wRfnnKFrPttFVWIP9/XphZTHJDr nLkXR+dTQt6C1K8dfzkvPSlPYuX85uZXZqTGMfosoujk3nWEvaQGjDw2o4qyRS/cWhY0ER51KjuR ACam2sdrgyRuy6TRZ5I4erQBWEU6cSTR9dC0v3lEXQQcJMLJNIm3EquTY86WEAplbmRzdHJlYW0K ZW5kb2JqCjI0IDAgb2JqIDw8Ci9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL0JaUVVG RCtMTVNhbnM5LU9ibGlxdWUKL0ZsYWdzIDQKL0ZvbnRCQm94IFstNDczIC0zMTMgMTUwNCAxMTU1 XQovQXNjZW50IDY5NAovQ2FwSGVpZ2h0IDY5NAovRGVzY2VudCAtMTk0Ci9JdGFsaWNBbmdsZSAt MTIKL1N0ZW1WIDk2Ci9YSGVpZ2h0IDQ0NAovQ2hhclNldCAoL0EvQy9LL1IvYS9jL2UvZi9pL2wv by9wL3IvdC91L3YpCi9Gb250RmlsZSAyMyAwIFIKPj4gZW5kb2JqCjIxIDAgb2JqIDw8Ci9UeXBl IC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWzY1L0EgNjcvQyA3NS9LIDgyL1IgOTcvYSA5OS9jIDEw MS9lL2YgMTA1L2kgMTA4L2wgMTExL28vcCAxMTQvciAxMTYvdC91L3ZdCj4+IGVuZG9iago4IDAg b2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovQmFzZUZvbnQgL0JaUVVGRCtMTVNh bnM5LU9ibGlxdWUKL0ZvbnREZXNjcmlwdG9yIDI0IDAgUgovRmlyc3RDaGFyIDY1Ci9MYXN0Q2hh ciAxMTgKL1dpZHRocyAyMiAwIFIKL0VuY29kaW5nIDIxIDAgUgo+PiBlbmRvYmoKOSAwIG9iaiA8 PAovVHlwZSAvUGFnZXMKL0NvdW50IDEKL0tpZHMgWzYgMCBSXQo+PiBlbmRvYmoKMjUgMCBvYmog PDwKL1R5cGUgL0NhdGFsb2cKL1BhZ2VzIDkgMCBSCj4+IGVuZG9iagoyNiAwIG9iaiA8PAovUHJv ZHVjZXIgKHBkZlRlWC0xLjQwLjEwKQovQ3JlYXRvciAoVGVYKQovQ3JlYXRpb25EYXRlIChEOjIw MTEwMTIwMTM1NzU4KzAxJzAwJykKL01vZERhdGUgKEQ6MjAxMTAxMjAxMzU3NTgrMDEnMDAnKQov VHJhcHBlZCAvRmFsc2UKL1BURVguRnVsbGJhbm5lciAoVGhpcyBpcyBwZGZUZVgsIFZlcnNpb24g My4xNDE1OTI2LTEuNDAuMTAtMi4yIChUZVggTGl2ZSAyMDA5L0RlYmlhbikga3BhdGhzZWEgdmVy c2lvbiA1LjAuMCkKPj4gZW5kb2JqCnhyZWYKMCAyNwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAw MjQ3MDEgMDAwMDAgbiAKMDAwMDAyNDcyMSAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAw MDAwMDA5MDUgMDAwMDAgbiAKMDAwMDAyNDU1NSAwMDAwMCBuIAowMDAwMDAwNzkzIDAwMDAwIG4g CjAwMDAwMDAwNjcgMDAwMDAgbiAKMDAwMDA0NDI4NSAwMDAwMCBuIAowMDAwMDQ0NDUxIDAwMDAw IG4gCjAwMDAwMDEyMzYgMDAwMDAgbiAKMDAwMDAwMTUwNCAwMDAwMCBuIAowMDAwMDAyMzE0IDAw MDAwIG4gCjAwMDAwMDIzOTUgMDAwMDAgbiAKMDAwMDAwNDQ2OCAwMDAwMCBuIAowMDAwMDA0NjM1 IDAwMDAwIG4gCjAwMDAwMDQ2ODEgMDAwMDAgbiAKMDAwMDAwNDk1NyAwMDAwMCBuIAowMDAwMDA1 NTI1IDAwMDAwIG4gCjAwMDAwMDU3NjUgMDAwMDAgbiAKMDAwMDAwNjEyNCAwMDAwMCBuIAowMDAw MDQ0MTU4IDAwMDAwIG4gCjAwMDAwMjQ3NDEgMDAwMDAgbiAKMDAwMDAyNTA3NSAwMDAwMCBuIAow MDAwMDQzODk3IDAwMDAwIG4gCjAwMDAwNDQ1MDggMDAwMDAgbiAKMDAwMDA0NDU1OCAwMDAwMCBu IAp0cmFpbGVyCjw8IC9TaXplIDI3Ci9Sb290IDI1IDAgUgovSW5mbyAyNiAwIFIKL0lEIFs8NTk2 MDVEMTQ2ODAwNDREMUMzRjE5QkU4MUNFMENGNjU+IDw1OTYwNUQxNDY4MDA0NEQxQzNGMTlCRTgx Q0UwQ0Y2NT5dID4+CnN0YXJ0eHJlZgo0NDgyNAolJUVPRgo= --Apple-Mail-8--241691782 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-8--241691782-- --Apple-Mail-9--241691779 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk09wmAACgkQdyiq39b9uS6fsgCfQf26aDbHVmwOEda9n1fPrdj/ CQIAoIBmCm/d/xdKso56RD0SARhMJs19 =Fst5 -----END PGP SIGNATURE----- --Apple-Mail-9--241691779-- From Internet-Drafts@ietf.org Mon Jan 24 10:30:07 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B51C3A6B23; Mon, 24 Jan 2011 10:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwtXLluSlnTT; Mon, 24 Jan 2011 10:30:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1958F3A6907; Mon, 24 Jan 2011 10:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124183002.11151.53415.idtracker@localhost> Date: Mon, 24 Jan 2011 10:30:02 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Jan 2011 18:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The NewReno Modification to TCP's Fast Recovery Algorithm Author(s) : T. Henderson, et al. Filename : draft-ietf-tcpm-rfc3782-bis-00.txt Pages : 22 Date : 2011-01-24 RFC 5681 [RFC5681] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [RFC2883], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. The purpose of this revision from [RFC3782] is to make errata changes and to adopt a proposal from Yoshifumi Nishida to slightly increase the minimum window size after Fast Recovery from one to two segments, to improve performance when the receiver uses delayed acknowledgments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc3782-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-24102611.I-D@ietf.org> --NextPart-- From alexander.zimmermann@comsys.rwth-aachen.de Mon Jan 24 11:50:06 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194BE28C0FC for ; Mon, 24 Jan 2011 11:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.714 X-Spam-Level: X-Spam-Status: No, score=-4.714 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmdqFcRWi0+R for ; Mon, 24 Jan 2011 11:50:03 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 09FA028C0D8 for ; Mon, 24 Jan 2011 11:50:02 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LFJ00JCCLW91J60@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 24 Jan 2011 20:52:57 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,371,1291590000"; d="sig'?scan'208";a="89989372" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 24 Jan 2011 20:52:57 +0100 Received: from [137.226.12.53] ([unknown] [137.226.12.53]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LFJ00JHKLW9WZ10@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 24 Jan 2011 20:52:57 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-10--236001683 From: Alexander Zimmermann In-reply-to: <20110124183002.11151.53415.idtracker@localhost> Date: Mon, 24 Jan 2011 20:52:58 +0100 Content-transfer-encoding: 7bit Message-id: <54632421-DEDF-4578-95D7-0727C859A370@comsys.rwth-aachen.de> References: <20110124183002.11151.53415.idtracker@localhost> To: tcpm WG X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 24 Jan 2011 19:50:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--236001683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What a coincidence! Just at the moment I wrote my comments about rfc3782bis, the notification came in... Here are some ideas for further improvement. I don't feel strongly about = any of the following points, However, IMO RFC3782 is too complicated. = RFC2582 is much easier to understand. Why? * The Problem of "Avoiding Multiple Fast Retransmit" is better = explain * We don't have in every second sentence an ns2 example call * Sec 1: Lack of a proper problem description What we have is this (2nd para) "Problems can arise, therefore, when multiple packets are dropped from a single window of data and the Fast Retransmit and Fast Recovery algorithms are invoked." But is what really the problem? AFAIK, the "original" problem was that = Reno run into an RTO, if we have more than two or three losses in a single = window of data. The main problem (AFAIK) was for example not, that we execute multiple = times FRet in one window (provided that we get enough DUPACKs) * New Sec between Sec 2 and Sec 3: Basic idea of the algo I love basic ideas! In that case the reader has some ideas how the algo works, before he read it step by step. Here, we could also directly mention that the following step 1), 1b) and = 6)=20 are require to fix *another* problem that the original one. The first = time I read RFC3782, is was not that easy to figure out that this steps fix = another issue. * Sec 5: IMO delete it or move it to an appendix. * Sec 6: Really, really complicated... Take for example RFC2582 or [GF04] (only the intro). Much easier to = understand. With this two doc, you can understand the problem. For example: - In RFC3782, 1st para: It confused the reader more than it helps.=20 - In RFC3782, 3rd para: Oh my god ;-) Regarding to RFC2582, why do we = delete the most important sentence here: "Thus with NewReno, the problem of multiple = Fast Retransmits from a single window of data can only occur after a Retransmit = Timeout." Say the problem/goal: we want to block a FRet *after an RTO* until = we reach recover. - In RFC3782, 4th para: It confused the reader more than it helps. = Typically, the changes between versions are not intermixed with a problem description. Make = an own Section where we can describe the diffs. BTW, we have already such a section. * IMO Section 7,8,9,10,11 should move to an appendix Alex [GF04]: Resolving Acknowledgment Ambiguity in non-SACK TCP Am 24.01.2011 um 19:30 schrieb : > 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 >=20 > Title : The NewReno Modification to TCP's Fast = Recovery Algorithm > Author(s) : T. Henderson, et al. > Filename : draft-ietf-tcpm-rfc3782-bis-00.txt > Pages : 22 > Date : 2011-01-24 >=20 > RFC 5681 [RFC5681] documents the following four intertwined TCP > congestion control algorithms: Slow Start, Congestion Avoidance, Fast > Retransmit, and Fast Recovery. RFC 5681 explicitly allows > certain modifications of these algorithms, including modifications > that use the TCP Selective Acknowledgement (SACK) option [RFC2883], > and modifications that respond to "partial acknowledgments" (ACKs > which cover new data, but not all the data outstanding when loss was > detected) in the absence of SACK. This document describes a specific > algorithm for responding to partial acknowledgments, referred to as > NewReno. This response to partial acknowledgments was first proposed > by Janey Hoe in [Hoe95]. >=20 > The purpose of this revision from [RFC3782] is to make errata changes > and to adopt a proposal from Yoshifumi Nishida to slightly increase > the minimum window size after Fast Recovery from one to two segments, > to improve performance when the receiver uses delayed acknowledgments. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-10--236001683 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk092JoACgkQdyiq39b9uS7K9wCg/ku2Kt+CwpU21iI71NsLdQG2 f7EAoPEyPlhG+0mVeXx7L1LoSrs/6ZxK =fEWO -----END PGP SIGNATURE----- --Apple-Mail-10--236001683-- From wesley.m.eddy@nasa.gov Tue Jan 25 10:21:32 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A783A682F for ; Tue, 25 Jan 2011 10:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.383 X-Spam-Level: X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgMzCV3AX-hH for ; Tue, 25 Jan 2011 10:21:31 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 66D7D3A6811 for ; Tue, 25 Jan 2011 10:21:31 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 0846BE8064 for ; Tue, 25 Jan 2011 12:24:29 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id p0PIOSlb009535 for ; Tue, 25 Jan 2011 12:24:28 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Tue, 25 Jan 2011 12:24:28 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 25 Jan 2011 12:24:27 -0600 Thread-Topic: dispositioning of RFC 793 reported-errata Thread-Index: Acu8vRnTvtP0xoiGQ0KJPLPqcKtEeg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-25_07:2011-01-25, 2011-01-25, 1970-01-01 signatures=0 Subject: [tcpm] dispositioning of RFC 793 reported-errata X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2011 18:21:32 -0000 Hello, we have several reported errata on RFC 793 which have been stalled i= n the "reported" state for quite some time, and need to be dispositioned as= either: o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. o Rejected - The erratum is in error, or proposes a change to the RFC that should be done my publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list. o Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. There are ~20 of these, so I was thinking we could go through them in 3 batches of ~7. Here are some proposed dispositions (from me) for the first 7 which your feedback would be useful on. These only come from my own review at the moment. In the next several weeks, I'd like to ask the working group if there is consensus on the proposed dispositions for each of these (please copy the TCPM list with any comments you have): 1 - Errata ID 1496: http://www.rfc-editor.org/errata_search.php?eid=3D1496 Accepted - note that RFC 1122 already fixes this 2 - Errata ID 1561: http://www.rfc-editor.org/errata_search.php?eid=3D1561 Hold for Document Update - the state is very clearly defined in the document (and diagram), so this change seems to not be strictly necessary, and it expresses something slightly different than the existing text, though it is correct. 3 - Errata ID 1562: http://www.rfc-editor.org/errata_search.php?eid=3D1562 Accepted - minor clarification 4 - Errata ID 1563: http://www.rfc-editor.org/errata_search.php?eid=3D1563 Accepted - note, RFC 1122 already corrected this 5 - Errata ID 1564: http://www.rfc-editor.org/errata_search.php?eid=3D1564 Accepted - minor clarification 6 - Errata ID 1565: http://www.rfc-editor.org/errata_search.php?eid=3D1565 Hold for Document Update - the actual clarification that might be included may be more complex than what this errata suggests, and it does not seem to be strictly necessary to clarify at the moment 7 - Errata ID 1566: http://www.rfc-editor.org/errata_search.php?eid=3D1566 Rejected - this is "may" and does not produce incorrect protocol behavior, so there is no reason to remove it. Guidance: In order to help you determine the correct handling for the errata, the IESG has come up with a few guidelines: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. 3. Errata on obsolete RFCs should be treated the same as errata on RFCs that are not obsolete where there is strong evidence that some people are still making use of the related technology. 4. Trivial grammar corrections should be Hold for Document Update. 5. Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update. 6. Changes which are simply stylistic issues or simply make things read better should be Hold for Document Update. 7. Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. 8. Changes that modify the working of a process, such as changing an IANA registration procedure, to something that might be different from the intended consensus when the document was approved should be Rejected. -- Wes Eddy MTI Systems From touch@isi.edu Tue Jan 25 10:57:26 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343103A6870 for ; Tue, 25 Jan 2011 10:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAdNkt12MvNk for ; Tue, 25 Jan 2011 10:57:25 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id EB6923A6875 for ; Tue, 25 Jan 2011 10:57:24 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0PJ0Dbc002670 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 25 Jan 2011 11:00:14 -0800 (PST) Message-ID: <4D3F1DBD.1090509@isi.edu> Date: Tue, 25 Jan 2011 11:00:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: 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] dispositioning of RFC 793 reported-errata X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2011 18:57:26 -0000 Hi, all, Some commments below. Joe ---------- On 1/25/2011 10:24 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: ... > In the next several weeks, I'd like to ask the working group if there > is consensus on the proposed dispositions for each of these (please > copy the TCPM list with any comments you have): > > 1 - Errata ID 1496: > http://www.rfc-editor.org/errata_search.php?eid=1496 > > Accepted - note that RFC 1122 already fixes this I'm not sure of the correct procedure here. RFC 1122 updates RFC 793. I don't think it's appropriate to include errata that merely point out those updates. At best, HOLD FOR DOC UPDATE, but I prefer that such changes be just REJECTED. > 2 - Errata ID 1561: > http://www.rfc-editor.org/errata_search.php?eid=1561 > > Hold for Document Update - the state is very clearly > defined in the document (and diagram), so this change > seems to not be strictly necessary, and it expresses > something slightly different than the existing text, > though it is correct. Agreed. > 3 - Errata ID 1562: > http://www.rfc-editor.org/errata_search.php?eid=1562 > > Accepted - minor clarification I disagree. The wording is very poor, at best. The point appears to be that the sequence number can increase due to data octets OR unique control segments (segments without data), AFAICT. The flag fields themselves are not counted per se, either individually or when repeated (again, AFAICT). E.g., the sequence number does not increase by two for a SYN-ACK (which has two flag bits). This change should either be Rejected (as submitted) or edited to be clear. > 4 - Errata ID 1563: > http://www.rfc-editor.org/errata_search.php?eid=1563 > > Accepted - note, RFC 1122 already corrected this This should be separated into different reports. The typographic errors should definitely be HOLD FOR DOCUMENT UPDATE; only the specific changes should be added. For the rest, disagree - handle the rest as noted for eratta 1496. > 5 - Errata ID 1564: > http://www.rfc-editor.org/errata_search.php?eid=1564 > > Accepted - minor clarification Disagree - handle as noted for errata 1562. > 6 - Errata ID 1565: > http://www.rfc-editor.org/errata_search.php?eid=1565 > > Hold for Document Update - the actual clarification > that might be included may be more complex than what > this errata suggests, and it does not seem to be > strictly necessary to clarify at the moment Agreed. > 7 - Errata ID 1566: > http://www.rfc-editor.org/errata_search.php?eid=1566 > > Rejected - this is "may" and does not produce incorrect > protocol behavior, so there is no reason to remove it. Agreed. --- From wesley.m.eddy@nasa.gov Tue Jan 25 13:45:50 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA793A68AD for ; Tue, 25 Jan 2011 13:45:50 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzM0pSKCpPeU for ; Tue, 25 Jan 2011 13:45:49 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 2C8F93A6891 for ; Tue, 25 Jan 2011 13:45:49 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 80B4CA851A; Tue, 25 Jan 2011 15:48:47 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id p0PLmkR1020053; Tue, 25 Jan 2011 15:48:47 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 25 Jan 2011 15:48:47 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Joe Touch Date: Tue, 25 Jan 2011 15:48:46 -0600 Thread-Topic: [tcpm] dispositioning of RFC 793 reported-errata Thread-Index: Acu8wh/CAwk6gx1GSry6FXBxoMgtlAAFhd5g Message-ID: References: <4D3F1DBD.1090509@isi.edu> In-Reply-To: <4D3F1DBD.1090509@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-25_08:2011-01-25, 2011-01-25, 1970-01-01 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] dispositioning of RFC 793 reported-errata X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2011 21:45:50 -0000 Thanks Joe, I buy your arguments, here are some additional comments: >-----Original Message----- >From: Joe Touch [mailto:touch@isi.edu] >Sent: Tuesday, January 25, 2011 2:00 PM > > ... > >> 1 - Errata ID 1496: >> http://www.rfc-editor.org/errata_search.php?eid=3D1496 >> >> Accepted - note that RFC 1122 already fixes this > >I'm not sure of the correct procedure here. RFC 1122 updates RFC 793. I >don't think it's appropriate to include errata that merely point out >those updates. > >At best, HOLD FOR DOC UPDATE, but I prefer that such changes be just >REJECTED. Now that you mention it, there should be an additional IESG guideline added to the list of errata-handling guidelines: For documents that the RFC-Editor has already recorded as "Updated by" other documents, if those updates correct or clarify the subject of the errata, then the errata should be REJECTED. >> 3 - Errata ID 1562: >> http://www.rfc-editor.org/errata_search.php?eid=3D1562 >> >> Accepted - minor clarification > >I disagree. The wording is very poor, at best. The point appears to be >that the sequence number can increase due to data octets OR unique >control segments (segments without data), AFAICT. The flag fields >themselves are not counted per se, either individually or when repeated >(again, AFAICT). E.g., the sequence number does not increase by two for >a SYN-ACK (which has two flag bits). > >This change should either be Rejected (as submitted) or edited to be >clear. I see your point; I could live with either a "reject" or "hold for document update" since the point is that the SYN/FIN bits count. The errata as-written is not quite right, and accepting some fixed version of it probably won't make any difference to implementers (since this is sufficiently well-explained elsewhere). >> 5 - Errata ID 1564: >> http://www.rfc-editor.org/errata_search.php?eid=3D1564 >> >> Accepted - minor clarification > >Disagree - handle as noted for errata 1562. I now agree; both 1562 and 1564 should be treated the same, however that consensus turns out. -- Wes Eddy MTI Systems From touch@isi.edu Tue Jan 25 13:55:32 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F663A689F for ; Tue, 25 Jan 2011 13:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR2dSodsF81A for ; Tue, 25 Jan 2011 13:55:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9EDBB3A6891 for ; Tue, 25 Jan 2011 13:55:30 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0PLw4Xk011286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 25 Jan 2011 13:58:04 -0800 (PST) Message-ID: <4D3F476C.1030906@isi.edu> Date: Tue, 25 Jan 2011 13:58:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <4D3F1DBD.1090509@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@ietf.org" Subject: Re: [tcpm] dispositioning of RFC 793 reported-errata X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 25 Jan 2011 21:55:33 -0000 Hi, Wes, On 1/25/2011 1:48 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Thanks Joe, I buy your arguments, here are some additional comments: > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Tuesday, January 25, 2011 2:00 PM >> >> ... >> >>> 1 - Errata ID 1496: >>> http://www.rfc-editor.org/errata_search.php?eid=1496 >>> >>> Accepted - note that RFC 1122 already fixes this >> >> I'm not sure of the correct procedure here. RFC 1122 updates RFC 793. I >> don't think it's appropriate to include errata that merely point out >> those updates. >> >> At best, HOLD FOR DOC UPDATE, but I prefer that such changes be just >> REJECTED. > > > Now that you mention it, there should be an additional IESG guideline > added to the list of errata-handling guidelines: For documents that > the RFC-Editor has already recorded as "Updated by" other documents, > if those updates correct or clarify the subject of the errata, then > the errata should be REJECTED. Yup - that's a useful general guideline IMO. >>> 3 - Errata ID 1562: >>> http://www.rfc-editor.org/errata_search.php?eid=1562 >>> >>> Accepted - minor clarification >> >> I disagree. The wording is very poor, at best. The point appears to be >> that the sequence number can increase due to data octets OR unique >> control segments (segments without data), AFAICT. The flag fields >> themselves are not counted per se, either individually or when repeated >> (again, AFAICT). E.g., the sequence number does not increase by two for >> a SYN-ACK (which has two flag bits). >> >> This change should either be Rejected (as submitted) or edited to be >> clear. > > I see your point; I could live with either a "reject" or "hold for > document update" since the point is that the SYN/FIN bits count. The > errata as-written is not quite right, and accepting some fixed version > of it probably won't make any difference to implementers (since this is > sufficiently well-explained elsewhere). I think as-is it's more confusing than helpful. Are there procedures for editing the errata? Or should we just submit a more clear one (that we hold for doc update) and reject this? Joe From wes@mti-systems.com Sun Jan 30 20:23:55 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0F13A6B58 for ; Sun, 30 Jan 2011 20:23:55 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g7VNMzZ9wVl for ; Sun, 30 Jan 2011 20:23:54 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id 151923A6AA8 for ; Sun, 30 Jan 2011 20:23:53 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0V4R6S8002720 for ; Sun, 30 Jan 2011 23:27:06 -0500 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.111.34] ([174.130.111.34:6729] helo=[192.168.1.104]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 91/D5-23439-A1A364D4; Sun, 30 Jan 2011 23:27:06 -0500 Message-ID: <4D463A1A.2090301@mti-systems.com> Date: Sun, 30 Jan 2011 23:27:06 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <4D2FC53C.4030304@mti-systems.com> In-Reply-To: <4D2FC53C.4030304@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 04:23:55 -0000 On 1/13/2011 10:38 PM, Wesley Eddy wrote: > Based on the discussion of section 7 (programming considerations), the > document on clarifying the persist condition has been updated by the > authors. > > The document can be found at: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ > > We think this is ready for working group last call now, so with this > email, I'd like to start a two-week WGLC on the document to last until > 1/28. Please send your comments to the TCPM list by then. Since this last call has concluded, I'm planning to do the PROTO writeup and send up the document to the IESG late this week. Since this document is fairly short, includes relatively simple technical material, and was well-discussed earlier in its history, I wasn't concerned by the lack of WGLC feedback, but will note it in the writeup. If there's any disagreement on this, or someone wants more time to review, please shout in the next couple days, before I submit the document to the IESG for publication. -- Wes Eddy MTI Systems From wes@mti-systems.com Sun Jan 30 20:41:13 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10A0D3A6B89 for ; Sun, 30 Jan 2011 20:41:13 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN0P9TV80yJ1 for ; Sun, 30 Jan 2011 20:41:12 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by core3.amsl.com (Postfix) with ESMTP id 19EA03A6B58 for ; Sun, 30 Jan 2011 20:41:12 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0V4iOJ6019144 for ; Sun, 30 Jan 2011 23:44:24 -0500 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.111.34] ([174.130.111.34:17610] helo=[192.168.1.104]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E3/78-31631-82E364D4; Sun, 30 Jan 2011 23:44:24 -0500 Message-ID: <4D463E29.3040308@mti-systems.com> Date: Sun, 30 Jan 2011 23:44:25 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] 2988bis document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 04:41:13 -0000 Based on previous discussions and the thread several months ago for confirming adoption of the RFC 2988bis document: http://www.ietf.org/mail-archive/web/tcpm/current/msg05814.html I'll ask to have a milestone added to the TCPM charter for this document and for it to be noted as a WG document in the tracker. Note that the authors feel this document is complete, and as this is a relatively short "bis" document and the main changes have seemed fairly well agreed upon in prior WG discussion, I plan to set the milestone date for March to submit this to the IESG, and will start a WGLC following addition of the milestone. With that in mind, please consider reviewing: http://tools.ietf.org/html/draft-paxson-tcpm-rfc2988bis-01 as a WG document, since a working group last call is planned soon. -- Wes Eddy MTI Systems From anil.agarwal@viasat.com Mon Jan 31 05:09:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1028E3A6B61 for ; Mon, 31 Jan 2011 05:09:10 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOl1kty5SxVW for ; Mon, 31 Jan 2011 05:09:09 -0800 (PST) Received: from viasat.com (hawk.viasat.com [12.198.241.145]) by core3.amsl.com (Postfix) with ESMTP id F3B063A6915 for ; Mon, 31 Jan 2011 05:09:08 -0800 (PST) Received: from ([172.31.1.23]) by hawk.viasat.com with ESMTP id 5B7LFJ1.18810735; Mon, 31 Jan 2011 08:12:19 -0500 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Jan 2011 08:12:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 08:12:17 -0500 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com> In-Reply-To: <4D463A1A.2090301@mti-systems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvA/yM/jbSCmx+4RHKKxmR2bdnj9AAPqkbA References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> From: "Agarwal, Anil" To: "Wesley Eddy" , X-OriginalArrivalTime: 31 Jan 2011 13:12:18.0429 (UTC) FILETIME=[7CB5DAD0:01CBC148] Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 13:09:10 -0000 Wes, In https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist, the "Programming Considerations" section seems to describe two different techniques for TCP-to-application interaction for persist timeout handling.=20 a) TCP sends a timeout indication to the application which then=20 closes the connection;=20 b) TCP itself terminates the connection.=20 1. The two techniques are written using very different description styles - would be beneficial to use one consistent style. 2. A sentence clarifying that these are two separate suggested techniques would also be useful. 3. Would be useful to clarify that TCP will close the connection and reclaim resources if a close is performed by the application for a connection in "persist" state, even if there is unsent data in the transmit buffer. Does it?=20 If it does, approximately how long will it (should it) take before the connection is terminated and resources are reclaimed? Anil Agarwal ViaSat Inc. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Wesley Eddy Sent: Sunday, January 30, 2011 11:27 PM To: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist On 1/13/2011 10:38 PM, Wesley Eddy wrote: > Based on the discussion of section 7 (programming considerations), the > document on clarifying the persist condition has been updated by the > authors. > > The document can be found at: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ > > We think this is ready for working group last call now, so with this > email, I'd like to start a two-week WGLC on the document to last until > 1/28. Please send your comments to the TCPM list by then. Since this last call has concluded, I'm planning to do the PROTO writeup and send up the document to the IESG late this week. Since this=20 document is fairly short, includes relatively simple technical material, and was well-discussed earlier in its history, I wasn't concerned by the lack of WGLC feedback, but will note it in the writeup. If there's any disagreement on this, or someone wants more time to=20 review, please shout in the next couple days, before I submit the=20 document to the IESG for publication. -- Wes Eddy MTI Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From ananth@cisco.com Mon Jan 31 07:58:50 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162333A6977 for ; Mon, 31 Jan 2011 07:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhu1bEy5pU6l for ; Mon, 31 Jan 2011 07:58:48 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C93953A67B7 for ; Mon, 31 Jan 2011 07:58:48 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4DAMZrRk2rRN+K/2dsb2JhbACWGI5hc6ItmnqFTgSFE4pZ Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2011 16:02:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0VG23wJ006882; Mon, 31 Jan 2011 16:02:03 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 08:02:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 08:02:01 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BBA43F6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvA/yM/jbSCmx+4RHKKxmR2bdnj9AAPqkbAAAf2G7A= References: <4D2FC53C.4030304@mti-systems.com><4D463A1A.2090301@mti-systems.com> <0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com> From: "Anantha Ramaiah (ananth)" To: "Agarwal, Anil" , "Wesley Eddy" , X-OriginalArrivalTime: 31 Jan 2011 16:02:03.0363 (UTC) FILETIME=[33677330:01CBC160] Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 15:58:50 -0000 Anil, You probably missed the 3+ years of on/off discussion that went on with this short draft. The wordings are so chosen in a such a way to honor the RFC 1122 (or 793) spirits that TCP by itself cannot abort the connection and it is ok for TCP to abort the connection if the application or system (OS) has indicated so. So, in both cases where you mention below we simply suggest that as long as the basic premise is followed (i.e, TCP by itself cannot abort the connection), we are fine with any method an implementation uses. The programming consideration section is there to simply illustrate the concept. Pl see inline for specific answers :- > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Agarwal, Anil > Sent: Monday, January 31, 2011 5:12 AM > To: Wesley Eddy; tcpm@ietf.org > Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist >=20 > Wes, >=20 > In https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist, the > "Programming Considerations" section seems to describe two different > techniques for TCP-to-application interaction for persist timeout > handling. > a) TCP sends a timeout indication to the application which then > closes the connection; > b) TCP itself terminates the connection. >=20 > 1. The two techniques are written using very different description > styles - > would be beneficial to use one consistent style. The base of these "2 techniques" is that the application has requested to close the connection if some conditions are met using a an API as mentioned in the previous paragraph.=20 I' >=20 > 2. A sentence clarifying that these are two separate suggested > techniques > would also be useful. Well, we really don't want to emphasize a whole lot, there were some folks who felt that there is no need for having a programming considerations section at all. Your suggestion seems to be supporting that and add more text, but we have had so much debate (unfortunately) on this topic and I would be reluctant to add more text unless there is a WG consensus.=20 >=20 > 3. Would be useful to clarify that TCP will close the connection and > reclaim > resources if a close is performed by the application for a > connection > in > "persist" state, even if there is unsent data in the transmit > buffer. > Does it? > If it does, approximately how long will it (should it) take before > the connection is terminated and resources are reclaimed? An application close would be handled the same way as it is today. We haven't changed any of those semantics. We can add a line if there is a confusion. Thanks, -Anantha >=20 > Anil Agarwal > ViaSat Inc. >=20 >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Wesley Eddy > Sent: Sunday, January 30, 2011 11:27 PM > To: tcpm@ietf.org > Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist >=20 > On 1/13/2011 10:38 PM, Wesley Eddy wrote: > > Based on the discussion of section 7 (programming considerations), > the > > document on clarifying the persist condition has been updated by the > > authors. > > > > The document can be found at: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ > > > > We think this is ready for working group last call now, so with this > > email, I'd like to start a two-week WGLC on the document to last > until > > 1/28. Please send your comments to the TCPM list by then. >=20 >=20 > Since this last call has concluded, I'm planning to do the PROTO > writeup >=20 > and send up the document to the IESG late this week. Since this > document is fairly short, includes relatively simple technical > material, >=20 > and was well-discussed earlier in its history, I wasn't concerned by > the >=20 > lack of WGLC feedback, but will note it in the writeup. >=20 > If there's any disagreement on this, or someone wants more time to > review, please shout in the next couple days, before I submit the > document to the IESG for publication. >=20 > -- > Wes Eddy > MTI Systems > _______________________________________________ > 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 Mon Jan 31 08:46:59 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26ABC3A6AAF for ; Mon, 31 Jan 2011 08:46:59 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvfnIzmri4dI for ; Mon, 31 Jan 2011 08:46:58 -0800 (PST) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id 9AA5C3A6915 for ; Mon, 31 Jan 2011 08:46:57 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0VGoBgu011837 for ; Mon, 31 Jan 2011 11:50:11 -0500 Authentication-Results: cm-omr11 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [173.107.190.185] ([173.107.190.185:11632] helo=[192.168.9.2]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3D/0D-02947-F38E64D4; Mon, 31 Jan 2011 11:50:11 -0500 Message-ID: <4D46E83E.50409@mti-systems.com> Date: Mon, 31 Jan 2011 11:50:06 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Agarwal, Anil" References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com> In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 16:46:59 -0000 On 1/31/2011 8:12 AM, Agarwal, Anil wrote: > Wes, > > In https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist, the > "Programming Considerations" section seems to describe two different > techniques for TCP-to-application interaction for persist timeout > handling. > a) TCP sends a timeout indication to the application which then > closes the connection; > b) TCP itself terminates the connection. > > 1. The two techniques are written using very different description > styles - > would be beneficial to use one consistent style. > > 2. A sentence clarifying that these are two separate suggested > techniques > would also be useful. > I think these are good points and it's helpful to have a fresh set of eyes on the document. On looking at that section again, I agree that it isn't particularly clear that there are 2 different techniques that the API supports. Since this should be possible to remedy with just a couple sentences, I think it should be done. -- Wes Eddy MTI Systems From mahesh@cisco.com Mon Jan 31 09:33:33 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5E93A683B for ; Mon, 31 Jan 2011 09:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.88 X-Spam-Level: X-Spam-Status: No, score=-8.88 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj4GphQ+pmp9 for ; Mon, 31 Jan 2011 09:33:32 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 112813A67B4 for ; Mon, 31 Jan 2011 09:33:32 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: spacer.gif, footerHead.gif, footer.gif : 55, 68, 347 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugFAAuCRk2rR7H+/2dsb2JhbACCQ5QUiTeEa3OiRZsQAoMPgj0EhROHDoNF Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2011 17:36:46 +0000 Received: from [10.21.107.249] (sjc-vpnasa-1017.cisco.com [10.21.107.249]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VHak5F017943 for ; Mon, 31 Jan 2011 17:36:46 GMT Message-ID: <4D46F32E.2080709@cisco.com> Date: Mon, 31 Jan 2011 09:36:46 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <4D2FC53C.4030304@mti-systems.com><4D463A1A.2090301@mti-systems.com><0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com> <4D46E83E.50409@mti-systems.com> In-Reply-To: <4D46E83E.50409@mti-systems.com> Content-Type: multipart/alternative; boundary="------------080805090303060807060807" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 17:33:33 -0000 This is a multi-part message in MIME format. --------------080805090303060807060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/31/2011 8:50 AM, Wesley Eddy wrote: > > > > > I think these are good points and it's helpful to have a fresh set of > eyes on the document. On looking at that section again, I agree that it > isn't particularly clear that there are 2 different techniques that the > API supports. Since this should be possible to remedy with just a > couple sentences, I think it should be > done. > Will clarify that there are two suggested techniques possible and send out an updated version of the document. -- *Mahesh Jethanandani* *Technical Leader* **ERBU* * mahesh@cisco.com Phone :*+1 408 527-8230* Fax :*+1 408 853-0762* ** 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. --------------080805090303060807060807 Content-Type: multipart/related; boundary="------------090107050704070307060705" --------------090107050704070307060705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 1/31/2011 8:50 AM, Wesley Eddy wrote:
Re: [tcpm] WGLC on draft-ietf-tcpm-persist




I think these are good points and it's helpful to have a fresh set of
eyes on the document.  On looking at that section again, I agree that it
isn't particularly clear that there are 2 different techniques that the
API supports.  Since this should be possible to remedy with just a
couple sentences, I think it should be done.

Will clarify that there are two suggested techniques possible and send out an updated version of the document.

--

Mahesh Jethanandani
Technical Leader
ERBU

mahesh@cisco.com
Phone :+1 408 527-8230
Fax :+1 408 853-0762


170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com

  
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


--------------090107050704070307060705 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="spacer.gif" R0lGODlhCgAKAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAKAAoAAAIIlI+py+0PYysA Ow== --------------090107050704070307060705 Content-Type: image/gif; name="footerHead.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footerHead.gif" R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y0 2ouz3rz7D4biSE4FADs= --------------090107050704070307060705 Content-Type: image/gif; name="footer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footer.gif" R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY 2vHy8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAA ACH5BAEAABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOk cslsOp/QqHRKFW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWG h4iJijIYBxclBhIai5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYs DgcUDcHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wADChxIUEYIADs= --------------090107050704070307060705-- --------------080805090303060807060807-- From anil.agarwal@viasat.com Mon Jan 31 12:01:24 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382293A6C6B for ; Mon, 31 Jan 2011 12:01:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq3fD7x+ZDD8 for ; Mon, 31 Jan 2011 12:01:23 -0800 (PST) Received: from viasat.com (hawk.viasat.com [12.198.241.145]) by core3.amsl.com (Postfix) with ESMTP id 699DB3A6C72 for ; Mon, 31 Jan 2011 12:01:06 -0800 (PST) Received: from ([172.31.1.23]) by hawk.viasat.com with ESMTP id 5B7LFJ1.18820192; Mon, 31 Jan 2011 15:04:16 -0500 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Jan 2011 15:04:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 15:04:15 -0500 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B065048DDE21@VGAEXCH01.hq.corp.viasat.com> In-Reply-To: <4D46F32E.2080709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvBbXVpFeBEgfVERTujFWamGQbzUQACTKpQ References: <4D2FC53C.4030304@mti-systems.com><4D463A1A.2090301@mti-systems.com><0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com><4D46E83E.50409@mti-systems.com> <4D46F32E.2080709@cisco.com> From: "Agarwal, Anil" To: "Mahesh Jethanandani" , X-OriginalArrivalTime: 31 Jan 2011 20:04:15.0635 (UTC) FILETIME=[09502E30:01CBC182] Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 20:01:24 -0000 Mahesh, Wes et al, Few more points - I don't think an application-initiated close() will terminate a tcp = connection in persist state. The RFCs don't mention it and most (all?) implementations don't do it either. I have a zombie tcp connection On Linux 2.4.20, in FIN_WAIT state,=20 which is sending TCP probes for the past 7 hours, even though the application has been killed. I suspended the receiving peer during a tcp transfer, so its tcp is alive and merrily sending ACKs to tcp probes. Same results with Linux 2.6.19. Checked the Linux source code too. Section 7 explicitly refers to "close". The application probably needs to do an "ABORT"; don't know if OSs support TCP ABORT operation on = sockets from userland. Also, it should be noted that application-initiated close will require = changes to every application. I suspect most OS vendors will choose the = second solution and implement a system-configurable timeout or retries = value and have TCP abort the connection on its own. Anil ________________________________________ From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of = Mahesh Jethanandani Sent: Monday, January 31, 2011 12:37 PM To: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist On 1/31/2011 8:50 AM, Wesley Eddy wrote:=20 I think these are good points and it's helpful to have a fresh set of eyes on the document.=A0 On looking at that section again, I agree that = it isn't particularly clear that there are 2 different techniques that the API supports.=A0 Since this should be possible to remedy with just a couple sentences, I think it should be done. Will clarify that there are two suggested techniques possible and send = out an updated version of the document. --=20 Mahesh Jethanandani Technical Leader ERBU mahesh@cisco.com Phone :+1 408 527-8230 Fax :+1 408 853-0762 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com =A0 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. From ananth@cisco.com Mon Jan 31 12:12:03 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15AD93A6C4D for ; Mon, 31 Jan 2011 12:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4lUfRVBDpg3 for ; Mon, 31 Jan 2011 12:12:02 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 326F53A6846 for ; Mon, 31 Jan 2011 12:12:02 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4DAIqnRk2rR7Ht/2dsb2JhbACWGY5gc6MKmx6CfoJQBIUTilk Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2011 20:15:17 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0VKFHMr009777; Mon, 31 Jan 2011 20:15:17 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 12:15:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 12:15:16 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BBA4612@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B065048DDE21@VGAEXCH01.hq.corp.viasat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvBbXVpFeBEgfVERTujFWamGQbzUQACTKpQAAL8p9A= References: <4D2FC53C.4030304@mti-systems.com><4D463A1A.2090301@mti-systems.com><0B0A20D0B3ECD742AA2514C8DDA3B065048DDC44@VGAEXCH01.hq.corp.viasat.com><4D46E83E.50409@mti-systems.com><4D46F32E.2080709@cisco.com> <0B0A20D0B3ECD742AA2514C8DDA3B065048DDE21@VGAEXCH01.hq.corp.viasat.com> From: "Anantha Ramaiah (ananth)" To: "Agarwal, Anil" , "Mahesh Jethanandani (mahesh)" , X-OriginalArrivalTime: 31 Jan 2011 20:15:17.0359 (UTC) FILETIME=[93BB3FF0:01CBC183] Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 20:12:03 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Agarwal, Anil > Sent: Monday, January 31, 2011 12:04 PM > To: Mahesh Jethanandani (mahesh); tcpm@ietf.org > Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist >=20 > Mahesh, Wes et al, >=20 > Few more points - >=20 > I don't think an application-initiated close() will terminate a tcp > connection in persist state. The RFCs don't mention it and most (all?) > implementations don't do it either. >=20 > I have a zombie tcp connection On Linux 2.4.20, in FIN_WAIT state, > which is sending TCP probes for the past 7 hours, > even though the application has been killed. > I suspended the receiving peer during a tcp transfer, so its tcp > is alive and merrily sending ACKs to tcp probes. > Same results with Linux 2.6.19. Checked the Linux source code too. This is the way the Linux implementation chose to behave. In particular, if the system runs out of resources, Linux has the algorithm that targets the orphaned sockets, it would abort these TCP connections stuck in FINWAIT1/2 state. Pl take a look at tcp_out_of_resources() function in tcp_timer.c.=20 -Anantha From wesley.m.eddy@nasa.gov Mon Jan 31 13:28:09 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494743A6C96 for ; Mon, 31 Jan 2011 13:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c27Pv4c3vw17 for ; Mon, 31 Jan 2011 13:28:08 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 76C233A6C93 for ; Mon, 31 Jan 2011 13:28:08 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 40A6A108476 for ; Mon, 31 Jan 2011 15:31:23 -0600 (CST) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id p0VLV4mI030367 for ; Mon, 31 Jan 2011 15:31:22 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Mon, 31 Jan 2011 15:30:57 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Mon, 31 Jan 2011 15:30:56 -0600 Thread-Topic: agenda planning for Prague Thread-Index: AcvBjiUVzXCeGRDOTqSK8eExV1DK4w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-31_09:2011-01-31, 2011-01-31, 1970-01-01 signatures=0 Subject: [tcpm] agenda planning for Prague X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 21:28:09 -0000 We've requested a meeting slot for the IETF 80 meeting in Prague: http://www.ietf.org/meeting/80/index.html As we're beginning to put the agenda together, please let David and I know = if you'd like a presentation slot. Precedence for time will be given for w= orking group items over other items, and to things being discussed on the m= ailing list or posted in I-Ds. -- Wes Eddy MTI Systems From johnwheffner@gmail.com Mon Jan 31 15:01:45 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505903A6BEB for ; Mon, 31 Jan 2011 15:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLI2lmGrUTd1 for ; Mon, 31 Jan 2011 15:01:44 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DA7CC3A6B26 for ; Mon, 31 Jan 2011 15:01:43 -0800 (PST) Received: by bwz12 with SMTP id 12so6720647bwz.31 for ; Mon, 31 Jan 2011 15:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JO47FG6fi+TFxpbVtcF5UUbUNrk+6X7C+lAn+NxyKAc=; b=WlQGo4XHQdrqKxAUAIMC/FTqZOL1HedMlK77iUwgUcaE+4riNPfnyA+AfnHSA/NpzZ YNOg8ck+7R2dP/sh7btMerwz4p6Oa5Sdnd8mnZIIbBKWaFqoYU+BGLxk1qa/Ij7oohd4 P+CzWplWkgj1RreqgOzkaK145ydbYpPbPwDHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ro4MTa0UV0ehw/o9mwYgqsTJHIz6mUkvpCkpJXuG0vaP938TB0+yFN6cOFOYJMxUTj CAi0VbwI/OoyO3Hd+L2ABg7oNs2Y4IaoEXl9iVduZxslCndj3bw66lZR6zMRVCOkKszg oDxTuilM7TrLEh8Q/QmVdlZ5SzB1aZ1ukJW8w= MIME-Version: 1.0 Received: by 10.204.23.202 with SMTP id s10mr793861bkb.173.1296515098428; Mon, 31 Jan 2011 15:04:58 -0800 (PST) Received: by 10.204.121.76 with HTTP; Mon, 31 Jan 2011 15:04:58 -0800 (PST) In-Reply-To: <4D463A1A.2090301@mti-systems.com> References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> Date: Mon, 31 Jan 2011 18:04:58 -0500 Message-ID: From: John Heffner To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 23:01:45 -0000 First, apologies for missing the last call deadline. But I'd like for the record to state that I don't believe the authors have addressed the substantive criticisms raised on the list. I'm also not sure that consensus has been reached on this document, but that is for the working group chairs to decide. To summarize my position in a single phrase, closing a TCP connection because it is in the persist state is a mistake. And this document describes a mechanism to do exactly that. If the language in RFC1122 needs to be clarified, the clarification should be that a connection may be aborted while in the persist state. It should not be aborted *because* it is in the persist state. To be more specific, the majority of the doc describes a DoS attack by resource exhaustion; however, the persist condition is only a small subset of this class of resource exhaustion attacks. Addressing only connections in the persist state ignores the rest of the problem. The document does not address this very simple well-know attack: . This document also does not address connections where, for example, one byte of window is opened every 60 seconds, and how they might be prioritized relative to connections in the persist state. Using the mechanism described in the document leaves a system completely vulnerable to resource exhaustion by such a slow-acking attacker. As a developer, why would I choose to implement this? Unless these simple variations are addressed, I think it's a waste of time. Additionally, most implementations already provide an API for handling closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER option. I don't think this document makes a sufficient justification for why this existing mechanism is inadequate, or why the proposed API is necessary or sufficient. Thanks, -John On Sun, Jan 30, 2011 at 11:27 PM, Wesley Eddy wrote: > On 1/13/2011 10:38 PM, Wesley Eddy wrote: >> >> Based on the discussion of section 7 (programming considerations), the >> document on clarifying the persist condition has been updated by the >> authors. >> >> The document can be found at: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ >> >> We think this is ready for working group last call now, so with this >> email, I'd like to start a two-week WGLC on the document to last until >> 1/28. Please send your comments to the TCPM list by then. > > > Since this last call has concluded, I'm planning to do the PROTO writeup = and > send up the document to the IESG late this week. =A0Since this document i= s > fairly short, includes relatively simple technical material, and was > well-discussed earlier in its history, I wasn't concerned by the lack of > WGLC feedback, but will note it in the writeup. > > If there's any disagreement on this, or someone wants more time to review= , > please shout in the next couple days, before I submit the document to the > IESG for publication. > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mahesh@cisco.com Mon Jan 31 15:29:49 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870A73A6B16 for ; Mon, 31 Jan 2011 15:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.635 X-Spam-Level: X-Spam-Status: No, score=-8.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx6CjNyPUHJN for ; Mon, 31 Jan 2011 15:29:47 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DA2BE3A6848 for ; Mon, 31 Jan 2011 15:29:47 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: spacer.gif, footerHead.gif, footer.gif : 55, 68, 347 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAD/VRk2rR7Ht/2dsb2JhbACCQ51OhGpzoUybLQKDD4I9BIUThw4 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2011 23:33:03 +0000 Received: from dhcp-128-107-99-74.cisco.com (dhcp-128-107-99-74.cisco.com [128.107.99.74]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0VNX3RC006533 for ; Mon, 31 Jan 2011 23:33:03 GMT Message-ID: <4D4746F3.3060609@cisco.com> Date: Mon, 31 Jan 2011 15:34:11 -0800 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090706050408060103060905" Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 23:29:49 -0000 This is a multi-part message in MIME format. --------------090706050408060103060905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John, I think you missed more than the last call deadline on the document :-) If there was ever the intent of this document to define all possible solutions to resource exhaustion DoS attacks, it was dropped quite some time ago. For the last couple of drafts when it was adopted as WG document, the intent was only to clarify the language in RFC 1122. The example given in the document was to demonstrate how the attack could happen. It was not meant to encompass all possible attacks. We agreed after numerous discussions that documenting and providing solutions to the resource exhaustion attacks that you refer to should be taken up in a separate document and is out of the scope of this document. HTH. On 1/31/11 3:04 PM, John Heffner wrote: > First, apologies for missing the last call deadline. But I'd like for > the record to state that I don't believe the authors have addressed > the substantive criticisms raised on the list. I'm also not sure that > consensus has been reached on this document, but that is for the > working group chairs to decide. > > To summarize my position in a single phrase, closing a TCP connection > because it is in the persist state is a mistake. And this document > describes a mechanism to do exactly that. If the language in RFC1122 > needs to be clarified, the clarification should be that a connection > may be aborted while in the persist state. It should not be aborted > *because* it is in the persist state. > > To be more specific, the majority of the doc describes a DoS attack by > resource exhaustion; however, the persist condition is only a small > subset of this class of resource exhaustion attacks. Addressing only > connections in the persist state ignores the rest of the problem. The > document does not address this very simple well-know attack: > . This document also does not address > connections where, for example, one byte of window is opened every 60 > seconds, and how they might be prioritized relative to connections in > the persist state. Using the mechanism described in the document > leaves a system completely vulnerable to resource exhaustion by such a > slow-acking attacker. As a developer, why would I choose to implement > this? Unless these simple variations are addressed, I think it's a > waste of time. > > Additionally, most implementations already provide an API for handling > closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER > option. I don't think this document makes a sufficient justification > for why this existing mechanism is inadequate, or why the proposed API > is necessary or sufficient. > > Thanks, > -John > > > On Sun, Jan 30, 2011 at 11:27 PM, Wesley Eddy wrote: >> On 1/13/2011 10:38 PM, Wesley Eddy wrote: >>> Based on the discussion of section 7 (programming considerations), the >>> document on clarifying the persist condition has been updated by the >>> authors. >>> >>> The document can be found at: >>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ >>> >>> We think this is ready for working group last call now, so with this >>> email, I'd like to start a two-week WGLC on the document to last until >>> 1/28. Please send your comments to the TCPM list by then. >> >> Since this last call has concluded, I'm planning to do the PROTO writeup and >> send up the document to the IESG late this week. Since this document is >> fairly short, includes relatively simple technical material, and was >> well-discussed earlier in its history, I wasn't concerned by the lack of >> WGLC feedback, but will note it in the writeup. >> >> If there's any disagreement on this, or someone wants more time to review, >> please shout in the next couple days, before I submit the document to the >> IESG for publication. >> >> -- >> Wes Eddy >> MTI Systems >> _______________________________________________ >> 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 -- *Mahesh Jethanandani* *Technical Leader* **ERBU* * mahesh@cisco.com Phone :*+1 408 527-8230* Fax :*+1 408 853-0762* ** 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. --------------090706050408060103060905 Content-Type: multipart/related; boundary="------------020806020707030802030003" --------------020806020707030802030003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John,

I think you missed more than the last call deadline on the document :-)

If there was ever the intent of this document to define all possible solutions to resource exhaustion DoS attacks, it was dropped quite some time ago. For the last couple of drafts when it was adopted as WG document, the intent was only to clarify the language in RFC 1122. The example given in the document was to demonstrate how the attack could happen. It was not meant to encompass all possible attacks.

We agreed after numerous discussions that documenting and providing solutions to the resource exhaustion attacks that you refer to should be taken up in a separate document and is out of the scope of this document.

HTH.

On 1/31/11 3:04 PM, John Heffner wrote: 
First, apologies for missing the last call deadline.  But I'd like for
the record to state that I don't believe the authors have addressed
the substantive criticisms raised on the list.  I'm also not sure that
consensus has been reached on this document, but that is for the
working group chairs to decide.

To summarize my position in a single phrase, closing a TCP connection
because it is in the persist state is a mistake.  And this document
describes a mechanism to do exactly that.  If the language in RFC1122
needs to be clarified, the clarification should be that a connection
may be aborted while in the persist state.  It should not be aborted
*because* it is in the persist state.

To be more specific, the majority of the doc describes a DoS attack by
resource exhaustion; however, the persist condition is only a small
subset of this class of resource exhaustion attacks.  Addressing only
connections in the persist state ignores the rest of the problem.  The
document does not address this very simple well-know attack:
<http://shlang.com/netkill/>.  This document also does not address
connections where, for example, one byte of window is opened every 60
seconds, and how they might be prioritized relative to connections in
the persist state.  Using the mechanism described in the document
leaves a system completely vulnerable to resource exhaustion by such a
slow-acking attacker.  As a developer, why would I choose to implement
this?  Unless these simple variations are addressed, I think it's a
waste of time.

Additionally, most implementations already provide an API for handling
closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER
option.  I don't think this document makes a sufficient justification
for why this existing mechanism is inadequate, or why the proposed API
is necessary or sufficient.

Thanks,
  -John


On Sun, Jan 30, 2011 at 11:27 PM, Wesley Eddy <wes@mti-systems.com> wrote:

On 1/13/2011 10:38 PM, Wesley Eddy wrote:

Based on the discussion of section 7 (programming considerations), the
document on clarifying the persist condition has been updated by the
authors.

The document can be found at:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/

We think this is ready for working group last call now, so with this
email, I'd like to start a two-week WGLC on the document to last until
1/28. Please send your comments to the TCPM list by then.


Since this last call has concluded, I'm planning to do the PROTO writeup and
send up the document to the IESG late this week.  Since this document is
fairly short, includes relatively simple technical material, and was
well-discussed earlier in its history, I wasn't concerned by the lack of
WGLC feedback, but will note it in the writeup.

If there's any disagreement on this, or someone wants more time to review,
please shout in the next couple days, before I submit the document to the
IESG for publication.

--
Wes Eddy
MTI Systems
_______________________________________________
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

--

Mahesh Jethanandani
Technical Leader
ERBU

mahesh@cisco.com
Phone :+1 408 527-8230
Fax :+1 408 853-0762


170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com

  
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


--------------020806020707030802030003 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="spacer.gif" R0lGODlhCgAKAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAKAAoAAAIIlI+py+0PYysA Ow== --------------020806020707030802030003 Content-Type: image/gif; name="footerHead.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footerHead.gif" R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y0 2ouz3rz7D4biSE4FADs= --------------020806020707030802030003 Content-Type: image/gif; name="footer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footer.gif" R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY 2vHy8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAA ACH5BAEAABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOk cslsOp/QqHRKFW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWG h4iJijIYBxclBhIai5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYs DgcUDcHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wADChxIUEYIADs= --------------020806020707030802030003-- --------------090706050408060103060905-- From ananth@cisco.com Mon Jan 31 15:31:29 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBAD3A6BFF for ; Mon, 31 Jan 2011 15:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JW2PDu8AC8g for ; Mon, 31 Jan 2011 15:31:28 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8D1623A6B88 for ; Mon, 31 Jan 2011 15:31:28 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwDAD/VRk2rR7Ht/2dsb2JhbACWG45gc6FMmy2FTgSFE4pZ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2011 23:34:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0VNYicv007802; Mon, 31 Jan 2011 23:34:44 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 15:34:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 15:34:42 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BBA47B6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvBm1d61wBwnJn9Q2auE6oITLWOGAAAE4wA References: <4D2FC53C.4030304@mti-systems.com><4D463A1A.2090301@mti-systems.com> From: "Anantha Ramaiah (ananth)" To: "John Heffner" , "Wesley Eddy" X-OriginalArrivalTime: 31 Jan 2011 23:34:43.0973 (UTC) FILETIME=[7063A350:01CBC19F] Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 23:31:29 -0000 John, We have been through this in the past and the authors have clarified = the reasons for some of the questions being posed by you and others. = Here is yet another attempt. Pl see inline responses :- > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > John Heffner > Sent: Monday, January 31, 2011 3:05 PM > To: Wesley Eddy > Cc: tcpm@ietf.org > Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist >=20 > First, apologies for missing the last call deadline. But I'd like for > the record to state that I don't believe the authors have addressed > the substantive criticisms raised on the list. I'm also not sure that > consensus has been reached on this document, but that is for the > working group chairs to decide. Pl go read the emails threads on this list on this subject. The only = issue, if I recall correctly was, the mention of a socket API in the = document. Now, this is an informational document and the mention of the = socket API is purely for illustrations only and thus doesn't mandate any = new protocol changes. We have also noted very clearly that it is up to = the implementation to chose whatever API it wants to.=20 >=20 > To summarize my position in a single phrase, closing a TCP connection > because it is in the persist state is a mistake. And this document Nobody is advocating that. We are just clarifying that it is OK to close = a connection at any time, persist state in no exception to this rule. = These 2 are different things. What makes you carry an impression that we = are asking implementations to close the connection stuck in persist = state? We are simply clarifying the it is inline with RFC's spirits if = the decision is made consciously.=20 > describes a mechanism to do exactly that. If the language in RFC1122 > needs to be clarified, the clarification should be that a connection > may be aborted while in the persist state. It should not be aborted > *because* it is in the persist state. Where did you get the impression? this has been your stance since day = one, I suggest this as a way to move forward. The authors have tried = their best put the verbiage to clarify the intent. Now, you seem to be = not convinced, it would be nicer if you can :- - read the document and state which sections are not conformant. - suggest a modified text. It is a very short document and hence I guess this shouldn't be a big = deal. >=20 > To be more specific, the majority of the doc describes a DoS attack by > resource exhaustion; however, the persist condition is only a small > subset of this class of resource exhaustion attacks. Addressing only > connections in the persist state ignores the rest of the problem. The > document does not address this very simple well-know attack: > . This document also does not address > connections where, for example, one byte of window is opened every 60 > seconds, and how they might be prioritized relative to connections in > the persist state. Using the mechanism described in the document > leaves a system completely vulnerable to resource exhaustion by such a > slow-acking attacker. As a developer, why would I choose to implement > this? Unless these simple variations are addressed, I think it's a > waste of time. Well, we removed all the resource management stuff from the document = since the WG wanted this document as a simple clarification document. I = thought we added the case of one byte window being opened etc., and why = addressing such a thing is beyond the scope of this document. I can = check the document again... >=20 > Additionally, most implementations already provide an API for handling > closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER > option. I don't think this document makes a sufficient justification > for why this existing mechanism is inadequate, or why the proposed API > is necessary or sufficient. We explained this earlier. SO_LINGER applies only during connection = close. Applications would like to know the reason for connection not = making any progress which includes persist. Now, application is simply = telling TCP layer that if the connection is in persist for more then a = stipulated time, TCP can go ahead and kill the connection in the same = manner like retransmit timeout. Now, I don't want the above statement to = say that RTO and persist need to be treated the same way, we are just = saying that "as long as application closes the connection or has = indicated its willingness to close the connection" it can do so and it = is in spirits of RFC 1122. =20 I am at loss to understand your concers on this very simple document. It = would be nicer if you can point to the exact sections where this = document is vague or isn't clear. Side note :- now this is typical, someone is going to snip portions of = my response and get hung up one statement (may be a language weakness or = something that is not intended etc., ) hence I am urging folks to read = the response in its entirety while responding and not pick (nitpick) on = some text. -Anantha >=20 > Thanks, > -John >=20 >=20 > On Sun, Jan 30, 2011 at 11:27 PM, Wesley Eddy > wrote: > > On 1/13/2011 10:38 PM, Wesley Eddy wrote: > >> > >> Based on the discussion of section 7 (programming considerations), > the > >> document on clarifying the persist condition has been updated by = the > >> authors. > >> > >> The document can be found at: > >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/ > >> > >> We think this is ready for working group last call now, so with = this > >> email, I'd like to start a two-week WGLC on the document to last > until > >> 1/28. Please send your comments to the TCPM list by then. > > > > > > Since this last call has concluded, I'm planning to do the PROTO > writeup and > > send up the document to the IESG late this week. =A0Since this = document > is > > fairly short, includes relatively simple technical material, and was > > well-discussed earlier in its history, I wasn't concerned by the = lack > of > > WGLC feedback, but will note it in the writeup. > > > > If there's any disagreement on this, or someone wants more time to > review, > > please shout in the next couple days, before I submit the document = to > the > > IESG for publication. > > > > -- > > Wes Eddy > > MTI Systems > > _______________________________________________ > > 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 fernando.gont.netbook.win@gmail.com Mon Jan 31 15:35:43 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43EBA3A6B88 for ; Mon, 31 Jan 2011 15:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIt5xJwwUu8k for ; Mon, 31 Jan 2011 15:35:42 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 368FE3A6848 for ; Mon, 31 Jan 2011 15:35:42 -0800 (PST) Received: by gxk27 with SMTP id 27so2577108gxk.31 for ; Mon, 31 Jan 2011 15:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=0upHLUWqezcPNpFnQivvan3jSAwFC/hm/OmUrdo1HE8=; b=Qckwrja3RTcKjM0NLeyY6lAR92vulA/epXpvBxUq/GeLfpUI/KomkWbI05XUWQ9Wti 2jCFWlQPRGh4vHTbcUN4zvFpY4B3cXz35rCOaGuXzextc2MVh5fiazO6FXNz7wKhVOc0 gIFw9mYjM9eGbzdpD3h5IwIDwgxb/+ORXufFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=laewpQLb2+TgpzwFpPEO+5w5Pi5WkjtgjYYamEpJlghvxiBJY/+XrLM/ySTOZWlG/b Xq7KAfZUi2TMibJ8LrFXqLbFGS+ERJBgfWV7Y0hMjM5PHnKacgsZPR5t6OMw8/T0OnBP nRoPMYlv4Gx4fco+HWUIhut30JDXbYkzhgOyE= Received: by 10.100.228.14 with SMTP id a14mr4223225anh.252.1296517135803; Mon, 31 Jan 2011 15:38:55 -0800 (PST) Received: from [192.168.0.121] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id c28sm26471251ana.1.2011.01.31.15.38.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 15:38:55 -0800 (PST) Sender: Fernando Gont Message-ID: <4D4747FD.8030005@gont.com.ar> Date: Mon, 31 Jan 2011 20:38:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Heffner References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 23:35:43 -0000 On 31/01/2011 08:04 p.m., John Heffner wrote: > To be more specific, the majority of the doc describes a DoS attack by > resource exhaustion; however, the persist condition is only a small > subset of this class of resource exhaustion attacks. Addressing only > connections in the persist state ignores the rest of the problem. The > document does not address this very simple well-know attack: > . This document also does not address > connections where, for example, one byte of window is opened every 60 > seconds, and how they might be prioritized relative to connections in > the persist state. Using the mechanism described in the document > leaves a system completely vulnerable to resource exhaustion by such a > slow-acking attacker. As a developer, why would I choose to implement > this? Unless these simple variations are addressed, I think it's a > waste of time. +1 For the record, I raised the same issues a while ago. FWIW, at the point in which resources are exhausted, the system needs to perform heuristics as to which connections are achieving anything useful, which one might make sense to terminate, etc. And to a large extent it becomes irrelevant whether "TCP MAY/SHOULD/MUST NOT abort a connection". -- It becomes a resource management problem, and the system should do what is best to keep offering the best possible service. A connection being in the "persist state" is just *one* of the parameters that may be employed when performed the aforementioned heuristics -- progress on the connection, amount of data successfully transferred so far, etc., etc. are other valuable parameters. Giving that these issues have been publicly discussed for quite a while (e.g., they have been part of a disclosure carried about by CERT-FI as part of the "Sockstress vulnerabilities"), one would expect attack tools to implement the "open the window a little bit, once in a while" (suggested by John Heffner, and also present in draft-ietf-tcpm-tcp-security) and other variants, that would defeat this "mitigation". -- FWIW, I was in the process of implementing this attack vector a while ago (and will resume when I have the time). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From johnwheffner@gmail.com Mon Jan 31 15:45:54 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31C23A6C26 for ; Mon, 31 Jan 2011 15:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBzK8vmXuM-x for ; Mon, 31 Jan 2011 15:45:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 951543A68B1 for ; Mon, 31 Jan 2011 15:45:53 -0800 (PST) Received: by bwz12 with SMTP id 12so6750567bwz.31 for ; Mon, 31 Jan 2011 15:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GuVuJqulb6nhKNVhbLmSobIIeA2ztriA6quI2poXpvI=; b=mC7rD1qo1z4OVzET8MkSs9z+IlhPGgBCN+JRUntKExxnGeEQNL/3yy76P2aTg03nky aB6igOExAjV2r5brwM7al0JUSwMcvUm+GbX1PoJ6XMhm0n7Z7jOZ8VIf0UOvE9S536G4 pcvCWqNJqcHguS/t90ODfB4P+rBuH9KCJmG/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rqk1dDhmBSMLSH/xkKPRGX200euNYmNwQrwNbTtrK/y1YZHoqI6Rr0fbt8MXa/AIm7 3nMhYJZXgjE8TodwgVI/j/lEYO5rBUcmJUy1QwUZCf2qADtnCzCKQH1/w4F7TROSU8Xj gD+ONM6IbHcJBJQF04e6Yd410XsQS/U0IJAUE= MIME-Version: 1.0 Received: by 10.204.58.196 with SMTP id i4mr5900623bkh.119.1296517748347; Mon, 31 Jan 2011 15:49:08 -0800 (PST) Received: by 10.204.121.76 with HTTP; Mon, 31 Jan 2011 15:49:08 -0800 (PST) In-Reply-To: <4D4746F3.3060609@cisco.com> References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <4D4746F3.3060609@cisco.com> Date: Mon, 31 Jan 2011 18:49:08 -0500 Message-ID: From: John Heffner To: Mahesh Jethanandani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 23:45:54 -0000 On Mon, Jan 31, 2011 at 6:34 PM, Mahesh Jethanandani wro= te: > > John, > > I think you missed more than the last call deadline on the document :-) > > If there was ever the intent of this document to define all possible solu= tions to resource exhaustion DoS attacks, it was dropped quite some time ag= o. For the last couple of drafts when it was adopted as WG document, the in= tent was only to clarify the language in RFC 1122. The example given in the= document was to demonstrate how the attack could happen. It was not meant = to encompass all possible attacks. > > We agreed after numerous discussions that documenting and providing solut= ions to the resource exhaustion attacks that you refer to should be taken u= p in a separate document and is out of the scope of this document. It should address the general problem, or not attack the problem at all. Addressing only a single special case in isolation does no real good, and I would argue actually does harm. As an operating system developer, I cannot see any justification to spend time and resources implementing the described changes. I have no objection to a very simple, straightforward clarification to the language in RFC1122, stating that connections MAY be ABORTed while in the persist state. I don't think it will be productive to re-hash all the old conversations, as neither of us have changed our positions. I'm just re-stating my position for the record, as concisely as I can. If there is in fact working group consensus then let's move forward. Thanks, -John From mahesh@cisco.com Mon Jan 31 15:49:28 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4AF3A6C8E for ; Mon, 31 Jan 2011 15:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFZ3hFJ0EJXa for ; Mon, 31 Jan 2011 15:49:27 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 611FD3A6C64 for ; Mon, 31 Jan 2011 15:49:27 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGfaRk2rR7Ht/2dsb2JhbACke3OhRZsvhU4EhROHDg Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2011 23:52:42 +0000 Received: from dhcp-128-107-99-74.cisco.com (dhcp-128-107-99-74.cisco.com [128.107.99.74]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0VNqgs7020223; Mon, 31 Jan 2011 23:52:42 GMT Message-ID: <4D474B8F.4030708@cisco.com> Date: Mon, 31 Jan 2011 15:53:51 -0800 From: Mahesh Jethanandani User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Heffner References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <4D4746F3.3060609@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 31 Jan 2011 23:49:28 -0000 On 1/31/11 3:49 PM, John Heffner wrote: > > I have no objection to a very simple, straightforward clarification to > the language in RFC1122, stating that connections MAY be ABORTed while > in the persist state. That is why the informational draft with a title "Clarification of sender behavior in persist condition". -- mj From ananth@cisco.com Mon Jan 31 17:44:54 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E685F3A6CB7 for ; Mon, 31 Jan 2011 17:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ekL4Y1J6Kh for ; Mon, 31 Jan 2011 17:44:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 221763A6CAD for ; Mon, 31 Jan 2011 17:44:54 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOP0Rk2rR7Ht/2dsb2JhbACke3OgbJtBhU4EhROKWQ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2011 01:48:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p111m9IA010492; Tue, 1 Feb 2011 01:48:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Jan 2011 17:48:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Jan 2011 17:48:08 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BBA48AC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4D4747FD.8030005@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvBoAtayunLGo8rQrW8ZNFE1Dx8TAAEYqbw References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <4D4747FD.8030005@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , "John Heffner" X-OriginalArrivalTime: 01 Feb 2011 01:48:09.0725 (UTC) FILETIME=[143072D0:01CBC1B2] Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: 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, 01 Feb 2011 01:44:55 -0000 Fernando, >=20 > +1 >=20 > For the record, I raised the same issues a while ago. >=20 > FWIW, at the point in which resources are exhausted, the system needs > to > perform heuristics as to which connections are achieving anything > useful, which one might make sense to terminate, etc. And to a large > extent it becomes irrelevant whether "TCP MAY/SHOULD/MUST NOT abort a > connection". -- It becomes a resource management problem, and the > system > should do what is best to keep offering the best possible service. >=20 > A connection being in the "persist state" is just *one* of the > parameters that may be employed when performed the aforementioned > heuristics -- progress on the connection, amount of data successfully > transferred so far, etc., etc. are other valuable parameters. >=20 > Giving that these issues have been publicly discussed for quite a while > (e.g., they have been part of a disclosure carried about by CERT-FI as > part of the "Sockstress vulnerabilities"), one would expect attack > tools > to implement the "open the window a little bit, once in a while" > (suggested by John Heffner, and also present in > draft-ietf-tcpm-tcp-security) and other variants, that would defeat > this > "mitigation". -- FWIW, I was in the process of implementing this attack > vector a while ago (and will resume when I have the time). Well, the best way to address this is to write a separate document which addresses these issues and proposes solutions to the same. This is definitely beyond of the current document which is a simple clarification. The API is part of the clarification. -Anantha