From thomas.r.henderson@boeing.com Tue Feb 1 11:32:47 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 355A83A6D71 for ; Tue, 1 Feb 2011 11:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.38 X-Spam-Level: X-Spam-Status: No, score=-106.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 0U9kw9TGpHYa for ; Tue, 1 Feb 2011 11:32:46 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 078483A6C5F for ; Tue, 1 Feb 2011 11:32:45 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p11JZiLa015176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Feb 2011 11:35:45 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p11JZiHR009992; Tue, 1 Feb 2011 11:35:44 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p11JZijx009985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 1 Feb 2011 11:35:44 -0800 (PST) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 1 Feb 2011 11:35:44 -0800 From: "Henderson, Thomas R" To: "'Alexander Zimmermann'" , tcpm WG Date: Tue, 1 Feb 2011 11:35:43 -0800 Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt Thread-Index: Acu8AIQ1WUBY81KvTBWB0qzFQ8YhaAGPp18Q Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AD74@XCH-NW-10V.nw.nos.boeing.com> References: <20110124183002.11151.53415.idtracker@localhost> <54632421-DEDF-4578-95D7-0727C859A370@comsys.rwth-aachen.de> In-Reply-To: <54632421-DEDF-4578-95D7-0727C859A370@comsys.rwth-aachen.de> 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 Cc: Andrei Gurtov , "floyd@acm.org" 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: Tue, 01 Feb 2011 19:32:47 -0000 Alex, thanks for timely feedback on this draft. Responses inline below... > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Alexander Zimmermann > Sent: Monday, January 24, 2011 11:53 AM > To: tcpm WG > Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-00.txt >=20 > What a coincidence! Just at the moment I wrote my comments about > rfc3782bis, the notification came in... >=20 > 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 >=20 >=20 > * Sec 1: Lack of a proper problem description >=20 > What we have is this (2nd para) >=20 > "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." >=20 > 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) The original RFC (and revisions) jointly addresses two possible problems th= at can occur with multiple losses in a single window: 1) Reno would typica= lly take a timeout (documented in Janey Hoe's Sigcomm '96 paper), and 2) ev= en if an RTO doesn't occur, multiple fast retransmits and window reductions= could occur (documented in Sally Floyd's 1994 technical report). Based on your comment, I would propose to more clearly state the problems r= ather than the current language that says "Problems can arise...". >=20 >=20 > * New Sec between Sec 2 and Sec 3: Basic idea of the algo >=20 > I love basic ideas! In that case the reader has some ideas how the algo > works, before he read it step by step. Rather than a new section, I would propose just adding something like this = to the top of Section 3: "The basic idea of these modifications is to infer, from the arrival of dup= licate acknowledgements, whether multiple losses in the same window of data= have most likely occurred, and to avoid taking a retransmit timeout or mak= ing multiple congestion window reductions due to such an event." >=20 > Here, we could also directly mention that the following step 1), 1b) > and 6) 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. This problem was originally addressed in Section 5 of RFC 2582, so it was n= ot new for RFC 3782. In RFC 2582, implementors had to implement the steps = in Section 3, then read Section 5 and consider adding more steps to those f= ound in Section 3, and to make a policy choice as to which variant of Secti= on 5 to implement. In RFC 3782, a single variant was moved forward and int= egrated with Section 3, so that implementors could just follow a single spe= cification section (Section 3). =20 >=20 >=20 > * Sec 5: IMO delete it or move it to an appendix. I would be OK with moving it to an appendix since it is not normative mater= ial and discusses variations. >=20 >=20 > * Sec 6: Really, really complicated... >=20 > Take for example RFC2582 or [GF04] (only the intro). Much easier to > understand. With > this two doc, you can understand the problem. >=20 > For example: > - In RFC3782, 1st para: It confused the reader more than it helps. > - 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." >=20 > 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. Without responding point-by-point to the above, I agree that this section w= ould benefit from a rewrite. >=20 >=20 > * IMO Section 7,8,9,10,11 should move to an appendix I would prefer to keep sections 7 and 8 in the main body since it is materi= al that would be useful for implementors to keep in mind. However, I can s= ee the rationale for moving the other sections (9-11) to appendices since t= hey are more background/informational. Regarding the citation of ns-2 scripts, I think that it is very useful to b= e able to refer to these scripts because they document each issue precisely= , but I realize that it is probably uncommon to cite them inline in the tex= t as is presently done. Perhaps in the revision, these can either be moved= to the appendices or else turned into more traditional (informative) refer= ence citations. - Tom=20 >=20 > Alex >=20 > [GF04]: Resolving Acknowledgment Ambiguity in non-SACK TCP >=20 From faber@isi.edu Tue Feb 1 21:20: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 78F473A6B08 for ; Tue, 1 Feb 2011 21:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 raSI2ef28Bzh for ; Tue, 1 Feb 2011 21:20:40 -0800 (PST) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by core3.amsl.com (Postfix) with ESMTP id D299C3A6833 for ; Tue, 1 Feb 2011 21:20:40 -0800 (PST) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id p125Nxci074672; Tue, 1 Feb 2011 21:23:59 -0800 (PST) (envelope-from faber@isi.edu) Date: Tue, 1 Feb 2011 21:23:58 -0800 From: Ted Faber To: Wesley Eddy Message-ID: <20110202052358.GA74200@zod.isi.edu> References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <4D463A1A.2090301@mti-systems.com> X-url: http://www.isi.edu/~faber User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 02 Feb 2011 05:20:42 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 30, 2011 at 11:27:06PM -0500, Wesley Eddy wrote: > 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. After I saw John's mail eariler today, I had a late look at this document. I don't support it for publication at this time, though that may not mean anything after Last Call. My concerns can be summed up in Section 5 and Section 7. Here's Section 5, Conclusions, in its entirety: The document addresses the fact that terminating TCP connections stuck in the persist condition does not violate RFC 1122 or RFC 793. It also suggests that TCP must not abort any connection until explicitly requested by the application or the operating system to do so. The potential implementation guidelines of the request and the action are documented in Section 7, and the details of mitigating the DoS attack are left to the implementer. That seems to say that the document says nothing at all, until the last sentence. The authors address the fact that an ESTABLISHED connection with a zero window doesn't violate any standards and that such connections shouldn't be spontaneously aborted by the TCP protocol engine. That's true, but not news. Then there's that last muddy sentence; I can't quite follow what it's getting, but it points me to a substantive section that follows the Conclusions Section (!) describing an API: The above interface allows applications to inform TCP that when the local connection stays in persist condition it can be aborted after a set time. That text describes an API that instructs the TCP engine to do exactly what the conclusions (and the RFCs) tell me is non-conformant: abort a valid connection. It seems to me that the right way to describe the interface in Section 7 is to say that it lets the application tell the OS about the application's preferences for releasing resources if they get scarce. "The above interface allows applications to inform *the* *Operating* *System*..." I think that makes the section compliant with the RFCs cited in the Conclusions, but I think it stops being an IETF document at that point. This may be water under the bridge now, but John made me curious and I figured I'd chime in. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1I6m4ACgkQaUz3f+Zf+Xvh5gCgzRNnOQY4bxuFk1Jb078VKTNY dZoAoMSGkzN1iYoc1q7L0Too8dgcXNJn =bLOG -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From fernando.gont.netbook.win@gmail.com Tue Feb 1 21:38:47 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 889A03A6B66 for ; Tue, 1 Feb 2011 21:38:47 -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 tIoCgcnYpSJL for ; Tue, 1 Feb 2011 21:38:46 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id AD7943A6B67 for ; Tue, 1 Feb 2011 21:38:46 -0800 (PST) Received: by ywk9 with SMTP id 9so3233819ywk.31 for ; Tue, 01 Feb 2011 21:42:05 -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=IKhpvVxpgYpjAZoqXllk20ZJgfl37a+mGiMs33jMnRM=; b=aPvjj3OnSuOXHIGq8YhyZ/0FWvcqWxaQSTwCixgiBE8OBYf+yGENX48i0apPTNrXZL JGfqRlk77XOOCnO9PnuDewE+cVkUYUE7hWooKp5PHwGyT6fBuJUlCXHjfCZK3DIMIKfP 6xYN4JSe8WJaxfXiE3S0GY1aRTdjOYlTaLlzQ= 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=j+RB2EkTPUgk9KCve3xb+pXhnSVmDjtouqcSXugs8wCUcnN21GvgZdlIBSgcIgraRf BU5Q2deTW8Yhj3eSVRfxVpJ8QlckWN+i/jRIL18TDXyb/sRd1EWgZDVvDGehbL9R0vCM +JFWJ9qHWD98/HyVAmSoXNmKj4Rndba/4wc2E= Received: by 10.90.52.5 with SMTP id z5mr11833915agz.181.1296625325269; Tue, 01 Feb 2011 21:42:05 -0800 (PST) Received: from [192.168.2.5] ([190.246.229.147]) by mx.google.com with ESMTPS id x62sm5788253yhc.30.2011.02.01.21.42.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 21:42:03 -0800 (PST) Sender: Fernando Gont Message-ID: <4D48EE9C.6030905@gont.com.ar> Date: Wed, 02 Feb 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: "Anantha Ramaiah (ananth)" References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <4D4747FD.8030005@gont.com.ar> <0C53DCFB700D144284A584F54711EC580BBA48AC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580BBA48AC@xmb-sjc-21c.amer.cisco.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] 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: Wed, 02 Feb 2011 05:38:47 -0000 Hi, Anantha, On 31/01/2011 10:48 p.m., Anantha Ramaiah (ananth) wrote: > 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. FWIW, all these issues (including netkill, Naphta, etc.) are discussed in draft-ietf-tcpm-tcp-security. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From faber@isi.edu Wed Feb 2 09:19: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 D374C3A6C05 for ; Wed, 2 Feb 2011 09:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 WGsDagB-Qts0 for ; Wed, 2 Feb 2011 09:19:20 -0800 (PST) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by core3.amsl.com (Postfix) with ESMTP id BA33F3A6BC0 for ; Wed, 2 Feb 2011 09:19:20 -0800 (PST) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id p12HMdok082178; Wed, 2 Feb 2011 09:22:39 -0800 (PST) (envelope-from faber@isi.edu) Date: Wed, 2 Feb 2011 09:22:38 -0800 From: Ted Faber To: Wesley Eddy Message-ID: <20110202172237.GB81723@zod.isi.edu> References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <20110202052358.GA74200@zod.isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <20110202052358.GA74200@zod.isi.edu> X-url: http://www.isi.edu/~faber User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 02 Feb 2011 17:19:21 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 01, 2011 at 09:23:58PM -0800, Ted Faber wrote: > Then there's that last muddy sentence; I can't quite follow what it's > getting, but it points me to a substantive section that follows the > Conclusions Section (!) describing an API: >=20 > The above interface allows applications to inform TCP that when > the local connection stays in persist condition it can be > aborted after a set time. >=20 > That text describes an API that instructs the TCP engine to do exactly > what the conclusions (and the RFCs) tell me is non-conformant: abort a > valid connection. Some private mail to me indicated that I do need to split the hair that's inherent in that description: namely that the new interface proposed in this informational document is really just a way for an application to abort a TCP connection. I disagree. But, you know what? That's not my problem at all. I apologize for wasting the authors' and the WG's time picking nits when I have a more fundamental objection and should have just said it. My problem is that the document is not clear enough. If the authors and the WG want to say that TCP connections can get stuck in a zero-window state and that can chew up enough resources to DoS the endpoint, that's great. If they want to also say that the authors have had success with an OS interface that allows the OS to preferentially abort connections in that state, I'm all for it. Content is not really the source of my objections. This text does not clearly lay that out at all. If you read through the intro there is no indication that there's a mitigation to be proposed, and there's only that confusing sentence in the conclusions that points to "potential implementation guidelines of the request and action" in a section buried after the Acknowledgements. I think that only people who were involved with this discussion will be able to tell what we're talking about. That "we" is intentional: this is a WG document. For the record: I think that the idea here is fine, assuming that I correctly summarized it above. This presentation is unclear enough that I don't think we should publish it as written. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1Jkt0ACgkQaUz3f+Zf+Xs8ZwCgkMt5/Q7nINH/Hc5I7A6Frzm/ 1KoAoKKEuPBpub3Vyu5SO4ptdK6FzBrh =DYi3 -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From touch@isi.edu Wed Feb 2 09:46: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 377943A6D2C for ; Wed, 2 Feb 2011 09:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 R0wTabuTbWb4 for ; Wed, 2 Feb 2011 09:46:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 32F433A6CDC for ; Wed, 2 Feb 2011 09:46:05 -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 p12Hn4Wf002713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 09:49:04 -0800 (PST) Message-ID: <4D499910.7030003@isi.edu> Date: Wed, 02 Feb 2011 09:49: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: Ted Faber References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <20110202052358.GA74200@zod.isi.edu> <20110202172237.GB81723@zod.isi.edu> In-Reply-To: <20110202172237.GB81723@zod.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] 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: Wed, 02 Feb 2011 17:46:06 -0000 Hi, Ted (et al.), My view is that this doc was supposed to say (and I thought said): - connections can get stuck - users and/or the OS (on behalf of users as a group) can *always* abort connections to protect resources The latter appears to be the point of needing this doc. I.e., that a TCP connection is not "protected" as a resource once initiated; the OS can always reclaim it. I never thought we needed an RFC to say that. IMO, the OS aborting the connection for these reasons is basically just using the existing RFC 793 interface as a proxy for the user, and there's no ambiguity. The rest of the issue is an implementation issue that (I agree with Ted) should not be in an RFC. But I've made that point before. Joe On 2/2/2011 9:22 AM, Ted Faber wrote: > On Tue, Feb 01, 2011 at 09:23:58PM -0800, Ted Faber wrote: >> Then there's that last muddy sentence; I can't quite follow what it's >> getting, but it points me to a substantive section that follows the >> Conclusions Section (!) describing an API: >> >> The above interface allows applications to inform TCP that when >> the local connection stays in persist condition it can be >> aborted after a set time. >> >> That text describes an API that instructs the TCP engine to do exactly >> what the conclusions (and the RFCs) tell me is non-conformant: abort a >> valid connection. > > Some private mail to me indicated that I do need to split the hair > that's inherent in that description: namely that the new interface > proposed in this informational document is really just a way for an > application to abort a TCP connection. I disagree. > > But, you know what? That's not my problem at all. I apologize for > wasting the authors' and the WG's time picking nits when I have a more > fundamental objection and should have just said it. > > My problem is that the document is not clear enough. > > If the authors and the WG want to say that TCP connections can get stuck > in a zero-window state and that can chew up enough resources to DoS the > endpoint, that's great. If they want to also say that the authors have > had success with an OS interface that allows the OS to preferentially > abort connections in that state, I'm all for it. Content is not really > the source of my objections. > > This text does not clearly lay that out at all. If you read through the > intro there is no indication that there's a mitigation to be proposed, > and there's only that confusing sentence in the conclusions that points > to "potential implementation guidelines of the request and action" in a > section buried after the Acknowledgements. > > I think that only people who were involved with this discussion will be > able to tell what we're talking about. That "we" is intentional: this > is a WG document. > > For the record: I think that the idea here is fine, assuming that I > correctly summarized it above. This presentation is unclear enough that > I don't think we should publish it as written. > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From faber@isi.edu Wed Feb 2 10:19: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 90C3C3A6D27 for ; Wed, 2 Feb 2011 10:19:24 -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 dI59IrVIdZkE for ; Wed, 2 Feb 2011 10:19:23 -0800 (PST) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by core3.amsl.com (Postfix) with ESMTP id 84D203A6C11 for ; Wed, 2 Feb 2011 10:19:23 -0800 (PST) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id p12IMhkU083046; Wed, 2 Feb 2011 10:22:43 -0800 (PST) (envelope-from faber@isi.edu) Date: Wed, 2 Feb 2011 10:22:43 -0800 From: Ted Faber To: Joe Touch Message-ID: <20110202182243.GE81723@zod.isi.edu> References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <20110202052358.GA74200@zod.isi.edu> <20110202172237.GB81723@zod.isi.edu> <4D499910.7030003@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sfyO1m2EN8ZOtJL6" Content-Disposition: inline In-Reply-To: <4D499910.7030003@isi.edu> X-url: http://www.isi.edu/~faber User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 02 Feb 2011 18:19:24 -0000 --sfyO1m2EN8ZOtJL6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I will pick nits with you, just for fun. :-) (Avert your eyes, draft authors.) On Wed, Feb 02, 2011 at 09:49:04AM -0800, Joe Touch wrote: > My view is that this doc was supposed to say (and I thought said): >=20 > - connections can get stuck >=20 > - users and/or the OS (on behalf of users as a group) can *always* abort= =20 > connections to protect resources >=20 > The latter appears to be the point of needing this doc. I.e., that a TCP= =20 > connection is not "protected" as a resource once initiated; the OS can=20 > always reclaim it. > > I never thought we needed an RFC to say that. Any protocol standard that claims the right to make resource decisions on behalf of the OS is pretty well doomed, and I don't think 793 or 1122 make any such claims. So, yeah, we agree that the RFCs are OK. >=20 > IMO, the OS aborting the=20 > connection for these reasons is basically just using the existing RFC=20 > 793 interface as a proxy for the user, and there's no ambiguity. And heeeeeeeeere's the nit: The OS doesn't need to do any such thing. A purist (and I think I'm talking to one :-)) would argue that there is no OS/TCP interface specified by the IETF, nor should there be. The OS simply reclaims the resources allocated to the TCP connection using whatever internal interface it has. That may look like an abort or it may be less sophisticated. For example, the OS may use the internal interface of killing the process holding the most open TCP connections. As long as the reclaimed connection(s) go(es) into the CLOSED state, the TCP protocol engine will DTRT, and no one cares how they got there. A Good Thing, IMHO. > The rest of the issue is an implementation issue that (I agree with Ted)= =20 > should not be in an RFC. But I've made that point before. While there's no need to standardize the interface they propose, I don't see a problem with saying that this is an interface that the authors have used and liked. Couldn't hurt, might help. But it needs to be clear, or it only stirs up nit-pickers. Uh, stirring up nit-pickers could hurt, so I guess I'm wrong... :-) --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --sfyO1m2EN8ZOtJL6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1JoPMACgkQaUz3f+Zf+XtOVQCgqvcmiXR2A+ehwh5ppBqiFtnc TlYAn0ysW9wN5Q/sxbuWuhsupMfAoqYe =BMsB -----END PGP SIGNATURE----- --sfyO1m2EN8ZOtJL6-- From touch@isi.edu Wed Feb 2 10:43: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 0A2503A6B6E for ; Wed, 2 Feb 2011 10:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 vRVckYG9OKvo for ; Wed, 2 Feb 2011 10:43:03 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 485FC3A67B7 for ; Wed, 2 Feb 2011 10:43:03 -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 p12IjvaL023404 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 10:45:57 -0800 (PST) Message-ID: <4D49A655.1050009@isi.edu> Date: Wed, 02 Feb 2011 10:45:41 -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: Ted Faber References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <20110202052358.GA74200@zod.isi.edu> <20110202172237.GB81723@zod.isi.edu> <4D499910.7030003@isi.edu> <20110202182243.GE81723@zod.isi.edu> In-Reply-To: <20110202182243.GE81723@zod.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p12IjvaL023404 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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: Wed, 02 Feb 2011 18:43:04 -0000 Hi, Ted, Overall, I think we agree. two points, however: On 2/2/2011 10:22 AM, Ted Faber wrote: > I will pick nits with you, just for fun. :-) (Avert your eyes, draft > authors.) > > On Wed, Feb 02, 2011 at 09:49:04AM -0800, Joe Touch wrote: >> My view is that this doc was supposed to say (and I thought said): >> >> - connections can get stuck >> >> - users and/or the OS (on behalf of users as a group) can *always* abort >> connections to protect resources >> >> The latter appears to be the point of needing this doc. I.e., that a TCP >> connection is not "protected" as a resource once initiated; the OS can >> always reclaim it. >> >> I never thought we needed an RFC to say that. > > Any protocol standard that claims the right to make resource decisions > on behalf of the OS is pretty well doomed, and I don't think 793 or 1122 > make any such claims. > > So, yeah, we agree that the RFCs are OK. We do, but I think consensus in the WG is that not everyone does, which is why the WG has decided it's useful here to say "the OS always had the right to do this". (I personally don't think it's necessary, but understand the WG see it this way) ... >> The rest of the issue is an implementation issue that (I agree with Ted) >> should not be in an RFC. But I've made that point before. > > While there's no need to standardize the interface they propose, I don't > see a problem with saying that this is an interface that the authors > have used and liked. > > Couldn't hurt, might help. But it needs to be clear, or it only stirs > up nit-pickers. Agreed. Joe From ananth@cisco.com Wed Feb 2 11:09: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 056FC3A6DCA for ; Wed, 2 Feb 2011 11:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 eDkmdR6fsIfS for ; Wed, 2 Feb 2011 11:09:58 -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 24F743A6DC7 for ; Wed, 2 Feb 2011 11:09:58 -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: AvABAE87SU2rR7Hu/2dsb2JhbACWOo5ic6BcmyqFUwSEeIoZiDI Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2011 19:13:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p12JDBWS018153; Wed, 2 Feb 2011 19:13:18 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); Wed, 2 Feb 2011 11:13:15 -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: Wed, 2 Feb 2011 11:13:14 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BC43EFB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20110202172237.GB81723@zod.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC on draft-ietf-tcpm-persist Thread-Index: AcvC/dQBEsRDvZmsTFiXpFVvtIfyeAAAiEBQ References: <4D2FC53C.4030304@mti-systems.com><4D463A1A.2090301@mti-systems.com><20110202052358.GA74200@zod.isi.edu> <20110202172237.GB81723@zod.isi.edu> From: "Anantha Ramaiah (ananth)" To: "Ted Faber" , "Wesley Eddy" X-OriginalArrivalTime: 02 Feb 2011 19:13:15.0928 (UTC) FILETIME=[3E697180:01CBC30D] 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: Wed, 02 Feb 2011 19:09:59 -0000 Ted, Some responses inline :-=20 And a question at the end, which is probably the one that matters for moving forward. > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Ted Faber > Sent: Wednesday, February 02, 2011 9:23 AM > To: Wesley Eddy > Cc: tcpm@ietf.org > Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist >=20 > On Tue, Feb 01, 2011 at 09:23:58PM -0800, Ted Faber wrote: > > Then there's that last muddy sentence; I can't quite follow what it's > > getting, but it points me to a substantive section that follows the > > Conclusions Section (!) describing an API: > > > > The above interface allows applications to inform TCP that when > > the local connection stays in persist condition it can be > > aborted after a set time. > > > > That text describes an API that instructs the TCP engine to do > exactly > > what the conclusions (and the RFCs) tell me is non-conformant: abort > a > > valid connection. >=20 > Some private mail to me indicated that I do need to split the hair > that's inherent in that description: namely that the new interface > proposed in this informational document is really just a way for an > application to abort a TCP connection.=20 That's actually the point. More so, we also state that it is left to the implementers to design a better API if they wish to do so. > I disagree. >=20 > But, you know what? That's not my problem at all. I apologize for > wasting the authors' and the WG's time picking nits when I have a more > fundamental objection and should have just said it. >=20 > My problem is that the document is not clear enough. >=20 > If the authors and the WG want to say that TCP connections can get > stuck in a zero-window state and that can chew up enough resources to > DoS the endpoint, that's great. If they want to also say that the > authors have had success with an OS interface that allows the OS to > preferentially abort connections in that state, I'm all for it. > Content is not really the source of my objections. Ok. >=20 > This text does not clearly lay that out at all. If you read through > the intro there is no indication that there's a mitigation to be > proposed, and there's only that confusing sentence in the conclusions > that points to "potential implementation guidelines of the request and > action" in a section buried after the Acknowledgements. >=20 > I think that only people who were involved with this discussion will be > able to tell what we're talking about. That "we" is intentional: this > is a WG document. I'll have to dig up the emails, but the current content (which includes pushing things to the appendix)) is all in response to the feedback received from the WG. >=20 > For the record: I think that the idea here is fine, assuming that I > correctly summarized it above. This presentation is unclear enough > that I don't think we should publish it as written. Any suggestions for a better looking layout?=20 Thanks, -Anantha From faber@isi.edu Wed Feb 2 11:27: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 C0EA33A6C41 for ; Wed, 2 Feb 2011 11:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 D-UxsTlcQ7Ev for ; Wed, 2 Feb 2011 11:27:57 -0800 (PST) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by core3.amsl.com (Postfix) with ESMTP id 9F9EB3A6BEE for ; Wed, 2 Feb 2011 11:27:57 -0800 (PST) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.4/8.14.4) with ESMTP id p12JVH67083949; Wed, 2 Feb 2011 11:31:17 -0800 (PST) (envelope-from faber@isi.edu) Date: Wed, 2 Feb 2011 11:31:16 -0800 From: Ted Faber To: "Anantha Ramaiah (ananth)" Message-ID: <20110202193116.GH81723@zod.isi.edu> References: <4D2FC53C.4030304@mti-systems.com> <4D463A1A.2090301@mti-systems.com> <20110202052358.GA74200@zod.isi.edu> <20110202172237.GB81723@zod.isi.edu> <0C53DCFB700D144284A584F54711EC580BC43EFB@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SdvjNjn6lL3tIsv0" Content-Disposition: inline In-Reply-To: <0C53DCFB700D144284A584F54711EC580BC43EFB@xmb-sjc-21c.amer.cisco.com> X-url: http://www.isi.edu/~faber User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 02 Feb 2011 19:27:58 -0000 --SdvjNjn6lL3tIsv0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 02, 2011 at 11:13:14AM -0800, Anantha Ramaiah (ananth) wrote: > > -----Original Message----- > > But, you know what? That's not my problem at all. I apologize for > > wasting the authors' and the WG's time picking nits when I have a more > > fundamental objection and should have just said it. > >=20 > > My problem is that the document is not clear enough. > >=20 > > If the authors and the WG want to say that TCP connections can get > > stuck in a zero-window state and that can chew up enough resources to > > DoS the endpoint, that's great. If they want to also say that the > > authors have had success with an OS interface that allows the OS to > > preferentially abort connections in that state, I'm all for it. > > Content is not really the source of my objections. >=20 > Ok. >=20 > >=20 > > This text does not clearly lay that out at all. If you read through > > the intro there is no indication that there's a mitigation to be > > proposed, and there's only that confusing sentence in the conclusions > > that points to "potential implementation guidelines of the request and > > action" in a section buried after the Acknowledgements. > >=20 > > I think that only people who were involved with this discussion will > be > > able to tell what we're talking about. That "we" is intentional: this > > is a WG document. >=20 > I'll have to dig up the emails, but the current content (which includes > pushing things to the appendix)) is all in response to the feedback > received from the WG. If the authors intend Section 7 to be an appendix, I suggest calling it Appendix 1, for starters. > > For the record: I think that the idea here is fine, assuming that I > > correctly summarized it above. This presentation is unclear enough > > that I don't think we should publish it as written. >=20 > Any suggestions for a better looking layout?=20 I think I was unclear again. I'm not looking for a better looking layout. The text of the draft needs to be clearer. When I said content wasn't my problem, I meant that the ideas that the WG has converged on (as I understand and summarized them in my message you quoted above) are fine with me. The words in the document are unclear to the point that people who have not been part of the WG will not, IMHO, understand what we are talking about at all. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --SdvjNjn6lL3tIsv0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1JsQQACgkQaUz3f+Zf+XsF6wCgqi96gJNJzGwt6+MGp6dWlXHI jx8AniZqUXflvQaVtVEykFcohf/HCCeu =O1S7 -----END PGP SIGNATURE----- --SdvjNjn6lL3tIsv0-- From iesg-secretary@ietf.org Wed Feb 2 13:51: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 3C3163A6DDF; Wed, 2 Feb 2011 13:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2k11TVunhLfq; Wed, 2 Feb 2011 13:51:57 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFB73A6864; Wed, 2 Feb 2011 13:51:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110202215157.24554.29312.idtracker@localhost> Date: Wed, 02 Feb 2011 13:51:57 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic Status) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 21:51:59 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic Status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-eggert-tcpm-historicize/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eggert-tcpm-historicize/ No IPR declarations have been submitted directly on this I-D. From mahesh@cisco.com Wed Feb 2 17:58: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 815DB3A66B4 for ; Wed, 2 Feb 2011 17:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.813 X-Spam-Level: X-Spam-Status: No, score=-9.813 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, 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 a5VdxGNvGojc for ; Wed, 2 Feb 2011 17:58:38 -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 2F47E3A659A for ; Wed, 2 Feb 2011 17:58:38 -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: Av0EACubSU2rR7Ht/2dsb2JhbACgP4Rsc6BamzCFUwSEeIZq Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 02:01:59 +0000 Received: from sjc-vpnasa1-99.cisco.com (sjc-vpnasa1-99.cisco.com [10.21.104.99]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1321xV6024278 for ; Thu, 3 Feb 2011 02:01:59 GMT Message-ID: <4D4A0CDE.5030605@cisco.com> Date: Wed, 02 Feb 2011 18:03:10 -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><20110202052358.GA74200@zod.isi.edu><20110202172237.GB81723@zod.isi.edu><0C53DCFB700D144284A584F54711EC580BC43EFB@xmb-sjc-21c.amer.cisco.com> <20110202193116.GH81723@zod.isi.edu> In-Reply-To: <20110202193116.GH81723@zod.isi.edu> Content-Type: multipart/alternative; boundary="------------060904090503090309000604" 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: Thu, 03 Feb 2011 01:58:39 -0000 This is a multi-part message in MIME format. --------------060904090503090309000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ted, If I am reading you right, these are the changes you are suggesting. * Clarify in the introduction that connections that get stuck in zero-window state can chew up enough resources to put the end point in a DoS condition. * Add a statement in the introduction section that talks about the implementation guideline later in the document. * Change the last sentence in Section 5 to say that Section 7 talks about the implementation guideline. * Change Section 7 to say Appendix 1. Anything else? If you can suggest particular text to any of the items let me know. Thanks. On 2/2/11 11:31 AM, Ted Faber wrote: > > > > > My problem is that the document is not clear enough. > > > > > > If the authors and the WG want to say that TCP connections can get > > > stuck in a zero-window state and that can chew up enough resources to > > > DoS the endpoint, that's great. If they want to also say that the > > > authors have had success with an OS interface that allows the OS to > > > preferentially abort connections in that state, I'm all for it. > > > Content is not really the source of my objections. > > > > Ok. > > > > > > > > This text does not clearly lay that out at all. If you read through > > > the intro there is no indication that there's a mitigation to be > > > proposed, and there's only that confusing sentence in the conclusions > > > that points to "potential implementation guidelines of the request and > > > action" in a section buried after the Acknowledgements. > > > > > > I think that only people who were involved with this discussion will > > be > > > able to tell what we're talking about. That "we" is intentional: this > > > is a WG document. > > > > I'll have to dig up the emails, but the current content (which includes > > pushing things to the appendix)) is all in response to the feedback > > received from the WG. > > If the authors intend Section 7 to be an appendix, I suggest calling it > Appendix 1, for starters. > > > > For the record: I think that the idea here is fine, assuming that I > > > correctly summarized it above. This presentation is unclear enough > > > that I don't think we should publish it as written. > > > > Any suggestions for a better looking layout? > > I think I was unclear again. I'm not looking for a better looking > layout. The text of the draft needs to be clearer. > > When I said content wasn't my problem, I meant that the ideas that the > WG has converged on (as I understand and summarized them in my message > you quoted above) are fine with me. > > The words in the document are unclear to the point that people who have > not been part of the WG will not, IMHO, understand what we are talking > about at all. > > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG > > -- mj --------------060904090503090309000604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ted,

