From tcpm-bounces@ietf.org Mon Dec 1 02:45:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2113A6A6C; Mon, 1 Dec 2008 02:45:04 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B135D3A6944; Mon, 1 Dec 2008 02:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081201104501.B135D3A6944@core3.amsl.com> Date: Mon, 1 Dec 2008 02:45:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-10.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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --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 : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-10.txt Pages : 17 Date : 2008-12-01 The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-10.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-uto-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-01024400.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Dec 1 05:38:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F723A6891; Mon, 1 Dec 2008 05:38:17 -0800 (PST) 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 4C25F3A689F for ; Mon, 1 Dec 2008 05:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR3btavUUBVS for ; Mon, 1 Dec 2008 05:38:15 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id C9F743A6847 for ; Mon, 1 Dec 2008 05:38:13 -0800 (PST) Received: from Gorry-Fairhursts-Laptop.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id mB1DXpOJ026457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2008 13:33:53 GMT Message-ID: <4933E7BF.2090200@erg.abdn.ac.uk> Date: Mon, 01 Dec 2008 13:33:51 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Fernando Gont References: <492D2726.3060505@erg.abdn.ac.uk> <200811270525.mAR5PWGK018547@venus.xmundo.net> In-Reply-To: <200811270525.mAR5PWGK018547@venus.xmundo.net> X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Maybe I was not clear: At a first read, this I-D seems to ask an IETF WG to publish an informational document that says actual implementations do not observe one Standards-track RFC (RFC1122, saying TCP provides its own mechanisms), and has currently has an unknown relationship with a second Standards-track RFC (RFC4821). The second was my main comment - we need to know more (see text below) about the level of conformance/deviation - so you suggestion of more text here would be most welcome. Other comments in line. Fernando Gont wrote: > Hello, Gorry, > > Thanks so much for your thorough and timely review. You'll find my > comments in-line.... > > >> * It was interesting to read the issues presented in the I-D. The I-D >> is mainly documentation of algorithms and current practice. If >> published, this seems like an informational document - I can not >> determine whether this is needed, and whether the material could >> already be covered by other documentation. > > It is not covered by other documentation. > OK. That's useful to know. > For instance, this > Internet-Draft is the document that has been referenced in a number of > vulnerability advisories published on these issues (e.g. by CERT/CC and > UK NISCC), and has also been referenced by a number of vulnerability > advisories published by vendors when they addressed these issues. > Understood. > >> * One section of the document (6) describes issues with Source-Quench, >> however this is not a credible issue - it has long been known that >> Source-Quench is not of value. I think this section could safely be >> omitted, reduced or combined with earlier sections to provide more >> rationale for the main part of the I-D. > > I'm not sure what you mean. It may have been known that SQ was not of > value... yet all implementations were responding to SQ as specified by > the IETF. And it was in response to this I-D that many implementations > removed support for SQ (e.g., I did the corresponding patch for OpenBSD). > [Section 6] The generation of SQ by actual routers is already deprecated. So, the new thing in this draft is that it observes that some implementations do not use SQ for TCP, since they have other ways to detect and react to congestion. That seems logical, if the IETF is publishing this document, we should make this change clear for other implementors to follow. My take is: * It can be acceptable to ignore SQ, because CC provides an equivalent function. * If hosts were to act upon SQ (in some future method) they should validate the response. - Put this way, it sounds a lot like the PMTUD/PLPMTUD argument. > >> * The main part of the document is about PMTUD vulnerabilities to ICMP >> attacks and some deployed countermeasures. In my opinion, this >> discussion should be set against the framework defined by the IETF >> standards-track "Packetization Layer Path MTU Discovery", RFC 4821, >> March 2007. This is not currently mentioned, which I find very >> confusing. I'd suggest that if the document is to be published as a >> useful output of the transport area it must compare the non-ICMP >> methods to those in RFC 4821. > > I believe that RFC 4821 does not necessarily obsolete traditional PMTUD. > Correct, as far as I know. RFC4821 is a separate STD-track document, applicable to TCP. > They may be orthogonal. That is, as stated in RFC 4821, you could > implement PLPMTUD just for black-hole detection. I agree that additional > discussion of PLPMTUD might be included, though. > The methods could be seen to parallel the concepts of RFC4821. Do you think they seek to do similar things? Can the methods be related to specific sections of RFC4821? If this is to be published as an IETF document, I'd like to see if this could be seen as a partial or full implementation, and if so does it deviate from the specification? >> * Appendix A concludes with an interpretation of the meaning of >> several RFCs. If this is the result of an IETF WG consensus call, this >> needs to be made clear and more effort needs to be made to determine >> the correct advice. If this is the editor's own view, then it should >> be omitted from a working group draft. > > This text was included in the document even before it was accepted as a > wg document. > So that just makes me wonder if the WG has agreed or not to this list. > (BTW, I do not recall when or why I moved that text out of > the main body of the doc to an appendix). I don't seem to recall people > arguing again this particular text. However, I'm open to remove this > text if the wg feels this is a show-stopper. > Either way, as long as the WG is happy with this. >> * Finally, I do not see a detailed discussion of ICMP issues in >> general as the title suggests, but more of a focus on PMTUD attacks. A >> change to the title and abstract would help attract the right people >> to read this and better reflect the actual content. > > The document discusses ICMP attacks against TCP. There are basically > three of them: connection.reset (hard errors), throughput reduction > (Source Quench), and the PMTUD ones. It's not that it focuses on the > PMTUD ones, but rather that the full counter-measure for the PMTUD > attack is more complex, so it requires more analysys, test-case > scenarios, etc. That's it. > The SQ topic was discussed earlier. Specifically, PLPMTUD is a recent standards track document though. I think my comment comes from reading the title and abstract. If the document talks about three methods, then this could perhaps be used to update the abstract to say what is described. At the moment, the need for implementors to read this is not called out in the abstract. As a TCP-implementor, I should see something there that tells me this is something I should read. > >> I will separately send some comments on the document itself to the >> list, but have decided to postpone the final stage of the review until >> I hear more about the relationship to PLPMTUD, since this may require >> some reworking of the document. It may be that there has been >> discussion on this topic before, if so please let me know. > > Please let me know if the above answer your questions.... > > Thanks so much for your review! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > Best wishes, Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Dec 1 10:24:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481D53A6B8A; Mon, 1 Dec 2008 10:24:20 -0800 (PST) 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 61DF13A6B8A for ; Mon, 1 Dec 2008 10:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] 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 3LtLBl81HCmK for ; Mon, 1 Dec 2008 10:24:18 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8D3D63A6B13 for ; Mon, 1 Dec 2008 10:24:16 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 241346B6A47; Mon, 1 Dec 2008 15:24:14 -0300 (ART) Received: from notebook.gont.com.ar (201-254-50-77.speedy.com.ar [201.254.50.77] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id mB1INvlv021947; Mon, 1 Dec 2008 16:24:00 -0200 Message-Id: <200812011824.mB1INvlv021947@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Dec 2008 15:15:18 -0300 To: gorry@erg.abdn.ac.uk From: Fernando Gont In-Reply-To: <4933E7BF.2090200@erg.abdn.ac.uk> References: <492D2726.3060505@erg.abdn.ac.uk> <200811270525.mAR5PWGK018547@venus.xmundo.net> <4933E7BF.2090200@erg.abdn.ac.uk> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 01 Dec 2008 15:24:13 -0300 (ART) Cc: tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-icmp-attacks-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 10:33 a.m. 01/12/2008, Gorry Fairhurst wrote: >At a first read, this I-D seems to ask an IETF WG to publish an >informational document that says actual implementations do not >observe one Standards-track RFC (RFC1122, saying TCP provides its >own mechanisms), I'd say they do not observe neither RFC1122 (reaction to hard errors) nor RFC 792 (reaction to SQ). >and has currently has an unknown relationship with a >second Standards-track RFC (RFC4821). The second was my main >comment - we need to know more (see text below) about the level of >conformance/deviation - so you suggestion of more text here would be >most welcome. I will read RFC 4821 in detail, and will come back to you on this one, with some proposed text. >>>* One section of the document (6) describes issues with >>>Source-Quench, however this is not a credible issue - it has long >>>been known that Source-Quench is not of value. I think this >>>section could safely be omitted, reduced or combined with earlier >>>sections to provide more rationale for the main part of the I-D. >>I'm not sure what you mean. It may have been known that SQ was not >>of value... yet all implementations were responding to SQ as >>specified by the IETF. And it was in response to this I-D that many >>implementations removed support for SQ (e.g., I did the >>corresponding patch for OpenBSD). > >[Section 6] > >The generation of SQ by actual routers is already deprecated. > >So, the new thing in this draft is that it observes that some >implementations do not use SQ for TCP, since they have other ways to >detect and react to congestion. That seems logical, if the IETF is >publishing this document, we should make this change clear for other >implementors to follow. At some point, the draft actually recommended hosts to do that. However, the text was rephrased because as the doc was (and still is) aiming at Informational, it shouldn't make any recommendations. (Maybe I could split this particular "recommendation" into a stand-alone std track document that simply deprecates SQ? Given that it would be a std track document, it could actually deprecate SQ. FWIW, we had all agreed on deprecating SQ). >My take is: >* It can be acceptable to ignore SQ, because CC provides an >equivalent function. >* If hosts were to act upon SQ (in some future method) they should >validate the response. Validate the response with the TCP SEQ, you mean? >>They may be orthogonal. That is, as stated in RFC 4821, you could >>implement PLPMTUD just for black-hole detection. I agree that >>additional discussion of PLPMTUD might be included, though. >The methods could be seen to parallel the concepts of RFC4821. > >Do you think they seek to do similar things? > >Can the methods be related to specific sections of RFC4821? IIRC, some things do parallel RFC4821. e.g., RFC 4821 interprets that if a probe segment is lost, it was lost due to the packet being "too big". My I-D interprets that, unless the the corresponding TCP segment was lost, the ICMP error message cannot be considered as "legitimate". RFC 4821 relies on timeouts to discover the Path-MTU. My I-D relies on timeouts to validate ICMP "frag needed" error messages. >If this is to be published as an IETF document, I'd like to see if >this could be seen as a partial or full implementation, and if so does >it deviate from the specification? The PMTUD stuff is simply "stronger" validation of ICMP "frag needed" than that provided by simply checking the TCP SEQ. As a result, it suffers from ICMP black-holes as RFC 1191 does. The PMTUD stuff in the ICMP attacks draft has been incorporated in some stacks (at least NetBSD and OpenBSD), to mitigate the attacks described in the document. >>>* Appendix A concludes with an interpretation of the meaning of >>>several RFCs. If this is the result of an IETF WG consensus call, >>>this needs to be made clear and more effort needs to be made to >>>determine the correct advice. If this is the editor's own view, >>>then it should be omitted from a working group draft. >>This text was included in the document even before it was accepted >>as a wg document. >So that just makes me wonder if the WG has agreed or not to this list. Not sure what to say. I guess that unless somebody yells, it means that they don't feel uncomfortable with what is in the document. >>>* Finally, I do not see a detailed discussion of ICMP issues in >>>general as the title suggests, but more of a focus on PMTUD >>>attacks. A change to the title and abstract would help attract the >>>right people to read this and better reflect the actual content. >>The document discusses ICMP attacks against TCP. There are >>basically three of them: connection.reset (hard errors), throughput >>reduction (Source Quench), and the PMTUD ones. It's not that it >>focuses on the PMTUD ones, but rather that the full counter-measure >>for the PMTUD attack is more complex, so it requires more analysys, >>test-case scenarios, etc. That's it. >The SQ topic was discussed earlier. > >Specifically, PLPMTUD is a recent standards track document though. I'm not sure PLPMTUD really affects this document. This I-D is about the traditional PMTUD mechanism. While a pointer can be included stating "This particular attack can be avoided if PLPMTUD is implemented, as it does not rely on ICMP messages", the stuff in the document still applies to hosts that decide to implement RFC 1191 (instead of PLPMTUD) or that decide to implement PLPMTUD only for black-hole detection. >I >think my comment comes from reading the title and abstract. If the >document talks about three methods, then this could perhaps be used to >update the abstract to say what is described. At the moment, the >need for implementors to read this is not called out in the >abstract. As a TCP-implementor, I should see something there that >tells me this is something I should read. I will come back to you with some alternative Abstract. If there's anything in particular you'd like to see there (other than an explicit comment stating that there are three attack.vectors), or you ahve some proposal for the abstract, please let me know... Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 3 01:08:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E865928C0EB; Wed, 3 Dec 2008 01:08:21 -0800 (PST) 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 481D03A6A9B; Wed, 3 Dec 2008 01:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYQM5lZifl0U; Wed, 3 Dec 2008 01:08:19 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 733963A68B1; Wed, 3 Dec 2008 01:08:18 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mB397km7091267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Dec 2008 11:07:47 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> From: Lars Eggert To: Fernando Gont In-Reply-To: <200812030857.mB38v6ND009886@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 11:07:45 +0200 References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com> <200811121548.mACFmKLY007025@venus.xmundo.net> <9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com> <200812030857.mB38v6ND009886@venus.xmundo.net> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 03 Dec 2008 11:07:47 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8714/Wed Dec 3 06:37:28 2008 on fit.nokia.com X-Virus-Status: Clean Cc: "tcpm@ietf.org" , "david.borman@windriver.com" , "ietf@ietf.org" , "gen-art@ietf.org" , "weddy@grc.nasa.gov" , "Black_David@emc.com" Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Type: multipart/mixed; boundary="===============0260840854==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0260840854== Content-Type: multipart/signed; boundary=Apple-Mail-129-879962857; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-129-879962857 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2008-12-3, at 10:47, Fernando Gont wrote: >>> (FYI, the draft originally aimed at Std. Track, and discussed other >>> alternative approaches for dealing with the problem of long delays >>> between connection establishment attempts. Then we changed the draft >>> category to "Informational", to simply document this behavior. At >>> that point, the discussion of parallel connections and other >>> approaches was dropped). >> >> I don't think just ignoring this problem is acceptable, but a >> reference >> to a discussion of what can be done about it in that RFC or some >> other >> document should suffice. > > I have produced a separate PDF document with such a discussion, and > have provided a pointer to it in the Introduction. Please let me know > if you think this addresses the issue you raised. > > WG: Is this okay with the working group, or is any other approach > preferred rather than the one I hve taken to adderss David's comments? Quick follow-up: I have suggested to Fernando the alternative of including a short section of text on just this issue in the document itself, instead of referencing a PDF that includes a lot of other test (the PDF is basically what used to be appendix A, which was removed based on WG feedback). But that is also not aligned with prior WG consensus, since it would move some text back that we had removed. Basically, David's comment is asking for some text that WG consensus had removed from the document, and we need to come to an agreement on whether we want to revisit this consensus and add some text or point to another document, or if we want to tell David that he's on the rough side of the consensus. Feedback, please? Lars --Apple-Mail-129-879962857 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODEyMDMwOTA3NDZaMCMGCSqGSIb3DQEJBDEWBBQerzul9R/GAG37 m4kdXxZ7MjAQajCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAV7GQBLNKLYljLaemLcAunpntEwmNJq58ooSJbZphKf10K4Z8zpz9 ykbbCO5AxlCBJk2xLL1z/5r5OPfGSl4mw3qCI5MExEy07h5T6rSif/91MzhB5HpNAh4NgaSyA8l2 1xm/Hdb5fM7PIOYOtdfB6lo+sO6TeDghSIRjp94y6gYY/4eQjh96w3SMpKHLofuJXlDrDRwbaLLB 1gpi+wnOHLoacLn0qF7mJqSh5zD6rVggq01u/XZaQHCCtQlNB78REpDRDKMpDzK3midyE40RkWao sK2uc9PzoFMZpqiL7t59plPf3+U2bIJDei+Lv+bCePrRUzKmM1l9PjEj1y3DsAAAAAAAAA== --Apple-Mail-129-879962857-- --===============0260840854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0260840854==-- From tcpm-bounces@ietf.org Wed Dec 3 01:35:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FDE28C0F3; Wed, 3 Dec 2008 01:35:21 -0800 (PST) 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 954413A6B54; Wed, 3 Dec 2008 01:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808] 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 CfD7QpGEVHeo; Wed, 3 Dec 2008 01:35:19 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 76EA63A6B4F; Wed, 3 Dec 2008 01:35:16 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7EB476B6598; Wed, 3 Dec 2008 06:35:12 -0300 (ART) Received: from notebook.gont.com.ar (201-254-56-64.speedy.com.ar [201.254.56.64] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id mB39Z5P5007692; Wed, 3 Dec 2008 07:35:06 -0200 Message-Id: <200812030935.mB39Z5P5007692@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Dec 2008 06:28:59 -0300 To: Lars Eggert From: Fernando Gont In-Reply-To: <754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com> <200811121548.mACFmKLY007025@venus.xmundo.net> <9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com> <200812030857.mB38v6ND009886@venus.xmundo.net> <754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 03 Dec 2008 06:35:12 -0300 (ART) Cc: "tcpm@ietf.org" , "david.borman@windriver.com" , "ietf@ietf.org" , "gen-art@ietf.org" , "weddy@grc.nasa.gov" , "Black_David@emc.com" Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 06:07 a.m. 03/12/2008, Lars Eggert wrote: >>I have produced a separate PDF document with such a discussion, and >>have provided a pointer to it in the Introduction. Please let me know >>if you think this addresses the issue you raised. >> >>WG: Is this okay with the working group, or is any other approach >>preferred rather than the one I hve taken to adderss David's comments? > >Quick follow-up: I have suggested to Fernando the alternative of >including a short section of text on just this issue in the document >itself, instead of referencing a PDF that includes a lot of other test >(the PDF is basically what used to be appendix A, which was removed >based on WG feedback). But that is also not aligned with prior WG >consensus, since it would move some text back that we had removed. > >Basically, David's comment is asking for some text that WG consensus >had removed from the document, and we need to come to an agreement on >whether we want to revisit this consensus and add some text or point >to another document, or if we want to tell David that he's on the >rough side of the consensus. FWIW, my personal take is that adding a reference to that PDF can address David's comments without having to add text back to the I-D. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 3 17:10:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829323A677D; Wed, 3 Dec 2008 17:10:31 -0800 (PST) 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 ABB7A3A689C for ; Wed, 3 Dec 2008 17:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luk+D6oNaTft for ; Wed, 3 Dec 2008 17:10:27 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 8C6273A677D for ; Wed, 3 Dec 2008 17:10:27 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8C66B26008B; Wed, 3 Dec 2008 19:10:20 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id mB41AK7Y029683; Wed, 3 Dec 2008 19:10:20 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 19:10:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 19:09:56 -0600 Message-ID: In-Reply-To: <200812030935.mB39Z5P5007692@venus.xmundo.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt Thread-Index: AclVKncD4d4OFCXvRKuFyZvw5sevuwAgdvOw References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com><200811121548.mACFmKLY007025@venus.xmundo.net><9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com><200812030857.mB38v6ND009886@venus.xmundo.net><754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> <200812030935.mB39Z5P5007692@venus.xmundo.net> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Fernando Gont" , "Lars Eggert" X-OriginalArrivalTime: 04 Dec 2008 01:10:20.0669 (UTC) FILETIME=[13CD3AD0:01C955AD] Cc: weddy@grc.nasa.gov, tcpm@ietf.org, david.borman@windriver.com, Black_David@emc.com Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Fernando Gont >Sent: Wednesday, December 03, 2008 4:29 AM > >>Basically, David's comment is asking for some text that WG consensus >>had removed from the document, and we need to come to an agreement on >>whether we want to revisit this consensus and add some text or point >>to another document, or if we want to tell David that he's on the >>rough side of the consensus. > >FWIW, my personal take is that adding a reference to that PDF can >address David's comments without having to add text back to the I-D. > My personal opinion is that this is going to be published as an RFC, and if all we need is a paragraph extracted from the other document to describe the issue, then we should do that rather than add a citation (dependency). This keeps the RFC self-contained, and removes the issue of people not being able to find the other document 20 years from now, or misunderstanding the context of that document as some kind of approved supplement to the RFC. Just my < $0.02 :). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 10 05:03:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE37F3A6B9F; Wed, 10 Dec 2008 05:03:05 -0800 (PST) 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 610643A6B9F for ; Wed, 10 Dec 2008 05:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 FvleSOjnB3G8 for ; Wed, 10 Dec 2008 05:03:04 -0800 (PST) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 20D343A67A5 for ; Wed, 10 Dec 2008 05:03:03 -0800 (PST) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mBAD2aZr059468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Dec 2008 15:02:37 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 15:02:35 +0200 References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com><200811121548.mACFmKLY007025@venus.xmundo.net><9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com><200812030857.mB38v6ND009886@venus.xmundo.net><754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> <200812030935.mB39Z5P5007692@venus.xmundo.net> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 10 Dec 2008 15:02:39 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8741/Wed Dec 10 09:07:43 2008 on fit.nokia.com X-Virus-Status: Clean Cc: "weddy@grc.nasa.gov" , "tcpm@ietf.org" , "david.borman@windriver.com" , Fernando Gont , "Black_David@emc.com" Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Type: multipart/mixed; boundary="===============0573653628==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0573653628== Content-Type: multipart/signed; boundary=Apple-Mail-9--648630750; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-9--648630750 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I think we need others to speak up, so we can come to consensus on what to do here. Lars On 2008-12-4, at 3:09, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Fernando Gont >> Sent: Wednesday, December 03, 2008 4:29 AM >> >>> Basically, David's comment is asking for some text that WG consensus >>> had removed from the document, and we need to come to an agreement >>> on >>> whether we want to revisit this consensus and add some text or point >>> to another document, or if we want to tell David that he's on the >>> rough side of the consensus. >> >> FWIW, my personal take is that adding a reference to that PDF can >> address David's comments without having to add text back to the I-D. >> > > > My personal opinion is that this is going to be published as an > RFC, and if all we need is a paragraph extracted from the other > document to describe the issue, then we should do that rather > than add a citation (dependency). This keeps the RFC self-contained, > and removes the issue of people not being able to find the > other document 20 years from now, or misunderstanding the context > of that document as some kind of approved supplement to the RFC. > > Just my < $0.02 :). --Apple-Mail-9--648630750 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODEyMTAxMzAyMzZaMCMGCSqGSIb3DQEJBDEWBBQ7b1YgBbZxvAY1 l4PBUXYKBjV2NzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAecsagemRT4/FcgtVdENeA4XmHNmc5O7+jSqoIv5h2PO7+/nKojak 2AXAkMyNHNyA4162bX6ZoLg8x6CrbubrzVsN/Nd4YDGfU6oF4lNVdNGuRm8DhJOi9JpnO4/J1d7b Q+ynhryXdudYwG4PH9jCX/Q5Lcvkv/OPQes7VEARCwB6JNpyqBIT5b72EI18l6fzNIOJ9FuxdLXH CtoxEkV1ErMhl6PAs63rNPrWiVP/Tf3xOipDXEBTz4B0T8CjvxQdTzavq4nAsDe9DP9yjbVgj/XS H1qp13gUrUZ3ezVx48OB1gfikztZnvXtqK4+y0IsEZdlFSrDJ93GgGqxdbytAwAAAAAAAA== --Apple-Mail-9--648630750-- --===============0573653628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0573653628==-- From tcpm-bounces@ietf.org Wed Dec 10 21:01:57 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE713A6C14; Wed, 10 Dec 2008 21:01:57 -0800 (PST) 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 7665B3A6C14 for ; Wed, 10 Dec 2008 21:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 zA7azxqvppEX for ; Wed, 10 Dec 2008 21:01:55 -0800 (PST) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id A72093A6972 for ; Wed, 10 Dec 2008 21:01:54 -0800 (PST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id mBB515RZ015026; Thu, 11 Dec 2008 07:01:06 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id mBB510wX014979; Thu, 11 Dec 2008 07:01:01 +0200 Date: Thu, 11 Dec 2008 07:01:00 +0200 (EET) From: Pekka Savola To: Lars Eggert In-Reply-To: Message-ID: References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com><200811121548.mACFmKLY007025@venus.xmundo.net><9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com><200812030857.mB38v6ND009886@venus.xmundo.net><754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> <200812030935.mB39Z5P5007692@venus.xmundo.net> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on otso.netcore.fi X-Virus-Status: Clean Cc: "tcpm@ietf.org" , "david.borman@windriver.com" , Fernando Gont , "weddy@grc.nasa.gov" , "Black_David@emc.com" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, 10 Dec 2008, Lars Eggert wrote: > I think we need others to speak up, so we can come to consensus on what to do > here. As requested: I think the document is fine just as it is. This has been going on far too long already and I just wish it was done. I could also live with re-adding some material, but because that would result in another 6+ months of arguments with the text etc I don't look forward to that option. I wish someone would write another I-D on implementation and deployment experiences with parallel TCP establishment approaches (maybe someone from Apple could help here). But I don't think this is something that should be tied to the fate of this draft. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 11 23:41:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56CC43A69EC; Thu, 11 Dec 2008 23:41:03 -0800 (PST) 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 AA1EA3A69EC for ; Thu, 11 Dec 2008 23:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.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 Z64mLEPkc28p for ; Thu, 11 Dec 2008 23:41:00 -0800 (PST) Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 584533A68CD for ; Thu, 11 Dec 2008 23:40:59 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3B4586B66F7; Fri, 12 Dec 2008 04:40:52 -0300 (ART) Received: from notebook.gont.com.ar (122-83-231-201.fibertel.com.ar [201.231.83.122]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id mBC7ebf3006649; Fri, 12 Dec 2008 05:40:39 -0200 Message-Id: <200812120740.mBC7ebf3006649@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Dec 2008 04:31:05 -0300 To: Pekka Savola , Lars Eggert From: Fernando Gont In-Reply-To: References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com> <200811121548.mACFmKLY007025@venus.xmundo.net> <9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com> <200812030857.mB38v6ND009886@venus.xmundo.net> <754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> <200812030935.mB39Z5P5007692@venus.xmundo.net> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 12 Dec 2008 04:40:51 -0300 (ART) Cc: "weddy@grc.nasa.gov" , "tcpm@ietf.org" , "david.borman@windriver.com" , "Black_David@emc.com" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:01 a.m. 11/12/2008, Pekka Savola wrote: >On Wed, 10 Dec 2008, Lars Eggert wrote: >>I think we need others to speak up, so we can come to consensus on >>what to do here. > >As requested: I think the document is fine just as it is. This has >been going on far too long already and I just wish it was done. > >I could also live with re-adding some material, but because that >would result in another 6+ months of arguments with the text etc I >don't look forward to that option. FWIW, I fully agree with Pekka. >I wish someone would write another I-D on implementation and >deployment experiences with parallel TCP establishment approaches >(maybe someone from Apple could help here). But I don't think this >is something that should be tied to the fate of this draft. I fully agree with Pekka in this respect, too. FWIW, I volunteer to work a bit more on the "parallel connections" stuff, and getting an I-D published on this (and getting whoever has implementation/deployment experience in this involved). But as Pekka said, I don't think the soft errors draft should be tied to any of this "parallel connections" stuff. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Dec 15 09:39:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F7228C129; Mon, 15 Dec 2008 09:39:18 -0800 (PST) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 27A223A697F; Mon, 15 Dec 2008 09:39:14 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20081215173915.27A223A697F@core3.amsl.com> Date: Mon, 15 Dec 2008 09:39:15 -0800 (PST) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP' to Proposed Standard 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has approved the following document: - 'Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP ' as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-04.txt Technical Summary: This document advances the F-RTO algorithm previously published in RFC 4138 from Experimental to Proposed Standard. The changes from RFC 4138 are described in an appendix, but mainly consist of clarifications. This document only upgrades F-RTO for TCP from Experimental to Standards Track; F-RTO for SCTP remains an Experimental mechanism as described in RFC 4138. (This is the reason why this document updates RFC 4138 instead of obsoleting it.) Working Group Summary The working group saw that there were good experiences with F-RTO trials for TCP, and decided that it was reasonable to move it from Experimental to Proposed Standard. The working group has accepted all of the changes that the authors have made without much controversy. Document Quality The document was reviewed for quality by a fair number of TCPM WG members. Personnel Wesley Eddy (wesley.m.eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) has reviewed this document for the IESG. RFC Editor Note. Please expand the RTO (Retransmission Timeout) and MSS (Maximum Segment Size) acronyms on first occurrence. Section 5: Old: "unnecessarily an inappropriately" NEW: "unnecessarily and inappropriately" _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 17 13:45:52 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40F43A698A; Wed, 17 Dec 2008 13:45:52 -0800 (PST) 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 20D6E3A698A for ; Wed, 17 Dec 2008 13:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock1=0.21] 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 uYX5WBdab5Om for ; Wed, 17 Dec 2008 13:45:50 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 873B23A67D2 for ; Wed, 17 Dec 2008 13:45:50 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B7985A80C8; Wed, 17 Dec 2008 15:45:42 -0600 (CST) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id mBHLjg7R014650; Wed, 17 Dec 2008 15:45:42 -0600 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Dec 2008 15:45:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 15:45:41 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICCRG review of draft-sridharan-tcpm-ctcp-02 Thread-Index: AclgkM6MBhCSwlKJRka+0ekS3P1Vxg== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 17 Dec 2008 21:45:42.0527 (UTC) FILETIME=[CF3DF0F0:01C96090] Cc: Murari Sridharan , iccrg@cs.ucl.ac.uk, "Deepak Bansal \(NETWORKING\)" , Dave Thaler Subject: [tcpm] ICCRG review of draft-sridharan-tcpm-ctcp-02 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Some time ago the IRTF Internet Congestion Control Research Group (ICCRG) was asked for its position on the safety of the Compound TCP behaviors described in draft-sridharan-tcpm-ctcp for Experimental deployment on the Internet. This is part of the process described here: http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt Below is the ICCRG review of the Compound TCP draft for input to TCPM. The ICCRG process itself resulted in a couple of iterations of the draft to clarify portions. By my understanding, TCPM should now be using the review, the updated draft, and TCPM's own discussion and feedback loop to decide the fate of the CTCP document with the understanding that TCPM has a general charter item allowing TCPM WG Experimental specification of ICCRG-reviewed congestion control proposals (according to the ION above). --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- ICCRG Compound TCP Safety Review -------------------------------- In July 2007, the ICCRG began reviewing the Compound TCP congestion control technique described in draft-sridharan-tcpm-ctcp-00 in terms of its safety for widespread experimental deployment on the public Internet. This review was conducted as an input to the IETF TCPM working group, where the draft was being considered for possible Experimental publication. The scope of this review does not include making or endorsing any claims about expected performance gains from using Compound TCP. Based on initial RG comments, an update (01) to the original (00) internet-draft was published. Based on further RG comments, another update (02) was published and contains several further clarifications. After reviewing the draft and a number of other documents with results from testing and simulation, three public evaluations were submitted to the ICCRG by RG participants. Several follow-on messages and comments were submitted by these and other RG participants. Multiple independent implementations have been done of Compound TCP at this point in time. Compound TCP has been experimented with in both simulators, testbeds, and campus/enterprise networks. On the matter of safety for experimental use, the implementers and experimenters seem to agree that the algorithm is safe, though in individual implementations, bugs have been found, unrelated to the algorithm itself. It is possible that clarifications to the specification will help to avoid this. The RG seems to have consensus that the Compound TCP mechanism is safe for experimental deployment on the public Internet. References to RG participants' reviews and papers, presentations, and mailing list messages that contributed to the consensus-forming are provided at the end of this document. Its novelty from the current Standards Track congestion control techniques is that Compound TCP also contains a delay-based component. Compound TCP's design only utilizes the delay-based component when loss is low and the congestion window has already grown large, and in other conditions reversts to the current Standards Track mechanisms. This was noted by some reviewers as one inspiration of confidence. The simulation results and analysis made available were also helpful, but were not found to be overwhelmingly convincing on their own. The implementation experiences, testbed work, and campus deployments weighed most heavily in the RG's mind as evidence of Compound TCP's safety. There was an open discussion item on the use of estimation algorithms for the queueing delay. There was also a question lingering about how the algorithm behaves in wireless environments where latency variations may not be completely due to congestion, and a security-related question as to the possibility to disrupt the delay-based component by altering the material used to take delay samples. These questions seem to apply to any congestion control algorithm that utilizes delay as a source of congestion information. Public reviews from: Wesley Eddy (Nov 1, 2007) http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000358.html Mark Allman (Nov 29, 2007) http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000378.html http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000379.html http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000380.html http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000381.html Doug Leith (Jan 16, 2008) http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-January/000402.html Additionally, several thread comments from: Lachlan Andrew http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000416.html Michael Welzl http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000411.html Dino-Martin Lopez-Pacheco http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000415.html Slides showing design and behavior: http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20TCP.pd f INFOCOM 2006 paper: http://research.microsoft.com/users/dthaler/ctcp-infocom06.pdf Evaluation by Doug Leith, Lachlan Andrew, Tom Quetchenbach, Bob Shorten, and Kfir Lavi, based on independent implementation: http://www.hep.man.ac.uk/PFLDnet2008/paper/Leith_DJ_Experimental%20Final .pdf http://www.welzl.at/iccrg-mar08-slides/iccrg_compound_mar08.ppt.pdf Evaluation by SLAC (Yee-Ting Li): http://www.slac.stanford.edu/pubs/slactns/tn04/slac-tn-06-005.pdf Behavior on under-buffered links: http://www.hep.man.ac.uk/PFLDnet2008/paper/Kun_T%20Final.pdf http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000441.html _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 19 05:20:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75273A69F2; Fri, 19 Dec 2008 05:20:02 -0800 (PST) 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 9E1683A6A15 for ; Fri, 19 Dec 2008 05:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 Xn5e8Id+3L38 for ; Fri, 19 Dec 2008 05:20:00 -0800 (PST) Received: from mail.fit.nokia.com (host-39.nrln.net [212.213.221.39]) by core3.amsl.com (Postfix) with ESMTP id 857063A6911 for ; Fri, 19 Dec 2008 05:20:00 -0800 (PST) Received: from [192.168.255.2] (a88-112-30-134.elisa-laajakaista.fi [88.112.30.134]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mBJDJesd046895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2008 15:19:40 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Fernando Gont In-Reply-To: <200812120740.mBC7ebf3006649@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 19 Dec 2008 15:19:39 +0200 References: <9FA859626025B64FBC2AF149D97C944A3C6EEA@CORPUSMX80A.corp.emc.com> <200811121548.mACFmKLY007025@venus.xmundo.net> <9FA859626025B64FBC2AF149D97C944A010748D4@CORPUSMX80A.corp.emc.com> <200812030857.mB38v6ND009886@venus.xmundo.net> <754037F5-4ADA-4A74-A6A0-99EB3ACB5DFD@nokia.com> <200812030935.mB39Z5P5007692@venus.xmundo.net> <200812120740.mBC7ebf3006649@venus.xmundo.net> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Fri, 19 Dec 2008 15:19:45 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/8786/Fri Dec 19 12:30:31 2008 on fit.nokia.com X-Virus-Status: Clean Cc: "tcpm@ietf.org" , "david.borman@windriver.com" , "weddy@grc.nasa.gov" , "Black_David@emc.com" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.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: , Content-Type: multipart/mixed; boundary="===============1926377456==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1926377456== Content-Type: multipart/signed; boundary=Apple-Mail-19-129992705; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-19-129992705 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, OK, let's move this document forward as-is. Thanks, Lars On 2008-12-12, at 9:31, Fernando Gont wrote: > At 02:01 a.m. 11/12/2008, Pekka Savola wrote: > >> On Wed, 10 Dec 2008, Lars Eggert wrote: >>> I think we need others to speak up, so we can come to consensus on >>> what to do here. >> >> As requested: I think the document is fine just as it is. This has >> been going on far too long already and I just wish it was done. >> >> I could also live with re-adding some material, but because that >> would result in another 6+ months of arguments with the text etc I >> don't look forward to that option. > > FWIW, I fully agree with Pekka. > > > >> I wish someone would write another I-D on implementation and >> deployment experiences with parallel TCP establishment approaches >> (maybe someone from Apple could help here). But I don't think this >> is something that should be tied to the fate of this draft. > > I fully agree with Pekka in this respect, too. > > FWIW, I volunteer to work a bit more on the "parallel connections" > stuff, and getting an I-D published on this (and getting whoever has > implementation/deployment experience in this involved). But as Pekka > said, I don't think the soft errors draft should be tied to any of > this "parallel connections" stuff. > > Thanks, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > --Apple-Mail-19-129992705 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wODEyMTkxMzE5MzlaMCMGCSqGSIb3DQEJBDEWBBT+gqC2mY/exsxK 8J1mn/kGqW3q2zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAdq45B+gJ0UReYOpzDy8oBjSp2D6nWVdfSuqVd3PNxVXjmvj+OukV esvsu/0b+9+iXHE6FHxJozZ/zaDFqYzun8S+yXtS6EGk/b3GyYyU9Zer8ZnmAey/AYDAEtJUIHKH sBBs3idQiPYozQm82BjM20KbpocskyTfl+qIL/a4cUuzWFHdipe+LBNVRR7YrV1Z2+ORj3GrYZR2 cuIPKb0i4Yijo87seMhId7duF6iu+AqvaK53WkAC2ZAGYT0JTRz0mBIHA6H3n9ItMnW0iTrBO4EH 8f7e70zrw1WCr1nt8jodcG3QfZBxHz0DZ/1cGeT2v4mIY/bF1STZulGNGrJNcQAAAAAAAA== --Apple-Mail-19-129992705-- --===============1926377456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1926377456==-- From tcpm-bounces@ietf.org Mon Dec 22 05:53:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F283A6829; Mon, 22 Dec 2008 05:53:45 -0800 (PST) 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 C01C43A6829 for ; Mon, 22 Dec 2008 05:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Okb5kF0mEYFh for ; Mon, 22 Dec 2008 05:53:43 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id C13FF3A6808 for ; Mon, 22 Dec 2008 05:53:43 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KCA005L76L9DBA0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 22 Dec 2008 14:53:33 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.36,263,1228086000"; d="sig'?scan'208,217";a="94551681" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 22 Dec 2008 14:53:33 +0100 Received: from chicago.informatik.RWTH-Aachen.DE (chicago.informatik.RWTH-Aachen.DE [137.226.12.187]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id mBMDrXeK027958; Mon, 22 Dec 2008 14:53:33 +0100 (CET) Message-id: <69BB101E-E2C2-4367-977A-1354C84F66DA@nets.rwth-aachen.de> From: Alexander Zimmermann To: tcpm@ietf.org Date: Mon, 22 Dec 2008 14:53:30 +0100 X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.930.3) Cc: Mark Allman Subject: [tcpm] draft-allman-tcp-early-rexmt-07 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: , Content-Type: multipart/mixed; boundary="===============0911801493==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0911801493== Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-3-391223437 Content-transfer-encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3-391223437 Content-Type: multipart/alternative; boundary=Apple-Mail-2-391223385 --Apple-Mail-2-391223385 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Mark, on page 4 of aforementioned draft you introduce the variable "ownd". According to 2581bis (and also other drafts/RFCs), it seems to me to better use the variable "FightSize". It's not a big deal, however I thing it is a little bit more consistent. Alex // // 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-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-2-391223385 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Mark,

on = page 4 of aforementioned draft you introduce the variable = "ownd". According to 2581bis (and also other drafts/RFCs), it = seems to me to better use the variable "FightSize". It's not a = big deal, however I thing it is a little bit = more consistent. 

Alex

//
// = 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-22220