If I am reading you right, these are the changes you are suggesting.
  • Clarify in the introduction that connections that get stuck in zero-window state can chew up enough resources to put the end point in a DoS condition.
  • Add a statement in the introduction section that talks about the implementation guideline later in the document.
  • Change the last sentence in Section 5 to say that Section 7 talks about the implementation guideline.
  • Change Section 7 to say Appendix 1.
Anything else?

If you can suggest particular text to any of the items let me know.

Thanks.

On 2/2/11 11:31 AM, Ted Faber wrote:
Re: [tcpm] WGLC on draft-ietf-tcpm-persist


> > My problem is that the document is not clear enough.
> >
> > If the authors and the WG want to say that TCP connections can get
> > stuck in a zero-window state and that can chew up enough resources to
> > DoS the endpoint, that's great.  If they want to also say that the
> > authors have had success with an OS interface that allows the OS to
> > preferentially abort connections in that state, I'm all for it.
> > Content is not really the source of my objections.
>
> Ok.
>
> >
> > This text does not clearly lay that out at all.  If you read through
> > the intro there is no indication that there's a mitigation to be
> > proposed, and there's only that confusing sentence in the conclusions
> > that points to "potential implementation guidelines of the request and
> > action" in a section buried after the Acknowledgements.
> >
> > I think that only people who were involved with this discussion will
> be
> > able to tell what we're talking about.  That "we" is intentional: this
> > is a WG document.
>
> I'll have to dig up the emails, but the current content (which includes
> pushing things to the appendix)) is all in response to the feedback
> received from the WG.

If the authors intend Section 7 to be an appendix, I suggest calling it
Appendix 1, for starters.

> > For the record: I think that the idea here is fine, assuming that I
> > correctly summarized it above.  This presentation is unclear enough
> > that I don't think we should publish it as written.
>
> Any suggestions for a better looking layout?

I think I was unclear again.  I'm not looking for a better looking
layout.  The text of the draft needs to be clearer.

When I said content wasn't my problem, I meant that the ideas that the
WG has converged on (as I understand and summarized them in my message
you quoted above) are fine with me.

The words in the document are unclear to the point that people who have
not been part of the WG will not, IMHO, understand what we are talking
about at all.

--
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG


-- mj
--------------060904090503090309000604-- From alexander.zimmermann@comsys.rwth-aachen.de Thu Feb 3 00:20:47 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 D6E463A688B for ; Thu, 3 Feb 2011 00:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.721 X-Spam-Level: X-Spam-Status: No, score=-4.721 tagged_above=-999 required=5 tests=[AWL=0.080, 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 fGkB26yyvTVn for ; Thu, 3 Feb 2011 00:20:45 -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 25CE53A68A4 for ; Thu, 3 Feb 2011 00:20:44 -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 <0LG100JG88O4ZXB0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 03 Feb 2011 09:24:04 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,418,1291590000"; d="sig'?scan'208";a="91955120" 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; Thu, 03 Feb 2011 09:24:04 +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 <0LG1002L58O4V770@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 03 Feb 2011 09:24:04 +0100 (CET) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-4-586662477 Content-transfer-encoding: 7bit Date: Thu, 03 Feb 2011 09:24:02 +0100 References: <20110202.170750.229739784.davem@davemloft.net> To: tcpm WG Message-id: <968B0DAD-4487-4543-B7B0-405A930EC36B@comsys.rwth-aachen.de> X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: [tcpm] Fwd: [PATCH] tcp: Increase the initial congestion window to 10. 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, 03 Feb 2011 08:20:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4-586662477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anfang der weitergeleiteten E-Mail: > Von: David Miller > Datum: 3. Februar 2011 02:07:50 MEZ > An: > Kopie: , > Betreff: [PATCH] tcp: Increase the initial congestion window to 10. >=20 >=20 > Signed-off-by: David S. Miller > --- >=20 > I've left the DCCP code to keep using RFC3390 logic, if they > wish to adopt this change in their code they can do so by > simply deleting the rfc33390_bytes_to_packets() function and > using TCP_INIT_CWND in their assignment. >=20 > include/net/tcp.h | 12 +++--------- > net/dccp/ccids/ccid2.c | 9 +++++++++ > net/ipv4/tcp_input.c | 2 +- > 3 files changed, 13 insertions(+), 10 deletions(-) >=20 > diff --git a/include/net/tcp.h b/include/net/tcp.h > index 9179111..7118668 100644 > --- a/include/net/tcp.h > +++ b/include/net/tcp.h > @@ -196,6 +196,9 @@ extern void tcp_time_wait(struct sock *sk, int = state, int timeo); > /* TCP thin-stream limits */ > #define TCP_THIN_LINEAR_RETRIES 6 /* After 6 linear retries, do = exp. backoff */ >=20 > +/* TCP initial congestion window */ > +#define TCP_INIT_CWND 10 > + > extern struct inet_timewait_death_row tcp_death_row; >=20 > /* sysctl variables for tcp */ > @@ -799,15 +802,6 @@ static inline __u32 tcp_current_ssthresh(const = struct sock *sk) > /* Use define here intentionally to get WARN_ON location shown at the = caller */ > #define tcp_verify_left_out(tp) WARN_ON(tcp_left_out(tp) > = tp->packets_out) >=20 > -/* > - * Convert RFC 3390 larger initial window into an equivalent number = of packets. > - * This is based on the numbers specified in RFC 5681, 3.1. > - */ > -static inline u32 rfc3390_bytes_to_packets(const u32 smss) > -{ > - return smss <=3D 1095 ? 4 : (smss > 2190 ? 2 : 3); > -} > - > extern void tcp_enter_cwr(struct sock *sk, const int set_ssthresh); > extern __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry = *dst); >=20 > diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c > index e96d5e8..fadecd2 100644 > --- a/net/dccp/ccids/ccid2.c > +++ b/net/dccp/ccids/ccid2.c > @@ -583,6 +583,15 @@ done: > dccp_ackvec_parsed_cleanup(&hc->tx_av_chunks); > } >=20 > +/* > + * Convert RFC 3390 larger initial window into an equivalent number = of packets. > + * This is based on the numbers specified in RFC 5681, 3.1. > + */ > +static inline u32 rfc3390_bytes_to_packets(const u32 smss) > +{ > + return smss <=3D 1095 ? 4 : (smss > 2190 ? 2 : 3); > +} > + > static int ccid2_hc_tx_init(struct ccid *ccid, struct sock *sk) > { > struct ccid2_hc_tx_sock *hc =3D ccid_priv(ccid); > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index eb7f82e..2f692ce 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -817,7 +817,7 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, struct = dst_entry *dst) > __u32 cwnd =3D (dst ? dst_metric(dst, RTAX_INITCWND) : 0); >=20 > if (!cwnd) > - cwnd =3D rfc3390_bytes_to_packets(tp->mss_cache); > + cwnd =3D TCP_INIT_CWND; > return min_t(__u32, cwnd, tp->snd_cwnd_clamp); > } >=20 > --=20 > 1.7.4 >=20 > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html // // 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-4-586662477 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) iEYEARECAAYFAk1KZiIACgkQdyiq39b9uS4DIgCfe3xBrNi7aTnEwHPUlaWb63lq uNwAn0OWhKUEgmxVxL72830+dY2X0qNS =X2Yr -----END PGP SIGNATURE----- --Apple-Mail-4-586662477-- From Internet-Drafts@ietf.org Fri Feb 4 01:30: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 62AB33A6B12; Fri, 4 Feb 2011 01:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GwDFoGmAJJGL; Fri, 4 Feb 2011 01:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76AF3A689B; Fri, 4 Feb 2011 01:30: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.12 Message-ID: <20110204093001.17727.51617.idtracker@localhost> Date: Fri, 04 Feb 2011 01:30:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-04.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, 04 Feb 2011 09:30:03 -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 : Reducing the TIME-WAIT state using TCP timestamps Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-timestamps-04.txt Pages : 11 Date : 2011-02-04 This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-timestamps-04.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-timestamps-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-04012746.I-D@ietf.org> --NextPart-- From wes@mti-systems.com Mon Feb 7 07: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 216993A6E05 for ; Mon, 7 Feb 2011 07:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 qdomaAcG6bfr for ; Mon, 7 Feb 2011 07:45:57 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by core3.amsl.com (Postfix) with ESMTP id 03DED3A6E02 for ; Mon, 7 Feb 2011 07:45:56 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p17Fjxn2017935 for ; Mon, 7 Feb 2011 10:45:59 -0500 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [184.217.235.228] ([184.217.235.228:41813] helo=[192.168.9.2]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D5/30-06715-4B3105D4; Mon, 07 Feb 2011 10:45:58 -0500 Message-ID: <4D5013B1.3090405@mti-systems.com> Date: Mon, 07 Feb 2011 10:45:53 -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 Lightning/1.0b2 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 of 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, 07 Feb 2011 15:45:58 -0000 Please consider this email the beginning of a TCPM working group last call on the RFC2988bis document: http://tools.ietf.org/html/draft-paxson-tcpm-rfc2988bis-01 (note that this is an accepted TCPM working group document, though the filename does not indicate it) Any comments should be addressed to the authors and TCPM mailing list. The working group last call should complete on 2/21, so please provide comments by then. -- Wes Eddy MTI Systems From iesg-secretary@ietf.org Mon Feb 7 11:10: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 0F8013A6EA8; Mon, 7 Feb 2011 11:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 ULUb+AkTt-Xd; Mon, 7 Feb 2011 11:10:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7113A6EA5; Mon, 7 Feb 2011 11:10:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207191022.15944.4156.idtracker@localhost> Date: Mon, 07 Feb 2011 11:10:22 -0800 Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'Reducing the TIME-WAIT state using TCP timestamps' to BCP (draft-ietf-tcpm-tcp-timestamps-04.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, 07 Feb 2011 19:10:24 -0000 The IESG has approved the following document: - 'Reducing the TIME-WAIT state using TCP timestamps' (draft-ietf-tcpm-tcp-timestamps-04.txt) as a BCP This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-timestamps/ Technical Summary This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. Working Group Summary Nothing exceptional occurred during the working group process for this document. Document Quality Implementations of the technique described in this document have been implemented for some time. The document specifically cites the Linux kernel's TCP implementation, though there are others as well. One reason for completing this document is to bring this practice to the RFC series so that it can be captured for other implementations. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) has reviewed the document for the IESG. From Internet-Drafts@ietf.org Mon Feb 14 09:45: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 8ECD23A6AC1; Mon, 14 Feb 2011 09:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 9cMLWEv6B+n8; Mon, 14 Feb 2011 09:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAE03A6AC5; Mon, 14 Feb 2011 09:45: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.12 Message-ID: <20110214174501.9449.31388.idtracker@localhost> Date: Mon, 14 Feb 2011 09:45:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-persist-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: Mon, 14 Feb 2011 17:45: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 : Clarification of sender behavior in persist condition. Author(s) : M. Bashyam, et al. Filename : draft-ietf-tcpm-persist-02.txt Pages : 11 Date : 2011-02-14 This document clarifies the Zero Window Probes (ZWP) described in [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-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-persist-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-14093208.I-D@ietf.org> --NextPart-- From fernando.gont.netbook.win@gmail.com Tue Feb 15 03:33: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 0577F3A6B74 for ; Tue, 15 Feb 2011 03:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 JRaV3XX1UucQ for ; Tue, 15 Feb 2011 03:33:08 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 304C73A6C8B for ; Tue, 15 Feb 2011 03:33:07 -0800 (PST) Received: by ywk9 with SMTP id 9so25866ywk.31 for ; Tue, 15 Feb 2011 03:33:33 -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=3BQWFZwPebiJ3yrNPEdTjaua1oVL2GDUigO0hWMJ3SM=; b=ea+wcvY1zMnrDw6l9O5T8kZ1dOCwbBI8PVXffj6bhLzrkTsf1ZfLvJLcABsabKykzd m45cSAETD1IruUt3kmeD51oedQ38rsfkXcZ8AwE5szCO0gDah31Gh4pwlhmVMRI4kHDb ehcM3evzQUTFnk49CkpQRrtsD8doLQkOfa0+Y= 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=GgyxW85w9Cc1MZVpml2GD8qk7fb1sB24+OE7JfFp5mJvbF7lQJgiA1KxCuwWuMyh4C Vruau11QPHaLqayO2CSZCl4rmHYhbLJvl/UDNuUK8aIB0vjyOdA2l5HBggKvbnm+TCjI 9QV3K/KqNPc5WDq7qnO78ZmjWSfZOhhFLWk4g= Received: by 10.150.158.12 with SMTP id g12mr1167721ybe.48.1297769612431; Tue, 15 Feb 2011 03:33:32 -0800 (PST) Received: from [192.168.0.124] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id r41sm2254138yba.16.2011.02.15.03.33.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Feb 2011 03:33:29 -0800 (PST) Sender: Fernando Gont Message-ID: <4D59BE24.6030407@gont.com.ar> Date: Mon, 14 Feb 2011 20:43:32 -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: draft-ietf-tcpm-persist@tools.ietf.org References: <20110214174501.9449.31388.idtracker@localhost> In-Reply-To: <20110214174501.9449.31388.idtracker@localhost> 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] I-D Action:draft-ietf-tcpm-persist-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: Tue, 15 Feb 2011 11:33:09 -0000 Folks, While skimming through this I-D I found that: * It lacks a Sec Cons section * References are not properly split into informative and normative * It lacks an "IANA consierations" section Thanks! Fernando On 14/02/2011 02:45 p.m., Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > > Title : Clarification of sender behavior in persist condition. > Author(s) : M. Bashyam, et al. > Filename : draft-ietf-tcpm-persist-02.txt > Pages : 11 > Date : 2011-02-14 > > This document clarifies the Zero Window Probes (ZWP) described in > [RFC1122]. In particular, it clarifies the actions that can be taken > on connections which are experiencing the ZWP condition. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-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. > > > > _______________________________________________ > 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 ananth@cisco.com Tue Feb 15 08:38:30 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 6391D3A6CA1 for ; Tue, 15 Feb 2011 08:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 47Yv7QSAAfHK for ; Tue, 15 Feb 2011 08:38:29 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8A2913A6A8B for ; Tue, 15 Feb 2011 08:38:29 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BAGs7Wk2rR7Ht/2dsb2JhbACXAI5ac6BUm2mFXgSFBYo4gwY X-IronPort-AV: E=Sophos;i="4.60,474,1291593600"; d="scan'208";a="310823054" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2011 16:38:55 +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 p1FGct3L021161; Tue, 15 Feb 2011 16:38:55 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); Tue, 15 Feb 2011 08:38:55 -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: Tue, 15 Feb 2011 08:38:54 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BE2D908@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4D59BE24.6030407@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-persist-02.txt Thread-Index: AcvNBD0O6aeFrkINSNiVYEiGG7vxIQAKeqJA References: <20110214174501.9449.31388.idtracker@localhost> <4D59BE24.6030407@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , X-OriginalArrivalTime: 15 Feb 2011 16:38:55.0270 (UTC) FILETIME=[D5FFEC60:01CBCD2E] Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-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: Tue, 15 Feb 2011 16:38:30 -0000 Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On > Behalf Of Fernando Gont > Sent: Monday, February 14, 2011 3:44 PM > To: draft-ietf-tcpm-persist@tools.ietf.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-02.txt >=20 > Folks, >=20 > While skimming through this I-D I found that: >=20 > * It lacks a Sec Cons section I wasn't sure if a sec con section is mandatory for an "informational draft". If this is the case, we can add it. > * References are not properly split into informative and normative Good catch. Will look into that.=20 > * It lacks an "IANA consierations" section Well, I don't think it is needed esp. if there is nothing needed from IANA, I guess this section can be omitted. But that's my understanding and I am glad to change my opinion. Thanks, -Anantha >=20 > Thanks! >=20 > Fernando >=20 >=20 >=20 >=20 > On 14/02/2011 02:45 p.m., Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the TCP Maintenance and Minor Extensions > Working Group of the IETF. > > > > > > Title : Clarification of sender behavior in persist > condition. > > Author(s) : M. Bashyam, et al. > > Filename : draft-ietf-tcpm-persist-02.txt > > Pages : 11 > > Date : 2011-02-14 > > > > This document clarifies the Zero Window Probes (ZWP) described in > > [RFC1122]. In particular, it clarifies the actions that can be taken > > on connections which are experiencing the ZWP condition. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-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. > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 From lars.eggert@nokia.com Tue Feb 15 10:54: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 387C23A6D37 for ; Tue, 15 Feb 2011 10:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, 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 JH4M-yHvhPsG for ; Tue, 15 Feb 2011 10:54:48 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 179F53A6AB3 for ; Tue, 15 Feb 2011 10:54:48 -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 p1FIt1jx015373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2011 20:55:02 +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-20--486172856; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <0C53DCFB700D144284A584F54711EC580BE2D908@xmb-sjc-21c.amer.cisco.com> Date: Tue, 15 Feb 2011 20:54:50 +0200 Message-Id: References: <20110214174501.9449.31388.idtracker@localhost> <4D59BE24.6030407@gont.com.ar> <0C53DCFB700D144284A584F54711EC580BE2D908@xmb-sjc-21c.amer.cisco.com> To: Anantha Ramaiah (ananth) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 15 Feb 2011 20:54:56 +0200 (EET) X-Nokia-AV: Clean Cc: draft-ietf-tcpm-persist@tools.ietf.org, tcpm@ietf.org, Fernando Gont Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-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: Tue, 15 Feb 2011 18:54:49 -0000 --Apple-Mail-20--486172856 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please see http://www.ietf.org/id-info/checklist.html and = http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-tcp= m-persist-02.txt On 2011-2-15, at 18:38, Anantha Ramaiah (ananth) wrote: > Fernando, >=20 >> -----Original Message----- >> From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On >> Behalf Of Fernando Gont >> Sent: Monday, February 14, 2011 3:44 PM >> To: draft-ietf-tcpm-persist@tools.ietf.org >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-02.txt >>=20 >> Folks, >>=20 >> While skimming through this I-D I found that: >>=20 >> * It lacks a Sec Cons section >=20 > I wasn't sure if a sec con section is mandatory for an "informational > draft". If this is the case, we can add it. >=20 >> * References are not properly split into informative and normative >=20 > Good catch. Will look into that.=20 >=20 >> * It lacks an "IANA consierations" section >=20 > Well, I don't think it is needed esp. if there is nothing needed from > IANA, I guess this section can be omitted. But that's my understanding > and I am glad to change my opinion. >=20 > Thanks, > -Anantha >>=20 >> Thanks! >>=20 >> Fernando >>=20 >>=20 >>=20 >>=20 >> On 14/02/2011 02:45 p.m., Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the TCP Maintenance and Minor > Extensions >> Working Group of the IETF. >>>=20 >>>=20 >>> Title : Clarification of sender behavior in persist >> condition. >>> Author(s) : M. Bashyam, et al. >>> Filename : draft-ietf-tcpm-persist-02.txt >>> Pages : 11 >>> Date : 2011-02-14 >>>=20 >>> This document clarifies the Zero Window Probes (ZWP) described in >>> [RFC1122]. In particular, it clarifies the actions that can be > taken >>> on connections which are experiencing the ZWP condition. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-02.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. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-20--486172856 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNTE4NTQ1MFowIwYJKoZIhvcNAQkE MRYEFGbjcTYkClKwB9kW0qo8KAd7vP/IMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AJa7g4LSvjKEZKnXu/WilN7L7ZiGpuYEKqnrUmsQnjFok+mmN8nTCQaBDfEPy3XHxsLzhhfkXGYC jTVysvcO5SaWHt000yOWC8jiei8yuenUlnLMnoN6/GpHy/pgNSsCSAfdOZ/xreoN7MnvRR+pEEq3 GhwtLFYmbeX3MXXEABATVgh5c2nOr0DlnZNkSZex61A588zUG+kRfEGhTHVPkEchMnWD+/48vntw h5zJfBxBQJuoobEXMi+dznNPEEEcsZHVOUsNnPku4fmOLlzQZlqhVY4sZaneWe8lN9Z/lItJmSYo +ZibD7IEE3BC8uDnOjWMSBeOV0UiQUKJgTV1nQ4AAAAAAAA= --Apple-Mail-20--486172856-- From Internet-Drafts@ietf.org Wed Feb 16 04: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 245983A6E4B; Wed, 16 Feb 2011 04:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 6ZvTuU8AMaLa; Wed, 16 Feb 2011 04:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E3D3A6C8B; Wed, 16 Feb 2011 04: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.12 Message-ID: <20110216121501.9756.17896.idtracker@localhost> Date: Wed, 16 Feb 2011 04:15:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.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: Wed, 16 Feb 2011 12: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 : Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic Status Author(s) : L. Eggert Filename : draft-eggert-tcpm-historicize-01.txt Pages : 4 Date : 2011-02-16 This document recommends that several TCP extensions that have never seen widespread use be moved to Historic status. The affected RFCs are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-tcpm-historicize-01.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-eggert-tcpm-historicize-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16041016.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Feb 16 08:45: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 6FE8D3A6E89; Wed, 16 Feb 2011 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 FkRyC1icX6UV; Wed, 16 Feb 2011 08:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34553A6C79; Wed, 16 Feb 2011 08:45: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.12 Message-ID: <20110216164501.27490.96538.idtracker@localhost> Date: Wed, 16 Feb 2011 08:45:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.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: Wed, 16 Feb 2011 16:45:03 -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 : Clarification of sender behavior in persist condition. Author(s) : M. Bashyam, et al. Filename : draft-ietf-tcpm-persist-03.txt Pages : 14 Date : 2011-02-16 This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-03.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-persist-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16083247.I-D@ietf.org> --NextPart-- From ananth@cisco.com Wed Feb 16 10:31: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 EEACD3A6D15 for ; Wed, 16 Feb 2011 10:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.932 X-Spam-Level: X-Spam-Status: No, score=-11.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 SnnwrA4JgwET for ; Wed, 16 Feb 2011 10:31:00 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 003D13A69AB for ; Wed, 16 Feb 2011 10:30:59 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABALKmW02rRN+K/2dsb2JhbACXI45Ic6EGm1KFXgSFCIpAiEE X-IronPort-AV: E=Sophos;i="4.60,480,1291593600"; d="scan'208";a="264590194" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2011 18:31:28 +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 p1GIVS6w023683; Wed, 16 Feb 2011 18:31:28 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); Wed, 16 Feb 2011 10:31:28 -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: Wed, 16 Feb 2011 10:31:27 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20110216164501.27490.96538.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt Thread-Index: AcvN+UdsceGFORWWRWmiXMyRvO/aMgADWGQA References: <20110216164501.27490.96538.idtracker@localhost> From: "Anantha Ramaiah (ananth)" To: "Ted Faber" , "John Heffner" , "Fernando Gont" X-OriginalArrivalTime: 16 Feb 2011 18:31:28.0646 (UTC) FILETIME=[B9BD1260:01CBCE07] Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.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: Wed, 16 Feb 2011 18:31:01 -0000 Greetings, This new version posted addresses the concerns raised during the last call. It also contains the idnits changes suggested by Fernando and Lars. Special thanks goes to Wes for going through the draft and providing some useful text which primarily aims at addressing the concerns raised during the LC. If folks in the to list can review the new version and check if this version addresses the issues raised by them, and provide feedback to the list, it would be great. Thanks, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, February 16, 2011 8:45 AM > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Subject: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the TCP Maintenance and Minor Extensions > Working Group of the IETF. >=20 >=20 > Title : Clarification of sender behavior in persist > condition. > Author(s) : M. Bashyam, et al. > Filename : draft-ietf-tcpm-persist-03.txt > Pages : 14 > Date : 2011-02-16 >=20 > This document clarifies the Zero Window Probes (ZWP) described in > Requirements for Internet Hosts [RFC1122]. In particular, it clarifies > the actions that can be taken on connections which are experiencing the > ZWP condition. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-03.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. From huitema@microsoft.com Wed Feb 16 22:59: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 9929A3A6D8C; Wed, 16 Feb 2011 22:59:39 -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 Smxl1gOSUYrv; Wed, 16 Feb 2011 22:59:38 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 9C0F13A6DA8; Wed, 16 Feb 2011 22:59:38 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Feb 2011 23:00:08 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.270.2; Wed, 16 Feb 2011 23:00:08 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 16 Feb 2011 23:00:08 -0800 From: Christian Huitema To: "Internet-Drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt Thread-Index: AQHLzdNVMx7/o2Ck7kOjqGI7Hk9lVJQFQ7TA Date: Thu, 17 Feb 2011 07:00:06 +0000 Message-ID: References: <20110216121501.9756.17896.idtracker@localhost> In-Reply-To: <20110216121501.9756.17896.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.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: Thu, 17 Feb 2011 06:59:39 -0000 I note that the list of RFC includes RFC 1263, "TCP Extensions Considered H= armful." The purpose of the draft is to make some extensions historic. Sinc= e RFC 1263 does not define any particular extension, I don't see the point = of including it. RFC 1263 is an informational RFC. It provides advice on pr= otocol design, and that advice appears to be just as informational now as i= t was then. I don't see why we should reclassify it. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Int= ernet-Drafts@ietf.org Sent: Wednesday, February 16, 2011 4:15 AM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Worki= ng Group of the IETF. Title : Moving the Undeployed TCP Extensions RFC1072, RFC1106, R= FC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic= Status Author(s) : L. Eggert Filename : draft-eggert-tcpm-historicize-01.txt Pages : 4 Date : 2011-02-16 This document recommends that several TCP extensions that have never seen w= idespread use be moved to Historic status. The affected RFCs are RFC1072, = RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-tcpm-historicize-01.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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From lars.eggert@nokia.com Thu Feb 17 00:57: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 DA6753A6DB3; Thu, 17 Feb 2011 00:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, 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 h-vclj1UmDH7; Thu, 17 Feb 2011 00:57:02 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 17F423A6CDE; Thu, 17 Feb 2011 00:57:02 -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 p1H8vPAo004444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 10:57:26 +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-50--349221648; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 17 Feb 2011 10:57:21 +0200 Message-Id: <11AE786E-F8C6-408E-9F1A-863BBFD0BC10@nokia.com> References: <20110216121501.9756.17896.idtracker@localhost> To: Christian Huitema X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 17 Feb 2011 10:57:22 +0200 (EET) X-Nokia-AV: Clean Cc: ops-dir@ietf.org, "tcpm@ietf.org Extensions" , "Scott O. Bradner" Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.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: Thu, 17 Feb 2011 08:57:02 -0000 --Apple-Mail-50--349221648 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-2-17, at 9:00, Christian Huitema wrote: > I note that the list of RFC includes RFC 1263, "TCP Extensions = Considered Harmful." The purpose of the draft is to make some extensions = historic. Since RFC 1263 does not define any particular extension, I = don't see the point of including it. RFC 1263 is an informational RFC. = It provides advice on protocol design, and that advice appears to be = just as informational now as it was then. I don't see why we should = reclassify it. it provides advice on *TCP* protocol design going forward, but the = community went the other way. I don't feel strongly about moving it to = Historic or not, but someone suggested it (see below). Scott Bradner brought this up during his ops-dir review as well: > On 2011-2-11, at 4:24, Scott O. Bradner wrote: >> I'm not sure why RFC 1263 "TCP Extensions Considered Harmful" should >> be included in the list since it seems to me that message of the RFC >> is still valid. But if it is to be included it seems like the >> "it is not used" general description does not apply to this RFC and = some >> specific text should be added to say why it should be made historic >=20 > good point. Someone (I can't remember who, might have been Craig = Partridge) suggested to include RFC1263 in this list because it argues = for an architectural approach which the subsequent TCP evolution with = its myriad of options did not follow. (RFC4614 also contains text along = those lines.) >=20 > I'm adding this text to my working copy: >=20 > ("TCP Extensions Considered Harmful") is = somewhat of a special case. Unlike the other RFCs made Historic by this = memo, it does not specify a TCP option that failed to see deployment, = but argued for a way to evolve TCP forward that the community did not = choose to follow. Lars= --Apple-Mail-50--349221648 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNzA4NTcyMlowIwYJKoZIhvcNAQkE MRYEFFgdGgm117MwZ+ql/J0iTLuruXnVMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ADeGaEszaiTKEd09dXTAWT9pDVnbu0qIBT7e76EwRcGCrbuLIZmwwbs7XDfH4T3LwLpVKhWsyOHF kjkpkHzOhG3hYQKerKfnfgGj252oDDoPwg7ciEOXgFb2tPVZu0uUfQGRwXs1g/NiR2pKo8FdcSKa LeVFup4yrxIcABVRYb1wLw9bw7UceHuQ0xN3VoadJZOujJavYNKLyMB67vimHkgFRrCyJm0JjfIi AptNXorKf0gHsDNnrON6UG9U45wFmaPbfH372GB8WJb8rgCFQ8Q0DokJZp686GjRpao1ZqNObiBV dPu8il42ZQ+5TAVgqCGdWdgzB5nZ0JiEWUSYsJwAAAAAAAA= --Apple-Mail-50--349221648-- From huitema@microsoft.com Thu Feb 17 09:35: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 C2F0A3A6CB8; Thu, 17 Feb 2011 09:35:10 -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=[AWL=0.000, 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 cSl3B4TM5uSB; Thu, 17 Feb 2011 09:35:08 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9B7263A6C6A; Thu, 17 Feb 2011 09:35:08 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 17 Feb 2011 09:35:37 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 17 Feb 2011 09:35:37 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 17 Feb 2011 09:35:36 -0800 From: Christian Huitema To: Lars Eggert Thread-Topic: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt Thread-Index: AQHLzdNVMx7/o2Ck7kOjqGI7Hk9lVJQFQ7TAgACoIYCAAApSsA== Date: Thu, 17 Feb 2011 17:35:35 +0000 Message-ID: References: <20110216121501.9756.17896.idtracker@localhost> <11AE786E-F8C6-408E-9F1A-863BBFD0BC10@nokia.com> In-Reply-To: <11AE786E-F8C6-408E-9F1A-863BBFD0BC10@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ops-dir@ietf.org" , "tcpm@ietf.org Extensions" , "Scott O. Bradner" Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.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: Thu, 17 Feb 2011 17:35:11 -0000 I would suggest to leave 1623 alone for now. There may be a rationale to d= owngrade it later -- or maybe not. In any case, that rationale is not that = it defines unused TCP extensions, and thus it does not belong to the same b= atch. -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: Thursday, February 17, 2011 12:57 AM To: Christian Huitema Cc: tcpm@ietf.org Extensions; ops-dir@ietf.org; Scott O. Bradner Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt Hi, On 2011-2-17, at 9:00, Christian Huitema wrote: > I note that the list of RFC includes RFC 1263, "TCP Extensions Considered= Harmful." The purpose of the draft is to make some extensions historic. Si= nce RFC 1263 does not define any particular extension, I don't see the poin= t of including it. RFC 1263 is an informational RFC. It provides advice on = protocol design, and that advice appears to be just as informational now as= it was then. I don't see why we should reclassify it. it provides advice on *TCP* protocol design going forward, but the communit= y went the other way. I don't feel strongly about moving it to Historic or = not, but someone suggested it (see below). Scott Bradner brought this up during his ops-dir review as well: > On 2011-2-11, at 4:24, Scott O. Bradner wrote: >> I'm not sure why RFC 1263 "TCP Extensions Considered Harmful" should >> be included in the list since it seems to me that message of the RFC >> is still valid. But if it is to be included it seems like the >> "it is not used" general description does not apply to this RFC and some >> specific text should be added to say why it should be made historic >=20 > good point. Someone (I can't remember who, might have been Craig Partridg= e) suggested to include RFC1263 in this list because it argues for an archi= tectural approach which the subsequent TCP evolution with its myriad of opt= ions did not follow. (RFC4614 also contains text along those lines.) >=20 > I'm adding this text to my working copy: >=20 > ("TCP Extensions Considered Harmful") is somew= hat of a special case. Unlike the other RFCs made Historic by this memo, it= does not specify a TCP option that failed to see deployment, but argued fo= r a way to evolve TCP forward that the community did not choose to follow. Lars From lars.eggert@nokia.com Thu Feb 17 09:42: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 A21373A6CB8; Thu, 17 Feb 2011 09:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 fqbSuZLoOgsH; Thu, 17 Feb 2011 09:42:39 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 98D8D3A6C6A; Thu, 17 Feb 2011 09:42:39 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1HHh7J7017188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 19:43:08 +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-82--317678865; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 17 Feb 2011 19:43:04 +0200 Message-Id: References: <20110216121501.9756.17896.idtracker@localhost> <11AE786E-F8C6-408E-9F1A-863BBFD0BC10@nokia.com> To: Christian Huitema X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 17 Feb 2011 19:43:05 +0200 (EET) X-Nokia-AV: Clean Cc: "ops-dir@ietf.org" , "tcpm@ietf.org Extensions" , "Scott O. Bradner" Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.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: Thu, 17 Feb 2011 17:42:40 -0000 --Apple-Mail-82--317678865 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ACK. I'll leave it to David as the responsible AD to make a call here. As I = said, I have no issue removing 1263 from this doc if this is the = consensus. Lars On 2011-2-17, at 19:35, Christian Huitema wrote: > I would suggest to leave 1623 alone for now. There may be a rationale = to downgrade it later -- or maybe not. In any case, that rationale is = not that it defines unused TCP extensions, and thus it does not belong = to the same batch. >=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Thursday, February 17, 2011 12:57 AM > To: Christian Huitema > Cc: tcpm@ietf.org Extensions; ops-dir@ietf.org; Scott O. Bradner > Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt >=20 > Hi, >=20 > On 2011-2-17, at 9:00, Christian Huitema wrote: >> I note that the list of RFC includes RFC 1263, "TCP Extensions = Considered Harmful." The purpose of the draft is to make some extensions = historic. Since RFC 1263 does not define any particular extension, I = don't see the point of including it. RFC 1263 is an informational RFC. = It provides advice on protocol design, and that advice appears to be = just as informational now as it was then. I don't see why we should = reclassify it. >=20 > it provides advice on *TCP* protocol design going forward, but the = community went the other way. I don't feel strongly about moving it to = Historic or not, but someone suggested it (see below). >=20 > Scott Bradner brought this up during his ops-dir review as well: >=20 >> On 2011-2-11, at 4:24, Scott O. Bradner wrote: >>> I'm not sure why RFC 1263 "TCP Extensions Considered Harmful" = should >>> be included in the list since it seems to me that message of the RFC >>> is still valid. But if it is to be included it seems like the >>> "it is not used" general description does not apply to this RFC and = some >>> specific text should be added to say why it should be made historic >>=20 >> good point. Someone (I can't remember who, might have been Craig = Partridge) suggested to include RFC1263 in this list because it argues = for an architectural approach which the subsequent TCP evolution with = its myriad of options did not follow. (RFC4614 also contains text along = those lines.) >>=20 >> I'm adding this text to my working copy: >>=20 >> ("TCP Extensions Considered Harmful") is = somewhat of a special case. Unlike the other RFCs made Historic by this = memo, it does not specify a TCP option that failed to see deployment, = but argued for a way to evolve TCP forward that the community did not = choose to follow. >=20 > Lars --Apple-Mail-82--317678865 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNzE3NDMwNVowIwYJKoZIhvcNAQkE MRYEFIXUCRFUaxfHOlV7ynFiKphhZ6tvMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AD7+nz7ELgIytSbLIjuTvfRoAtsTfac2IKovCPbXhfZGHazlpLrutzUxxz12RgROw0pDvTmytpeg 9l1mKoFs05A6ozTW8kcN/Uirv3bV6e5nFrcfmlFaBlOdGiyT+zar0Jk6HLFdHjFGsJAncfVMXAB5 F9jbKjjwKduQuq4T8aq5CbTmUv26NRnHZFrdAr5V6rKN5zSNQm2U7ZGvtioU1arXVf12aDDy6qWz HuGzUlFVEqaS9ZlLihiimW885nw2AlUtJKtaKc+Sl/s3/Aw6a+BlPp//tydVcM5Xh1VQnV7yVmgW FP3JeZaHds7FdjRcwo5kAVdMTGUbfLBGSA/CH28AAAAAAAA= --Apple-Mail-82--317678865-- From bruno.mongazon-cazavet@alcatel-lucent.com Mon Feb 21 08:05: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 DB5163A6FD8 for ; Mon, 21 Feb 2011 08:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=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 eiSKaz6FLkas for ; Mon, 21 Feb 2011 08:05:13 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CDB4D3A6FBF for ; Mon, 21 Feb 2011 08:05:12 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1LG3wc7007961 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 21 Feb 2011 17:05:51 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 21 Feb 2011 17:05:39 +0100 Message-ID: <4D628D53.4050001@alcatel-lucent.com> Date: Mon, 21 Feb 2011 17:05:39 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [tcpm] TCP-Rehash draft 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, 21 Feb 2011 16:05:14 -0000 Dear working group members, I wonder if you have any chance to look at the TCP-Rehash draft: http://tools.ietf.org/html/draft-mongazon-tcpm-tcp-rehash-00 i posted a few months ago. Did you read it and would consider any interest and follow-up in the working group context ? On my side, i have a pretty serious running implementation of the draft in Linux 2.6.27 and Linux 2.6.34. I am ready to discuss and present both the draft and implementation in next IETF meeting. Would you be interested in this ? Thanks for your time and consideration. Bruno Mongazon. From Donald.Smith@qwest.com Mon Feb 21 13:11: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 2CD623A7127 for ; Mon, 21 Feb 2011 13:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 8CbTRDo2SzL9 for ; Mon, 21 Feb 2011 13:11:28 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 34ADF3A6F53 for ; Mon, 21 Feb 2011 13:11:26 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p1LLC2dK015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 15:12:02 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 565471E005B; Mon, 21 Feb 2011 14:11:57 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 339FE1E0058; Mon, 21 Feb 2011 14:11:57 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p1LLBsuC012164; Mon, 21 Feb 2011 15:11:55 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 21 Feb 2011 14:11:55 -0700 From: "Smith, Donald" To: "'Bruno Mongazon-Cazavet'" , "tcpm@ietf.org Extensions" Date: Mon, 21 Feb 2011 14:11:55 -0700 Thread-Topic: [tcpm] TCP-Rehash draft Thread-Index: AcvR4UYM9xbBrfYESMG/a0uXBR5hXAAKgoiQ Message-ID: References: <4D628D53.4050001@alcatel-lucent.com> In-Reply-To: <4D628D53.4050001@alcatel-lucent.com> 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-CFilter-Loop: Reflected Subject: Re: [tcpm] TCP-Rehash draft 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, 21 Feb 2011 21:11:36 -0000 Sharing: Author's permission required. Donald.Smith@qwest.com > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Bruno Mongazon-Cazavet > Sent: Monday, February 21, 2011 9:06 AM > To: tcpm@ietf.org Extensions > Subject: [tcpm] TCP-Rehash draft > > Dear working group members, > > I wonder if you have any chance to look at the TCP-Rehash draft: > http://tools.ietf.org/html/draft-mongazon-tcpm-tcp-rehash-00 > > i posted a few months ago. > > Did you read it and would consider any interest and follow-up in the > working group context ? I did and yes. > On my side, i have a pretty serious running implementation of the draft > in Linux 2.6.27 and Linux 2.6.34. > I am ready to discuss and present both the draft and implementation in > next IETF meeting. > Would you be interested in this ? > > Thanks for your time and consideration. > Bruno Mongazon. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From yoshifumi.nishida@gmail.com Mon Feb 21 21:27: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 6F5FD3A681A for ; Mon, 21 Feb 2011 21:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[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 vBSD4QXvt9XU for ; Mon, 21 Feb 2011 21:27:16 -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 817743A680A for ; Mon, 21 Feb 2011 21:27:15 -0800 (PST) Received: by wyb42 with SMTP id 42so1038740wyb.31 for ; Mon, 21 Feb 2011 21:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3sIO1P3IyycDA+I369JoKup0oyADzHgA0yNNUkNiWPk=; b=UVP4bpxy2TMl+Cao6n36BQ9ktYc5f8PaKwX8dyf25AK1WXXH4Whk8bvJ9OuaX1VPcC ngt/bDKwg5CiS0ZOwx/J77mvY3DOql/ePyAE/h6nM8YBLPjBLQ06lXvTB/CB0slzrcaC EU+RtoTIoBQyydZ9g0KD3zZbJFguZkVdkyQFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=mPVKCeed9q7QnIlK46z/KJt0F3P1HFUArQluAywE5vBvVimTliWtdGrMFUriGih+dQ DnyZ8568RDv5ig4G4yXOovJN7Hm3786En2dRITUHUpg+XuxbaYMhVSmyWBfueeC78yYt euJTNLsA7bwez0/UMozmcP7zixnlknUk4CVKM= MIME-Version: 1.0 Received: by 10.216.150.164 with SMTP id z36mr1927720wej.52.1298352477652; Mon, 21 Feb 2011 21:27:57 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.174.129 with HTTP; Mon, 21 Feb 2011 21:27:57 -0800 (PST) Date: Mon, 21 Feb 2011 21:27:57 -0800 X-Google-Sender-Auth: uChnXuOuGaj7p6Q1unUDaeEBpLg Message-ID: From: Yoshifumi Nishida To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) 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, 22 Feb 2011 05:27:17 -0000 Hello Richard and all. I've been thinking about the issue Richard brought up and I think it's valid and worth for discussion. I personally think this is a minor issue in RFC3517. (also in RFC3517bis) Please allow me to explain this issue once more and please correct me if I misunderstand something. Let's say, we have a pair of SACK TCP sender and receiver and when cwnd=3D5, sender transmits S1, S2, S3 .. S5 packets. Now, if we lost S1, S5, segments here, we will see the following sequence. 1: When S2 S3 S4 arrives at the receiver side, the receiver sends back dupacks with SACK info to the sender. 2: When the sender receives the 3rd dupack, it retransmits S1 and enters loss recovery phase. 3: When S1 arrives at the receiver side, the receiver sends back a cumulative ACK for S4. 4: When the ACK for S4 arrives, the sender process this ACK by the following steps 4.1: It's not greater than RecoveryPoint, so TCP cannot exit loss recovery phase yet. 4.2: Use update() and setpipe() and find it has only 1 outstanding segm= ent. 4.3: Since cwnd - pipe >=3D 1MSS, tcp tries to send one or more segment= s. 4.4: Use NextSeg() to find the packet to be sent Here, I think there is one minor issue in NextSeg(). When TCP checks if S5 can be sent with the rule (1) in NextSeg(), it fails. ( because (1.b) and (1.c) return false.) Rule (2) can be applicable "if there are available unsent data". But, let's think about the case where there's no available unsent data. Now, TCP is going to apply Rule (3) for S5, but again it fails ( because (1.b) returns false. ) Here, TCP cannot send any packets even though there is a chance to send a retransmit packet. To summarize, I think the logic in RFC3517 can stall in some situations even though there are packets can be sent. This might cause the lost of ack clocking and unnecessary timeouts. I think the solution would be simple. Don't apply (1.b) to the Rule (3) in NextSeg(). I mean, change Rule (3) in NextSeg() from If the conditions for rules (1) and (2) fail, but there exists an unSACKed sequence number 'S3' that meets the criteria for detecting loss given in steps (1.a) and (1.b) above (specifically excluding step (1.c)) then one segment of up to SMSS octets starting with S3 MAY be returned. To If the conditions for rules (1) and (2) fail, but there exists an unSACKed sequence number 'S3' that meets the criteria for detecting loss given in steps (1.a) above (specifically excluding step (1.b) and step (1.c)) then one segment of up to SMSS octets starting with S3 MAY be returned. I might need more time to think about this, but I think removing (1.b) from (3) will not be very harmful. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2010/11/15 Scheffenegger, Richard : > > Hi group, > > Following up on the discussion prior to IETF79, I submitted a draft spec = to discuss TCP SACK loss recovery at end-of-stream. > > I believe there was also split concensus if that should be refined furthe= r to get into RFC3517bis (as it is - IMHO - a minor change under very speci= fic circumstances to TCP SACK), or as a standalone document. I have one pre= ference, but refrain from pursuing it actively, as there are more senior me= mbers who know better than me on these details. > > Thanks a lot for your time! > > Richard Scheffenegger > > > > A new version of I-D, draft-scheffenegger-tcpm-sack-loss-recovery-00.txt = has been successfully submitted by Richard Scheffenegger and posted to the = IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-scheffenegger-tcpm-sack-loss-recovery > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 Improving SACK-based loss recovery for TCP > Creation_date: =A0 2010-11-15 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 12 > > Abstract: > This note clarifies the behavior of TCP SACK while doing loss recovery cl= ose to the end-of-stream. =A0This allows TCP SACK to never exhibit worse lo= ss recovery characteristics than TCP NewReno under identical circumstances. > > > > > >> -----Original Message----- >> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] >> Sent: Sonntag, 24. Oktober 2010 08:41 >> To: tcpm@ietf.org >> Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >> >> 2010/10/23 Ethan Blanton : >> >> > S1 ... S7 are sent. =A0S1, S6, and S7 are lost. =A0The sender >> retransmits >> > S1, gets a cumulative ACK for S6, retransmits S6, then gets a >> > cumulative ACK for S7. =A0Should it retransmit S7? =A0Did the original >> > transmission or the retransmission trigger the cum ACK for S7? >> > Consider the case were S6 was not lost in the first place, >> but delayed >> > in the network for ~1RTT. =A0Now consider interaction with >> timestamps, >> > DSACK, etc. where this potentially *can* be disambiguated. >> >> In my feeling, this depends on the pipe size. >> if cwnd - pipe >=3D 1 SMSS, we can send at least 1 packet. >> In this example, S8 will be sent. ( rule (2) in NextSeg() >> will be applied) If S8 can arrive at the receiver >> successfully, the sender can get good estimation for lost >> packets by the ACK for S8. Then, it can retransmit proper packets. >> >> However, as Richard already pointed out, if this is the end >> of transmission, there is no S8. >> In this case, I think retransmitting S7 will not be harmful so much. >> >> If this is not the end of transmission (e.g. application >> stall), I'm not very sure whether we should retransmit a packet. >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From wes@mti-systems.com Tue Feb 22 06:16:11 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 D11E03A68F3 for ; Tue, 22 Feb 2011 06:16:11 -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 0r2W-qp9fHtH for ; Tue, 22 Feb 2011 06:16:11 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id EB5D83A68F0 for ; Tue, 22 Feb 2011 06:16:10 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p1MEGsut004871 for ; Tue, 22 Feb 2011 09:16:55 -0500 Authentication-Results: cm-omr11 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [173.148.107.17] ([173.148.107.17:32455] helo=[192.168.9.2]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 70/CA-02348-355C36D4; Tue, 22 Feb 2011 09:16:54 -0500 Message-ID: <4D63C54E.1080504@mti-systems.com> Date: Tue, 22 Feb 2011 09:16:46 -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 Lightning/1.0b2 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] tcp-security draft reviews and meeting slot 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, 22 Feb 2011 14:16:11 -0000 Hi folks, as we plan for the Prague meeting, one thing we need to gauge interest on is having a meeting slot for discussing detail of the tcp-security draft: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/ There had been meetings on this in Anaheim and Beijing, and Fernando has recently completed a large editing pass. This document deeply needs the WG's attention to vet the recommendations and either express approval or discuss alterations. If people think that we need to arrange a separate room in Prague for this, please let us know. In the past two meetings on this document, the participation has been a bit light, and the level of feedback not very strong yet for confidently advancing this to BCP status. We are also looking for people to review specific sections that align with their interests or expertise, and not necessarily to review the entire document in one blow. The main sections of the document include: TCP header fields Common TCP Options Connection-establishment mechanism Buffer management TCP segment reassembly algorithm TCP congestion control TCP API Blind in-window attacks Information leaking Covert channels TCP port scanning Processing of ICMP error messages by TCP TCP interaction with IP Please let us know if you have plans or interest to review a particular section so that we know the complete document will be covered by reviews. -- Wes Eddy MTI Systems From touch@isi.edu Tue Feb 22 18:25: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 BC6643A67B8 for ; Tue, 22 Feb 2011 18:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.484 X-Spam-Level: X-Spam-Status: No, score=-105.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 zYkdHdK8Ux+r for ; Tue, 22 Feb 2011 18:25:50 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id CE86B3A67B6 for ; Tue, 22 Feb 2011 18:25:50 -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 p1N2PkO6024667 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 22 Feb 2011 18:25:46 -0800 (PST) Message-ID: <4D64702A.9070304@isi.edu> Date: Tue, 22 Feb 2011 18:25: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: Bruno Mongazon-Cazavet References: <4D628D53.4050001@alcatel-lucent.com> In-Reply-To: <4D628D53.4050001@alcatel-lucent.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 Extensions" Subject: Re: [tcpm] TCP-Rehash draft 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: Wed, 23 Feb 2011 02:25:51 -0000 Hi, all, FWIW, there was a discussion of whether this proposal was a subset of the features of multipathTCP on the multipathTCP list back in Nov. Some other points: - rehash is a bad term to use; it implies a security hash, rather than altering the addresses of a TCP connection - the option includes stateful exchanges of options TCP options are stateless w.r.t. the TCP state machine, and must be able to be processed out of order and assume losses (they aren't running inside the TCP data stream); that appears to challenge the design of this mechanism (it seems to be addressed in part, but corner cases aren't considered) - the option seems to be twice as long as necessary it seems like you already have the current or old IP address in the TCP pseudoheader (IP header); why do you need to send both? you clearly need room for flags somewhere, but can accomplish that with 1 byte (or 2 if padded), rather than 4 - the option appears to deal only with the address changing however, the ports are also specific to the endpoints as well; it should not be assumed that a connection can be moved with its ports intact Finally, I don't see how requiring IPsec to use this mechanism makes it simpler than MPTCP (which doesn't require IPsec). There are many other issues which are not addressed, notably how applications assume that successive or concurrent connections to the same IP address go to the same endpoint (e.g., for FTP, or web transactions); similar concerns are raised in the Intarea "address sharing" doc, and should be discussed here. Joe On 2/21/2011 8:05 AM, Bruno Mongazon-Cazavet wrote: > Dear working group members, > > I wonder if you have any chance to look at the TCP-Rehash draft: > http://tools.ietf.org/html/draft-mongazon-tcpm-tcp-rehash-00 > > i posted a few months ago. > > Did you read it and would consider any interest and follow-up in the > working group context ? > On my side, i have a pretty serious running implementation of the draft > in Linux 2.6.27 and Linux 2.6.34. > I am ready to discuss and present both the draft and implementation in > next IETF meeting. > Would you be interested in this ? > > Thanks for your time and consideration. > Bruno Mongazon. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From bruno.mongazon-cazavet@alcatel-lucent.com Wed Feb 23 01:33: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 F06F33A69CA for ; Wed, 23 Feb 2011 01:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.042 X-Spam-Level: X-Spam-Status: No, score=-5.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_FR=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 mNS0RrmlSJLo for ; Wed, 23 Feb 2011 01:33:38 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7E2943A69B8 for ; Wed, 23 Feb 2011 01:33:37 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1N9WjqX005064 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Feb 2011 10:34:20 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 23 Feb 2011 10:34:03 +0100 Message-ID: <4D64D48B.4010308@alcatel-lucent.com> Date: Wed, 23 Feb 2011 10:34:03 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Joe Touch References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> In-Reply-To: <4D64702A.9070304@isi.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP-Rehash draft 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: Wed, 23 Feb 2011 09:33:40 -0000 Le 23/02/2011 03:25, Joe Touch a écrit : > Hi, all, > > FWIW, there was a discussion of whether this proposal was a subset of > the features of multipathTCP on the multipathTCP list back in Nov. Yes i saw this. Having also some knowledge and experience with MPTCP, i would argue that features are somewhat different. TCP-Rehash and MPTCP looks more complementary than competing. > Some other points: > - rehash is a bad term to use; it implies a security hash, rather than > altering the addresses of a TCP connection "rehash" term is used in reference to the "hash" mechanism performed by TCP/IP Linux stack to find a TCP control block giving a 5-Tuple. When choosing this name, no security matter was considered. Just the capability to recompute the hash value of a TCP-cb for a given 5-tuple (old address) with a new 5-tuple (new address). That's why i called it "rehash". I must agree that the term might not be the best but i wanted to avoid terms like "migrate" or alike. > - the option includes stateful exchanges of options > TCP options are stateless w.r.t. the TCP state machine, > and must be able to be processed out of order and > assume losses (they aren't running inside the TCP > data stream); that appears to challenge the design > of this mechanism (it seems to be addressed in part, > but corner cases aren't considered) There are couples of RFC that use TCP options in a stateful way (i.e. RFC1323 with timestamp echo). Basically MPTCP options also work the same. I don't see any restriction in IETF in using TCP options to maintain state information. I agree about "out of order" and "losses" issues and it is true it challenged a bit the design. I came up with the following invariants: (a) the first packet out with the new address must carry the REHASH-ADDR option if the connection is "rehash" capable (b) if REHASH-ADDR has been sent, and some packets are still received with the old address, the receiver did not yet "rehash" and the sender drops old packets and provides again the REHASH-ADDR option until a maximum number of retry is reached. Could you provide some details on the corner cases that are not covered ? > - the option seems to be twice as long as necessary > it seems like you already have the current or old IP > address in the TCP pseudoheader (IP header); why > do you need to send both? I need both because if there is a NAT in between, the IP header source address will differ. Although TCP-Rehash is currently described as not-NAT capable, provision in the TCP option would allow to do this later. > you clearly need room for flags somewhere, but can > accomplish that with 1 byte (or 2 if padded), rather > than 4 Provision for flags is in bytes 0-1. > - the option appears to deal only with the address changing > however, the ports are also specific to the endpoints > as well; it should not be assumed that a connection > can be moved with its ports intact Right, the ports are currently missing in the option and could be added in further revision of the draft. Please consider that this is draft-0 and thus claims it might lack of some features. > Finally, I don't see how requiring IPsec to use this mechanism makes it > simpler than MPTCP (which doesn't require IPsec). Just saying that if your network is insecure and because TCP-Rehash security is low, you can use IPsec. > There are many other issues which are not addressed, notably how > applications assume that successive or concurrent connections to the > same IP address go to the same endpoint (e.g., for FTP, or web > transactions); similar concerns are raised in the Intarea "address > sharing" doc, and should be discussed here. Fine, can you provide pointer to this document, please. Best regards, Bruno. > Joe > > On 2/21/2011 8:05 AM, Bruno Mongazon-Cazavet wrote: >> Dear working group members, >> >> I wonder if you have any chance to look at the TCP-Rehash draft: >> http://tools.ietf.org/html/draft-mongazon-tcpm-tcp-rehash-00 >> >> i posted a few months ago. >> >> Did you read it and would consider any interest and follow-up in the >> working group context ? >> On my side, i have a pretty serious running implementation of the draft >> in Linux 2.6.27 and Linux 2.6.34. >> I am ready to discuss and present both the draft and implementation in >> next IETF meeting. >> Would you be interested in this ? >> >> Thanks for your time and consideration. >> Bruno Mongazon. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Wed Feb 23 01:50: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 DFAC73A69C4 for ; Wed, 23 Feb 2011 01:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 omCcv-Sis03g for ; Wed, 23 Feb 2011 01:50:15 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 0D7173A67A5 for ; Wed, 23 Feb 2011 01:50:15 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1N9oucN013375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2011 11:50:58 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-25-172385693; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D64D48B.4010308@alcatel-lucent.com> Date: Wed, 23 Feb 2011 11:50:49 +0200 Message-Id: References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 23 Feb 2011 11:50:54 +0200 (EET) X-Nokia-AV: Clean Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] TCP-Rehash draft 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: Wed, 23 Feb 2011 09:50:16 -0000 --Apple-Mail-25-172385693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-2-23, at 11:34, Bruno Mongazon-Cazavet wrote: > TCP-Rehash and MPTCP looks more complementary than competing. right. MPTCP is clearly a superset of what your proposal wants to = achieve. However, since the IETF has committed to standardize MPTCP, it = seems kind of superfluous to take on a second, incompatible proposal = with an overlapping but reduced feature set. That said, I wonder if someone interested (you?) could take MPTCP and = strip it down, so that more or less the functionality that you described = for "TCP-Rehash" remained. In other words, produce a document that = describes a "lightweight" implementation of only some of the features of = MPTCP, and in a way that remained compatible with MPTCP (=3D used the = MPTCP options and some of the MPTCP state machine.) TCP-Rehash is an interesting proposal, don't get me wrong. But it simply = came to the IETF too late, with MPTCP being pretty far along the = standardization process and Linux code for it readily available = (https://scm.info.ucl.ac.be/trac/mptcp/). Lars= --Apple-Mail-25-172385693 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyMzA5NTA0OVowIwYJKoZIhvcNAQkE MRYEFPI4sDork1Yfh826ZbsF2Y9SLkTxMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AFZD9k+GZTnJ2YDxEUJykidu85XKcMj8xssYd/f4dpcyYTUkIOSJBCONVecvkJzgerW3UD0wgkrw niaptkpgiMmHdviZDekjzI/lw5fQKoZbtPqfU0Ir+Q+t7XwiPTqfGp2l+5hvKWaapUQwY2JYYIkT h6290RkOHRjZ0/x+zQnHExEvhTcwfvkITvctH3CCeQP2CvFZ6Tit2HuhajuXvrz2vDI6wxBkR7wf ZLiISjd95lqI1usFWdsQbf4Iq7lkQaKkJCf3s1nXaU4uVCUNZIRi/UHB//NsQsRXKsGc1FMVxpbW 4DLaE7copHRrcDgNNRNCrV86AgYwcFuWh6EKLR8AAAAAAAA= --Apple-Mail-25-172385693-- From bruno.mongazon-cazavet@alcatel-lucent.com Wed Feb 23 02:37: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 783C13A69F8 for ; Wed, 23 Feb 2011 02:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_FR=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 6CfRpRB9dqz2 for ; Wed, 23 Feb 2011 02:37:11 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 1EC5D3A69F3 for ; Wed, 23 Feb 2011 02:37:10 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1NAbOY8030397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Feb 2011 11:37:54 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 23 Feb 2011 11:37:47 +0100 Message-ID: <4D64E37A.7060907@alcatel-lucent.com> Date: Wed, 23 Feb 2011 11:37:46 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Lars Eggert References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] TCP-Rehash draft 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: Wed, 23 Feb 2011 10:37:12 -0000 Le 23/02/2011 10:50, Lars Eggert a écrit : > Hi, > > On 2011-2-23, at 11:34, Bruno Mongazon-Cazavet wrote: >> TCP-Rehash and MPTCP looks more complementary than competing. > right. MPTCP is clearly a superset of what your proposal wants to achieve. However, since the IETF has committed to standardize MPTCP, it seems kind of superfluous to take on a second, incompatible proposal with an overlapping but reduced feature set. > > That said, I wonder if someone interested (you?) could take MPTCP and strip it down, so that more or less the functionality that you described for "TCP-Rehash" remained. In other words, produce a document that describes a "lightweight" implementation of only some of the features of MPTCP, and in a way that remained compatible with MPTCP (= used the MPTCP options and some of the MPTCP state machine.) > > TCP-Rehash is an interesting proposal, don't get me wrong. But it simply came to the IETF too late, with MPTCP being pretty far along the standardization process and Linux code for it readily available (https://scm.info.ucl.ac.be/trac/mptcp/). Hi Lars, I understand these concerns and commit to the most constructive approach from IETF standards perspective. Would it be possible to arrange a 15 minutes slot for me at IETF-80 in Prague so i can present the draft, provide a demonstration of the Linux implementation and have a working group agreement on next steps ? You might choose TCPM or MPTCP (or both) working group(s). Please choose what is the most convenient. Regards, Bruno. > Lars From touch@isi.edu Wed Feb 23 11:11: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 B25BC3A6940 for ; Wed, 23 Feb 2011 11:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=-0.890, 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 Y5-79kI9Rt5U for ; Wed, 23 Feb 2011 11:11:44 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0DD2A3A693A for ; Wed, 23 Feb 2011 11:11:44 -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 p1NJCKZq010704 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 23 Feb 2011 11:12:20 -0800 (PST) Message-ID: <4D655C14.2050801@isi.edu> Date: Wed, 23 Feb 2011 11:12:20 -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: Bruno Mongazon-Cazavet References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> In-Reply-To: <4D64D48B.4010308@alcatel-lucent.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 Extensions" Subject: Re: [tcpm] TCP-Rehash draft 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: Wed, 23 Feb 2011 19:11:45 -0000 Some final suggestions; I'm guessing the rest can wait for your presentation... On 2/23/2011 1:34 AM, Bruno Mongazon-Cazavet wrote: ... >> - the option includes stateful exchanges of options >> TCP options are stateless w.r.t. the TCP state machine, >> and must be able to be processed out of order and >> assume losses (they aren't running inside the TCP >> data stream); that appears to challenge the design >> of this mechanism (it seems to be addressed in part, >> but corner cases aren't considered) > > There are couples of RFC that use TCP options in a stateful way (i.e. > RFC1323 with timestamp echo). That's not quite state in the way I was assuming it. It's OK to base your response on what you see (that's immediate context), but there can't be a "state machine" of transitions based on the options, AFAICT - i.e., your response can't/shouldn't depend on previously received options. The only place where such a transition can occur readily is during the SYN exchange. > Basically MPTCP options also work the same. > I don't see any restriction in IETF in using TCP options to maintain > state information. There's no formal restriction, but TCP likes to resend segments as needed, and those segments aren't often recomputed from scratch (including options) when resent. So the options sent must, AFAICT, be stable w.r.t. retransmission, reordering, and loss. It's implicit in that part of the TCP mechanism. > I agree about "out of order" and "losses" issues and it is true it > challenged a bit the design. > I came up with the following invariants: > > (a) the first packet out with the new address must carry the REHASH-ADDR > option if the connection is "rehash" capable > (b) if REHASH-ADDR has been sent, and some packets are still received > with the old address, the receiver did not yet "rehash" and the sender > drops old packets and provides again the REHASH-ADDR option until a > maximum number of retry is reached. That's OK, but the question is what happens when a segment is retransmitted. If you have to check the options for every segment just before it is retransmitted, you have a problem IMO. > Could you provide some details on the corner cases that are not covered ? Loss, retransmission, user requesting a second relocation while one is pending, etc. >> - the option seems to be twice as long as necessary >> it seems like you already have the current or old IP >> address in the TCP pseudoheader (IP header); why >> do you need to send both? > > I need both because if there is a NAT in between, the IP header source > address will differ. > Although TCP-Rehash is currently described as not-NAT capable, provision > in the TCP option would allow to do this later. This is confusing. If you need it for NATs, then you need to show that mechanism now. If that mechanism is pending and you're OK waiting to develop it, then develop this version without that assumption, IMO. >> you clearly need room for flags somewhere, but can >> accomplish that with 1 byte (or 2 if padded), rather >> than 4 > > Provision for flags is in bytes 0-1. For TCP options, byte 0 = KIND, and shouldn't vary (you shouldn't expect to use more than one KIND for a single option), and byte 1 = length. The format should be shown as a sequence of words (see RFC793, e.g.), but here's what you have: KIND (1 byte; default for TCP options) len (1 byte; default for TCP options) - you set this to 16 control (2 bytes) nonce (4 bytes) addr1 (4 bytes) addr2 (4 bytes) FWIW, control is really bytes 2-3, not 0-1. If you want flags in the control bytes, you should reserve flag fields, e.g., declare the first byte as type, and the second as flags. For the Init exchange, you can easily just send the nonce, and in that case the length gives you the type, e.g.: KIND len = 6 nonce (4 bytes) so when len=6 AND this appears in a SYN (IMO, that's the only time/place this ought to be exchanged), then you can record/exchange the nonces and conserve some space. Later messages can just be: KIND len = 10 nonce (4) addr (4) This saves a lot of space, which is needed for options like SACK. Again, no need to send both old and new addrs; the current addr is in the IP header. You need send only the one you're going to, AFAICT. >> - the option appears to deal only with the address changing >> however, the ports are also specific to the endpoints >> as well; it should not be assumed that a connection >> can be moved with its ports intact > > Right, the ports are currently missing in the option and could be added > in further revision of the draft. > Please consider that this is draft-0 and thus claims it might lack of > some features. AOK; again, length can deal with that issue. >> Finally, I don't see how requiring IPsec to use this mechanism makes it >> simpler than MPTCP (which doesn't require IPsec). > > Just saying that if your network is insecure and because TCP-Rehash > security is low, you can use IPsec. The rules you have require IPsec in the general case; only in limited, known-secure environments can you avoid that. If that's your plan, you're making a system that's much lighter than MPTCP, but then relying on a system which is arguably more complex ;-) >> There are many other issues which are not addressed, notably how >> applications assume that successive or concurrent connections to the >> same IP address go to the same endpoint (e.g., for FTP, or web >> transactions); similar concerns are raised in the Intarea "address >> sharing" doc, and should be discussed here. > > Fine, can you provide pointer to this document, please. https://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ There have been discussions about this doc recently on the Intarea mailing list too that are worth checking out. Joe From bruno.mongazon-cazavet@alcatel-lucent.com Fri Feb 25 00:46: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 BB7423A6940 for ; Fri, 25 Feb 2011 00:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_FR=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 S9Cd+AG893PF for ; Fri, 25 Feb 2011 00:46:38 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3DA123A6928 for ; Fri, 25 Feb 2011 00:46:38 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1P8lB6O013244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Feb 2011 09:47:28 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 25 Feb 2011 09:47:20 +0100 Message-ID: <4D676C98.3060705@alcatel-lucent.com> Date: Fri, 25 Feb 2011 09:47:20 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Joe Touch References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> <4D655C14.2050801@isi.edu> In-Reply-To: <4D655C14.2050801@isi.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP-Rehash draft 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, 25 Feb 2011 08:46:39 -0000 Le 23/02/2011 20:12, Joe Touch a écrit : > Some final suggestions; I'm guessing the rest can wait for your > presentation... > > On 2/23/2011 1:34 AM, Bruno Mongazon-Cazavet wrote: > ... >>> - the option includes stateful exchanges of options >>> TCP options are stateless w.r.t. the TCP state machine, >>> and must be able to be processed out of order and >>> assume losses (they aren't running inside the TCP >>> data stream); that appears to challenge the design >>> of this mechanism (it seems to be addressed in part, >>> but corner cases aren't considered) >> There are couples of RFC that use TCP options in a stateful way (i.e. >> RFC1323 with timestamp echo). > That's not quite state in the way I was assuming it. It's OK to base > your response on what you see (that's immediate context), but there > can't be a "state machine" of transitions based on the options, AFAICT - > i.e., your response can't/shouldn't depend on previously received options. [BM] Why can't there be a state machine based on the options ? > The only place where such a transition can occur readily is during the > SYN exchange. > >> Basically MPTCP options also work the same. >> I don't see any restriction in IETF in using TCP options to maintain >> state information. > There's no formal restriction, but TCP likes to resend segments as > needed, and those segments aren't often recomputed from scratch > (including options) when resent. So the options sent must, AFAICT, be > stable w.r.t. retransmission, reordering, and loss. It's implicit in > that part of the TCP mechanism. [BM] I think it is already the case. If you append the TCP options at the very bottom level of the TCP stack, there is no problem. You don't even know whether it is a retransmit. It does not change the TCP regular behavior. You just look in TCP block and check whether you need to add a TCP option or not. >> I agree about "out of order" and "losses" issues and it is true it >> challenged a bit the design. >> I came up with the following invariants: >> >> (a) the first packet out with the new address must carry the REHASH-ADDR >> option if the connection is "rehash" capable >> (b) if REHASH-ADDR has been sent, and some packets are still received >> with the old address, the receiver did not yet "rehash" and the sender >> drops old packets and provides again the REHASH-ADDR option until a >> maximum number of retry is reached. > That's OK, but the question is what happens when a segment is > retransmitted. If you have to check the options for every segment just > before it is retransmitted, you have a problem IMO. [BM] Please see previous remark. Basically: -TCP-Rehash option processing happens at the very low level of TCP stack (in the solely parts where every packet goes out or in) -at that place, i check in the (little) state-machine for TCP-Rehash if there is a TCP-option to add or process In the solely part of TCP in and out, you don't even know if the packet is retransmitted or not. >> Could you provide some details on the corner cases that are not covered ? > Loss, retransmission, user requesting a second relocation while one is > pending, etc. [bm] loss and retransmission is handled. The case of second relocation while one is pending is interesting and honestly i don't yet have a satisfying solution. Imagine that your stack changes addresses faster than the rate of packets. I can write a word for this in the draft. >>> - the option seems to be twice as long as necessary >>> it seems like you already have the current or old IP >>> address in the TCP pseudoheader (IP header); why >>> do you need to send both? >> I need both because if there is a NAT in between, the IP header source >> address will differ. >> Although TCP-Rehash is currently described as not-NAT capable, provision >> in the TCP option would allow to do this later. > This is confusing. If you need it for NATs, then you need to show that > mechanism now. > > If that mechanism is pending and you're OK waiting to develop it, then > develop this version without that assumption, IMO. [BM] Right. NAT-traversal should be in the draft, but a day is only 24h !! >>> you clearly need room for flags somewhere, but can >>> accomplish that with 1 byte (or 2 if padded), rather >>> than 4 >> Provision for flags is in bytes 0-1. > For TCP options, byte 0 = KIND, and shouldn't vary (you shouldn't expect > to use more than one KIND for a single option), and byte 1 = length. > > The format should be shown as a sequence of words (see RFC793, e.g.), > but here's what you have: > > KIND (1 byte; default for TCP options) > len (1 byte; default for TCP options) - you set this to 16 > control (2 bytes) > nonce (4 bytes) > addr1 (4 bytes) > addr2 (4 bytes) > > FWIW, control is really bytes 2-3, not 0-1. > > If you want flags in the control bytes, you should reserve flag fields, > e.g., declare the first byte as type, and the second as flags. > > For the Init exchange, you can easily just send the nonce, and in that > case the length gives you the type, e.g.: > > KIND > len = 6 > nonce (4 bytes) > > so when len=6 AND this appears in a SYN (IMO, that's the only time/place > this ought to be exchanged), then you can record/exchange the nonces and > conserve some space. > > Later messages can just be: > KIND > len = 10 > nonce (4) > addr (4) > > This saves a lot of space, which is needed for options like SACK. > > Again, no need to send both old and new addrs; the current addr is in > the IP header. You need send only the one you're going to, AFAICT. [BM] Thanks Joe, your proposals looks reasonable. >>> - the option appears to deal only with the address changing >>> however, the ports are also specific to the endpoints >>> as well; it should not be assumed that a connection >>> can be moved with its ports intact >> Right, the ports are currently missing in the option and could be added >> in further revision of the draft. >> Please consider that this is draft-0 and thus claims it might lack of >> some features. > AOK; again, length can deal with that issue. [BM] ok got it. >>> Finally, I don't see how requiring IPsec to use this mechanism makes it >>> simpler than MPTCP (which doesn't require IPsec). >> Just saying that if your network is insecure and because TCP-Rehash >> security is low, you can use IPsec. > The rules you have require IPsec in the general case; only in limited, > known-secure environments can you avoid that. If that's your plan, > you're making a system that's much lighter than MPTCP, but then relying > on a system which is arguably more complex ;-) >>> There are many other issues which are not addressed, notably how >>> applications assume that successive or concurrent connections to the >>> same IP address go to the same endpoint (e.g., for FTP, or web >>> transactions); similar concerns are raised in the Intarea "address >>> sharing" doc, and should be discussed here. >> Fine, can you provide pointer to this document, please. > https://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/ [BM] thanks. > There have been discussions about this doc recently on the Intarea > mailing list too that are worth checking out. > > Joe > From bruno.mongazon-cazavet@alcatel-lucent.com Fri Feb 25 00:51:30 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 C63D43A693B for ; Fri, 25 Feb 2011 00:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.947 X-Spam-Level: X-Spam-Status: No, score=-5.947 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_FR=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 wm0ylYlGlG6H for ; Fri, 25 Feb 2011 00:51:28 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id B1F433A681C for ; Fri, 25 Feb 2011 00:51:27 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1P8qI2u027669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Feb 2011 09:52:18 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 25 Feb 2011 09:52:18 +0100 Message-ID: <4D676DC2.5000805@alcatel-lucent.com> Date: Fri, 25 Feb 2011 09:52:18 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0D12CDA7@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D12CDA7@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] TCP-Rehash draft 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, 25 Feb 2011 08:51:30 -0000 Le 24/02/2011 11:21, Scheffenegger, Richard a écrit : > Bruno, > > > >>> - the option includes stateful exchanges of options >>> TCP options are stateless w.r.t. the TCP state machine, >>> and must be able to be processed out of order and >>> assume losses (they aren't running inside the TCP >>> data stream); that appears to challenge the design >>> of this mechanism (it seems to be addressed in part, >>> but corner cases aren't considered) >> There are couples of RFC that use TCP options in a stateful way (i.e. >> RFC1323 with timestamp echo). >> Basically MPTCP options also work the same. > > Last time I checked, MPTCP negotiates all options that require state changes; and RFC1323 was designed specifically to aid stateless tracking of RTT (instead of what appears to have become endemic, keeping state and tracking each individual sent segment, and matching the ACKs to the proper segment, for "timestamp-less", fine-granularity RTT tracking purposes... [BM] This is a good point of MPTCP. > Perhaps using Linux as basis is not the base departure point to argue about IETF compliant behavior (Linux deviates in so many ways from a IETF-adhering stack, that it's hard to delineate all the interactions; this is not intended as a judgmental statement). [BM] I use what i have ! I test specifications through implementation as IETF requires. I could also have done it on FreeBSD, just lack of time. Regards, Bruno. > Best regards, > Richard > > > -----Original Message----- > From: Bruno Mongazon-Cazavet [mailto:bruno.mongazon-cazavet@alcatel-lucent.com] > Sent: Mittwoch, 23. Februar 2011 10:34 > To: Joe Touch > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] TCP-Rehash draft > > > Le 23/02/2011 03:25, Joe Touch a écrit : >> Hi, all, >> >> FWIW, there was a discussion of whether this proposal was a subset of >> the features of multipathTCP on the multipathTCP list back in Nov. > Yes i saw this. > Having also some knowledge and experience with MPTCP, i would argue that > features are somewhat different. > TCP-Rehash and MPTCP looks more complementary than competing. > >> Some other points: >> - rehash is a bad term to use; it implies a security hash, rather than >> altering the addresses of a TCP connection > "rehash" term is used in reference to the "hash" mechanism performed by > TCP/IP Linux stack to find a TCP control block giving a 5-Tuple. > When choosing this name, no security matter was considered. Just the > capability to recompute the hash value of a TCP-cb for a given 5-tuple > (old address) with a new 5-tuple (new address). That's why i called it > "rehash". > > I must agree that the term might not be the best but i wanted to avoid > terms like "migrate" or alike. > >> - the option includes stateful exchanges of options >> TCP options are stateless w.r.t. the TCP state machine, >> and must be able to be processed out of order and >> assume losses (they aren't running inside the TCP >> data stream); that appears to challenge the design >> of this mechanism (it seems to be addressed in part, >> but corner cases aren't considered) > There are couples of RFC that use TCP options in a stateful way (i.e. > RFC1323 with timestamp echo). > Basically MPTCP options also work the same. > I don't see any restriction in IETF in using TCP options to maintain > state information. > > I agree about "out of order" and "losses" issues and it is true it > challenged a bit the design. > I came up with the following invariants: > > (a) the first packet out with the new address must carry the REHASH-ADDR > option if the connection is "rehash" capable > (b) if REHASH-ADDR has been sent, and some packets are still received > with the old address, the receiver did not yet "rehash" and the sender > drops old packets and provides again the REHASH-ADDR option until a > maximum number of retry is reached. > > Could you provide some details on the corner cases that are not covered ? > >> - the option seems to be twice as long as necessary >> it seems like you already have the current or old IP >> address in the TCP pseudoheader (IP header); why >> do you need to send both? > I need both because if there is a NAT in between, the IP header source > address will differ. > Although TCP-Rehash is currently described as not-NAT capable, provision > in the TCP option would allow to do this later. > >> you clearly need room for flags somewhere, but can >> accomplish that with 1 byte (or 2 if padded), rather >> than 4 > Provision for flags is in bytes 0-1. > >> - the option appears to deal only with the address changing >> however, the ports are also specific to the endpoints >> as well; it should not be assumed that a connection >> can be moved with its ports intact > Right, the ports are currently missing in the option and could be added > in further revision of the draft. > Please consider that this is draft-0 and thus claims it might lack of > some features. > >> Finally, I don't see how requiring IPsec to use this mechanism makes it >> simpler than MPTCP (which doesn't require IPsec). > Just saying that if your network is insecure and because TCP-Rehash > security is low, you can use IPsec. > >> There are many other issues which are not addressed, notably how >> applications assume that successive or concurrent connections to the >> same IP address go to the same endpoint (e.g., for FTP, or web >> transactions); similar concerns are raised in the Intarea "address >> sharing" doc, and should be discussed here. > Fine, can you provide pointer to this document, please. > > Best regards, > Bruno. > >> Joe >> >> On 2/21/2011 8:05 AM, Bruno Mongazon-Cazavet wrote: >>> Dear working group members, >>> >>> I wonder if you have any chance to look at the TCP-Rehash draft: >>> http://tools.ietf.org/html/draft-mongazon-tcpm-tcp-rehash-00 >>> >>> i posted a few months ago. >>> >>> Did you read it and would consider any interest and follow-up in the >>> working group context ? >>> On my side, i have a pretty serious running implementation of the draft >>> in Linux 2.6.27 and Linux 2.6.34. >>> I am ready to discuss and present both the draft and implementation in >>> next IETF meeting. >>> Would you be interested in this ? >>> >>> Thanks for your time and consideration. >>> Bruno Mongazon. >>> >>> _______________________________________________ >>> 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 henk@uijterwaal.nl Fri Feb 25 01:55:18 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 855F83A685B for ; Fri, 25 Feb 2011 01:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 EVkJqOJc0rUN for ; Fri, 25 Feb 2011 01:55:17 -0800 (PST) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by core3.amsl.com (Postfix) with ESMTP id 863F93A6857 for ; Fri, 25 Feb 2011 01:55:17 -0800 (PST) Received: from guest133.guestnet.ripe.net (guest133.guestnet.ripe.net [193.0.10.164]) (authenticated bits=0) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id p1P9u7aT004182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 25 Feb 2011 10:56:08 +0100 (CET) (envelope-from henk@uijterwaal.nl) Message-ID: <4D677CB7.4090301@uijterwaal.nl> Date: Fri, 25 Feb 2011 10:56:07 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [tcpm] Fwd: WGLC for draft-ietf-ippm-tcp-throughput-tm-06.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, 25 Feb 2011 09:55:18 -0000 IPPM WG, This is a Working Group Last Call for the draft: TCP Throughput Testing Methodology draft-ietf-ippm-tcp-throughput-tm-12.txt The -07 version of this document has been submitted to IESG last October. Since then, there have been several reviews and a lot of text has been changed. Before proceeding, we think it is good that the WG looks at this document again. The TCPM WG is cc'd as some members of this group have been involved in the reviews. Please review the draft and raise any issues by Monday, March 28, 2011, 8:00 UTC. An URL for the draft is: http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-12.txt (The date is intentional, if there are issues that require face-2-face discussion, we can do this in Prague). Matt & Henk From lars.eggert@nokia.com Fri Feb 25 02:07: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 707FF3A6857 for ; Fri, 25 Feb 2011 02:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 VRj8hez5c2Yn for ; Fri, 25 Feb 2011 02:07:54 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 90F1A3A6864 for ; Fri, 25 Feb 2011 02:07:54 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PA8h1b021421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Feb 2011 12:08:45 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-7-346252350; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D677CB7.4090301@uijterwaal.nl> Date: Fri, 25 Feb 2011 12:08:35 +0200 Message-Id: References: <4D677CB7.4090301@uijterwaal.nl> To: Henk Uijterwaal X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 25 Feb 2011 12:08:41 +0200 (EET) X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: WGLC for draft-ietf-ippm-tcp-throughput-tm-06.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, 25 Feb 2011 10:07:55 -0000 --Apple-Mail-7-346252350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I encourage TCP folks to give this document a close read and comment on = the IPPM list. Thanks, Lars On 2011-2-25, at 11:56, Henk Uijterwaal wrote: >=20 >=20 > IPPM WG, >=20 > This is a Working Group Last Call for the draft: >=20 > TCP Throughput Testing Methodology > draft-ietf-ippm-tcp-throughput-tm-12.txt >=20 > The -07 version of this document has been submitted to IESG last = October. Since > then, there have been several reviews and a lot of text has been = changed. > Before proceeding, we think it is good that the WG looks at this = document again. > The TCPM WG is cc'd as some members of this group have been > involved in the reviews. >=20 > Please review the draft and raise any issues by Monday, March 28, = 2011, 8:00 > UTC. An URL for the draft is: >=20 > http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-12.txt >=20 > (The date is intentional, if there are issues that require face-2-face > discussion, we can do this in Prague). >=20 > Matt & Henk >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-7-346252350 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 AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyNTEwMDgzNlowIwYJKoZIhvcNAQkE MRYEFNzhsQXhriDroNpns+svd05ALDxTMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ABQdJP2xUVAyg5ZEYvvnO3+3W/CilUa8n7tihKmaAy1rsZT8ZQwfFsSsZ62hFNFp7C8oLYOrdGY2 b9zOK/DJYZovqi6VH+bNv8CrkjbNWvJsrXLfFT76g5Vz4Ka+kFsDgb0fYT8JwG1jPbQhr5F4n41/ eNAc/yXErf356mgaM/L74A6fZ+zdKftZ65CA7wPIxHn2XCEtnYtAdyZFo32/lXl+GSAZ59mcR/h2 cWuyZxUWZT0J87T8AOuwyO3Vr1LkW4/8H7OpjT15hGLQrfwFpxSuMSq1RZeGAGBXNuHLTdjXT6dZ w39kg0u+hY0dkhAQuTzd8F2ec2tYh5X1mANjsR8AAAAAAAA= --Apple-Mail-7-346252350-- From touch@isi.edu Fri Feb 25 09:04: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 BCF203A67A5 for ; Fri, 25 Feb 2011 09:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.745 X-Spam-Level: X-Spam-Status: No, score=-105.745 tagged_above=-999 required=5 tests=[AWL=0.854, 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 hZrQ59Fc3O3w for ; Fri, 25 Feb 2011 09:04:31 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id CAD673A6407 for ; Fri, 25 Feb 2011 09:04:31 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p1PH4XUE016801 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 25 Feb 2011 09:04:42 -0800 (PST) Message-ID: <4D67E120.2020507@isi.edu> Date: Fri, 25 Feb 2011 09:04:32 -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: Bruno Mongazon-Cazavet References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> <4D655C14.2050801@isi.edu> <4D676C98.3060705@alcatel-lucent.com> In-Reply-To: <4D676C98.3060705@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP-Rehash draft 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, 25 Feb 2011 17:04:32 -0000 On 2/25/2011 12:47 AM, Bruno Mongazon-Cazavet wrote: > Le 23/02/2011 20:12, Joe Touch a écrit : >> Some final suggestions; I'm guessing the rest can wait for your >> presentation... >> >> On 2/23/2011 1:34 AM, Bruno Mongazon-Cazavet wrote: >> ... >>>> - the option includes stateful exchanges of options >>>> TCP options are stateless w.r.t. the TCP state machine, >>>> and must be able to be processed out of order and >>>> assume losses (they aren't running inside the TCP >>>> data stream); that appears to challenge the design >>>> of this mechanism (it seems to be addressed in part, >>>> but corner cases aren't considered) >>> There are couples of RFC that use TCP options in a stateful way (i.e. >>> RFC1323 with timestamp echo). >> That's not quite state in the way I was assuming it. It's OK to base >> your response on what you see (that's immediate context), but there >> can't be a "state machine" of transitions based on the options, AFAICT - >> i.e., your response can't/shouldn't depend on previously received >> options. > > [BM] Why can't there be a state machine based on the options ? A few reasons: 1) options come out of order and unreliably 2) there is no notion of how options would change if a segment is retransmitted i.e., #2 means that NOTHING in the packet can be used as context for the option (e.g., sequence number, etc.), and changing the options for different retransmissions of a given segment is *required* for state-machine based options. >> The only place where such a transition can occur readily is during the >> SYN exchange. >> >>> Basically MPTCP options also work the same. >>> I don't see any restriction in IETF in using TCP options to maintain >>> state information. >> There's no formal restriction, but TCP likes to resend segments as >> needed, and those segments aren't often recomputed from scratch >> (including options) when resent. So the options sent must, AFAICT, be >> stable w.r.t. retransmission, reordering, and loss. It's implicit in >> that part of the TCP mechanism. > > [BM] I think it is already the case. If you append the TCP options at > the very bottom level of the TCP stack, there is no problem. > You don't even know whether it is a retransmit. It does not change the > TCP regular behavior. You just look in TCP block and check whether you > need to add a TCP option or not. See above. The problem is that it's difficult to provide enough context for an option so that it can truly be evaluated independently of the packet in which it occurs, and unless you do so, it won't work with retransmissions. Further, most TCPs don't set options for each retransmission differently - that's a major change, and needs to be specified very clearly as a requirement. >>> I agree about "out of order" and "losses" issues and it is true it >>> challenged a bit the design. >>> I came up with the following invariants: >>> >>> (a) the first packet out with the new address must carry the REHASH-ADDR >>> option if the connection is "rehash" capable >>> (b) if REHASH-ADDR has been sent, and some packets are still received >>> with the old address, the receiver did not yet "rehash" and the sender >>> drops old packets and provides again the REHASH-ADDR option until a >>> maximum number of retry is reached. >> That's OK, but the question is what happens when a segment is >> retransmitted. If you have to check the options for every segment just >> before it is retransmitted, you have a problem IMO. > > [BM] Please see previous remark. Basically: > > -TCP-Rehash option processing happens at the very low level of TCP stack > (in the solely parts where every packet goes out or in) > -at that place, i check in the (little) state-machine for TCP-Rehash if > there is a TCP-option to add or process First, you've described how *you* happen to implement it, not how it is specified. You need to change the spec to *require* that order of processing, and that's quite outside the typical protocol specification (it creeps into implementation). > In the solely part of TCP in and out, you don't even know if the packet > is retransmitted or not. > >>> Could you provide some details on the corner cases that are not >>> covered ? >> Loss, retransmission, user requesting a second relocation while one is >> pending, etc. > > [bm] loss and retransmission is handled. The case of second relocation > while one is pending is interesting and honestly i don't yet have a > satisfying solution. Imagine that your stack changes addresses faster > than the rate of packets. I can write a word for this in the draft. You need to prohibit that in the state machine. Joe From bruno.mongazon-cazavet@alcatel-lucent.com Mon Feb 28 00:39: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 55FA03A6AC2 for ; Mon, 28 Feb 2011 00:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_FR=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 bGhGilFRfNWo for ; Mon, 28 Feb 2011 00:39:24 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 68BF03A6A64 for ; Mon, 28 Feb 2011 00:39:22 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1S8cBBt010187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Feb 2011 09:40:19 +0100 Received: from [172.27.205.168] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Feb 2011 09:39:46 +0100 Message-ID: <4D6B5F4D.8090404@alcatel-lucent.com> Date: Mon, 28 Feb 2011 09:39:41 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Joe Touch References: <4D628D53.4050001@alcatel-lucent.com> <4D64702A.9070304@isi.edu> <4D64D48B.4010308@alcatel-lucent.com> <4D655C14.2050801@isi.edu> <4D676C98.3060705@alcatel-lucent.com> <4D67E120.2020507@isi.edu> In-Reply-To: <4D67E120.2020507@isi.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP-Rehash draft 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, 28 Feb 2011 08:39:25 -0000 Le 25/02/2011 18:04, Joe Touch a écrit : > > On 2/25/2011 12:47 AM, Bruno Mongazon-Cazavet wrote: >> Le 23/02/2011 20:12, Joe Touch a écrit : >>> Some final suggestions; I'm guessing the rest can wait for your >>> presentation... >>> >>> On 2/23/2011 1:34 AM, Bruno Mongazon-Cazavet wrote: >>> ... >>>>> - the option includes stateful exchanges of options >>>>> TCP options are stateless w.r.t. the TCP state machine, >>>>> and must be able to be processed out of order and >>>>> assume losses (they aren't running inside the TCP >>>>> data stream); that appears to challenge the design >>>>> of this mechanism (it seems to be addressed in part, >>>>> but corner cases aren't considered) >>>> There are couples of RFC that use TCP options in a stateful way (i.e. >>>> RFC1323 with timestamp echo). >>> That's not quite state in the way I was assuming it. It's OK to base >>> your response on what you see (that's immediate context), but there >>> can't be a "state machine" of transitions based on the options, AFAICT - >>> i.e., your response can't/shouldn't depend on previously received >>> options. >> [BM] Why can't there be a state machine based on the options ? > A few reasons: > > 1) options come out of order and unreliably > > 2) there is no notion of how options would change if a segment is > retransmitted > > i.e., #2 means that NOTHING in the packet can be used as context for the > option (e.g., sequence number, etc.), and changing the options for > different retransmissions of a given segment is *required* for > state-machine based options. [BM] The only requirement for TCP Options is expressed in page 4 of the draft: Whenever TCP packets carrying a TCP Rehash option needs retransmission, the TCP Rehash option shall go again together with the retransmitted packet without breaking the TCP ordering logic. So there is nothing related to the packet content in that sentence, and this is the general case for TCP-Rehash. >>> The only place where such a transition can occur readily is during the >>> SYN exchange. >>> >>>> Basically MPTCP options also work the same. >>>> I don't see any restriction in IETF in using TCP options to maintain >>>> state information. >>> There's no formal restriction, but TCP likes to resend segments as >>> needed, and those segments aren't often recomputed from scratch >>> (including options) when resent. So the options sent must, AFAICT, be >>> stable w.r.t. retransmission, reordering, and loss. It's implicit in >>> that part of the TCP mechanism. >> [BM] I think it is already the case. If you append the TCP options at >> the very bottom level of the TCP stack, there is no problem. >> You don't even know whether it is a retransmit. It does not change the >> TCP regular behavior. You just look in TCP block and check whether you >> need to add a TCP option or not. > See above. The problem is that it's difficult to provide enough context > for an option so that it can truly be evaluated independently of the > packet in which it occurs, and unless you do so, it won't work with > retransmissions. [BM] I am trying to do so, being independent of the packet content. I don't think the draft says so. The only thing that is considered is the SYN bit during initial 3way handshake. Apart from that, the packet content is never considered when adding a TCP-Rehash option. > Further, most TCPs don't set options for each > retransmission differently - that's a major change, and needs to be > specified very clearly as a requirement. [BM] the option is not set differently, that's the point, it is just eventually added. >>>> I agree about "out of order" and "losses" issues and it is true it >>>> challenged a bit the design. >>>> I came up with the following invariants: >>>> >>>> (a) the first packet out with the new address must carry the REHASH-ADDR >>>> option if the connection is "rehash" capable >>>> (b) if REHASH-ADDR has been sent, and some packets are still received >>>> with the old address, the receiver did not yet "rehash" and the sender >>>> drops old packets and provides again the REHASH-ADDR option until a >>>> maximum number of retry is reached. >>> That's OK, but the question is what happens when a segment is >>> retransmitted. If you have to check the options for every segment just >>> before it is retransmitted, you have a problem IMO. >> [BM] Please see previous remark. Basically: >> >> -TCP-Rehash option processing happens at the very low level of TCP stack >> (in the solely parts where every packet goes out or in) >> -at that place, i check in the (little) state-machine for TCP-Rehash if >> there is a TCP-option to add or process > First, you've described how *you* happen to implement it, not how it is > specified. You need to change the spec to *require* that order of > processing, and that's quite outside the typical protocol specification > (it creeps into implementation). [BM] Page 6 the draft says: Prior to issue the REHASH-ADDR option, the initiator of connection movement must perform locally the connection rehash and ensure that the REHASH-ADDR option is mandatory carried in the first outgoing packet flowing from the new IP address. You might consider this is an implementation constraint, but this is the basic principle of the rehash. If you can't add the rehash option on the first outgoing packet carrying the new address, you can't do rehash. I think it is not implementation but functional. This is how it is drawn in the draft. To me it is part of protocol specification. >> In the solely part of TCP in and out, you don't even know if the packet >> is retransmitted or not. >> >>>> Could you provide some details on the corner cases that are not >>>> covered ? >>> Loss, retransmission, user requesting a second relocation while one is >>> pending, etc. >> [bm] loss and retransmission is handled. The case of second relocation >> while one is pending is interesting and honestly i don't yet have a >> satisfying solution. Imagine that your stack changes addresses faster >> than the rate of packets. I can write a word for this in the draft. > You need to prohibit that in the state machine. [BM] Right i can add it to "Usage restriction" section 4. Regards, Bruno. > Joe >