From tcpm-bounces@ietf.org Thu Jun 07 05:47:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEZw-0008C6-NK; Thu, 07 Jun 2007 05:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEZu-0008A4-Pu for tcpm@ietf.org; Thu, 07 Jun 2007 05:46:50 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwEZs-0002pT-65 for tcpm@ietf.org; Thu, 07 Jun 2007 05:46:50 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 10:46:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Jun 2007 10:46:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 Thread-Index: Aceo6LvGGjjRXsxWTZemDvQ63DYD9w== From: To: X-OriginalArrivalTime: 07 Jun 2007 09:46:47.0221 (UTC) FILETIME=[C3AE5650:01C7A8E8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: rbriscoe@jungle.bt.co.uk Subject: [tcpm] Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1324088048==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1324088048== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A8E8.B76AB999" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A8E8.B76AB999 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have now submitted a new version of our draft for testing TCP receiver's responses to packet re-ordering and loss. We have incorporated all the comments that were received in response to the initial draft. Hopefully this new version will prove more acceptable to the people who had concerns about the initial version. Hopefully it will be uploaded onto the ID shadow directory shortly. In the meantime, HTML and txt versions of the draft can be found here: http://www.jungle.bt.co.uk/people/rbriscoe/ext/pubs.html#tcp-rcv-cheat The main changes that we have made are: Clarified that this is testing whether receivers are compliant with TCP regarding responding to out-of-order segments Highlighted that we don't expect all TCP implementations to incorporate this test Added text on possible interactions with other TCP variants Our overall aim with this draft is to set out a safe method to test receiver compliance with TCP over packet reordering so that if optimistic acknowledgements do materialise as a threat, the IETF already have a safe solution that can be used to counter the threat. We would welcome any comments, especially if people still feel uneasy about the overall aim of the draft and how it sets out to achieve it. We are keen that this document should be adopted as a WG item. If it were to be adopted we would suggest that the filename be altered to reflect the changed emphasis of the draft by altering "-rcv-cheat" to "-rcv-compliance". Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 ------_=_NextPart_001_01C7A8E8.B76AB999 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updated draft-tcpm-moncaster-tcp-rcv-cheat-01

Hi,

We have now submitted a new version of = our draft for testing TCP receiver's responses to packet re-ordering and = loss. We have incorporated all the comments that were received in = response to the initial draft. Hopefully this new version will prove = more acceptable to the people who had concerns about the initial = version.

Hopefully it will be uploaded onto the = ID shadow directory shortly. In the meantime, HTML and txt versions of = the draft can be found here: http://www.jungle.bt.co.uk/people/rbriscoe/ext/pubs.html#t= cp-rcv-cheat

The main changes that we have made = are:

Clarified that this is testing whether = receivers are compliant with TCP regarding responding to out-of-order = segments
Highlighted that we don't expect all = TCP implementations to incorporate this test
Added text on possible interactions = with other TCP variants

Our overall aim with this draft is to = set out a safe method to test receiver compliance with TCP over packet = reordering so that if optimistic acknowledgements do materialise as a = threat, the IETF already have a safe solution that can be used to = counter the threat.

We would welcome any comments, = especially if people still feel uneasy about the overall aim of the = draft and how it sets out to achieve it.

We are keen that this document should = be adopted as a WG item. If it were to be adopted we would suggest that = the filename be altered to reflect the changed emphasis of the draft by = altering "-rcv-cheat" to = "-rcv-compliance".

Toby

____________________________________________________________________= ________
Toby Moncaster, = <toby.moncaster@bt.com> Networks Research Centre, BT = Research
B54/70 Adastral Park, Martlesham = Heath, Ipswich, IP53RE, UK.  +44 1473 648734=20

------_=_NextPart_001_01C7A8E8.B76AB999-- --===============1324088048== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1324088048==-- From tcpm-bounces@ietf.org Fri Jun 08 05:33:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwaq4-0001wb-1S; Fri, 08 Jun 2007 05:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwaq3-0001wN-Hw for tcpm@ietf.org; Fri, 08 Jun 2007 05:32:59 -0400 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwaq1-0006LS-4o for tcpm@ietf.org; Fri, 08 Jun 2007 05:32:59 -0400 Received: (qmail 38211 invoked from network); 8 Jun 2007 08:47:16 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jun 2007 08:47:16 -0000 Message-ID: <46692247.4070903@freebsd.org> Date: Fri, 08 Jun 2007 11:32:55 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: toby.moncaster@bt.com Subject: Re: [tcpm] Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rbriscoe@jungle.bt.co.uk, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org toby.moncaster@bt.com wrote: > Hi, > > We have now submitted a new version of our draft for testing TCP > receiver's responses to packet re-ordering and loss. We have > incorporated all the comments that were received in response to the > initial draft. Hopefully this new version will prove more acceptable to > the people who had concerns about the initial version. > > Hopefully it will be uploaded onto the ID shadow directory shortly. In > the meantime, HTML and txt versions of the draft can be found here: > http://www.jungle.bt.co.uk/people/rbriscoe/ext/pubs.html#tcp-rcv-cheat This server seems to be unreachable from the Internet. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 08 06:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbIi-0007YW-F9; Fri, 08 Jun 2007 06:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbIg-0007YH-CG for tcpm@ietf.org; Fri, 08 Jun 2007 06:02:34 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwbId-0002hH-Tr for tcpm@ietf.org; Fri, 08 Jun 2007 06:02:34 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 11:02:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 Date: Fri, 8 Jun 2007 11:02:34 +0100 Message-ID: In-Reply-To: <46692247.4070903@freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 Thread-Index: Acepr/8uAlHokcgCQwGPB7hPvu5n0gAA6ANw From: To: X-OriginalArrivalTime: 08 Jun 2007 10:02:31.0242 (UTC) FILETIME=[20C642A0:01C7A9B4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rbriscoe@jungle.bt.co.uk, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Apologies for that. The draft is on: Text version: http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/tcp-test/draf t-moncaster-tcpm-rcv-cheat-01.txt HTML version: http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/tcp-test/draf t-moncaster-tcpm-rcv-cheat-01.html And is now on the ID shadow directory=20 ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: Andre Oppermann [mailto:andre@freebsd.org]=20 Sent: 08 June 2007 10:33 To: Moncaster,T,Toby,CXR9 R Cc: tcpm@ietf.org; Briscoe,RJ,Bob,XVR9 BRISCORJ R Subject: Re: [tcpm] Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 toby.moncaster@bt.com wrote: > Hi, >=20 > We have now submitted a new version of our draft for testing TCP=20 > receiver's responses to packet re-ordering and loss. We have=20 > incorporated all the comments that were received in response to the=20 > initial draft. Hopefully this new version will prove more acceptable=20 > to the people who had concerns about the initial version. >=20 > Hopefully it will be uploaded onto the ID shadow directory shortly. In > the meantime, HTML and txt versions of the draft can be found here: > http://www.jungle.bt.co.uk/people/rbriscoe/ext/pubs.html#tcp-rcv-cheat This server seems to be unreachable from the Internet. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 08 07:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd7P-0005j6-7J; Fri, 08 Jun 2007 07:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwd7O-0005iy-M6 for tcpm@ietf.org; Fri, 08 Jun 2007 07:59:02 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwd7M-0008EC-7a for tcpm@ietf.org; Fri, 08 Jun 2007 07:59:02 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 12:58:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 12:59:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 - corrected file locations Thread-Index: Acepr/8uAlHokcgCQwGPB7hPvu5n0gAA6ANwAAQYahA= From: To: X-OriginalArrivalTime: 08 Jun 2007 11:58:59.0552 (UTC) FILETIME=[6621BE00:01C7A9C4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [tcpm] Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 - corrected file locations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 Hi All, I messed up on the file locations in the email (copied below) I sent regarding the new version of our draft. The correct locations are: http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/tcp-test/draf t-moncaster-tcpm-rcv-cheat-01.txt http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/tcp-test/draf t-moncaster-tcpm-rcv-cheat-01.html It has been posted on the ID shadow directory as well now. Toby ---ORIGINAL MESSAGE--- ______________________________________________=20 From: Moncaster,T,Toby,CXR9 R =20 Sent: 07 June 2007 10:47 To: tcpm@ietf.org Cc: Jacquet,A,Arnaud,CXR9 R; Briscoe,RJ,Bob,XVR9 BRISCORJ R Subject: Updated draft-tcpm-moncaster-tcp-rcv-cheat-01 Hi, We have now submitted a new version of our draft for testing TCP receiver's responses to packet re-ordering and loss. We have incorporated all the comments that were received in response to the initial draft. Hopefully this new version will prove more acceptable to the people who had concerns about the initial version. Hopefully it will be uploaded onto the ID shadow directory shortly. In the meantime, HTML and txt versions of the draft can be found here: http://www.jungle.bt.co.uk/people/rbriscoe/ext/pubs.html#tcp-rcv-cheat The main changes that we have made are: Clarified that this is testing whether receivers are compliant with TCP regarding responding to out-of-order segments Highlighted that we don't expect all TCP implementations to incorporate this test Added text on possible interactions with other TCP variants Our overall aim with this draft is to set out a safe method to test receiver compliance with TCP over packet reordering so that if optimistic acknowledgements do materialise as a threat, the IETF already have a safe solution that can be used to counter the threat. We would welcome any comments, especially if people still feel uneasy about the overall aim of the draft and how it sets out to achieve it. We are keen that this document should be adopted as a WG item. If it were to be adopted we would suggest that the filename be altered to reflect the changed emphasis of the draft by altering "-rcv-cheat" to "-rcv-compliance". Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 11 15:51:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpvR-0005Mz-Lr; Mon, 11 Jun 2007 15:51:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxpup-0003sk-QQ; Mon, 11 Jun 2007 15:51:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hxpup-0007sM-FY; Mon, 11 Jun 2007 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 111C62AC96; Mon, 11 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057r-P1; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-uto-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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-06.txt Pages : 16 Date : 2007-6-11 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 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-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11125136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11125136.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Jun 12 03:53:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1Bq-0003BB-1l; Tue, 12 Jun 2007 03:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1Bo-0003B2-AU for tcpm@ietf.org; Tue, 12 Jun 2007 03:53:20 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1Bm-0004Hy-TK for tcpm@ietf.org; Tue, 12 Jun 2007 03:53:20 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C7qs4G011251 for ; Tue, 12 Jun 2007 10:53:17 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 10:53:07 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 10:53:07 +0300 Received: from [172.21.35.94] (esdhcp03594.research.nokia.com [172.21.35.94]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C7r6qp016644 for ; Tue, 12 Jun 2007 10:53:06 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <0C53DCFB700D144284A584F54711EC58036BF0B6@xmb-sjc-21c.amer.cisco.com> References: <0C53DCFB700D144284A584F54711EC58036BF0B6@xmb-sjc-21c.amer.cisco.com> Message-Id: From: Lars Eggert Date: Tue, 12 Jun 2007 10:53:04 +0300 To: tcpm@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 07:53:07.0830 (UTC) FILETIME=[B7129960:01C7ACC6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [tcpm] draft-ietf-tcpm-tcp-uto-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075690425==" Errors-To: tcpm-bounces@ietf.org --===============0075690425== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--683362100; protocol="application/pkcs7-signature" --Apple-Mail-8--683362100 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Fernando has produced a -06 revision of the draft that - as far as we know - addresses all the comments we have received. (Thank you, reviewers!) We have no further changes lined up for this document. It's been a long time, but in our opinion, this is finally ready for WGLC. Lars --Apple-Mail-8--683362100 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ 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 a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTIwNzUzMDRaMCMGCSqGSIb3DQEJBDEWBBR9ZNB3gKvQhXmz fCcpjsx4BE6uHzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAK9ygs0B//Rl2ep0VWd6agEoH0iMD/I/Nyfrt+aveaLVtSRP+Ix89 JnEDnCSzGVHJE1qP7xm1WS+nobVInJmkfH8xdc9Xux5ClYNti5tk/PoGW64tpIMvGg7VeF1km6Rk CqVOYX/RbUZACgG/7fA9yc9bR4AAxPeclZ2ugnfqUn95w7arJVk1cMjKnWCiWXBUsjtm+UNcpOJ8 Hx3mt1xeB58+8yfP/rFwbQUCmrK0QI6p8VLuby/Ce2QqMbz6Nc5iQh37ftGtmoB8U9Q7BYGEtD0O aRWFk8YHxyFDW11+mosGXRxFRb9k8/wHOaJo3t9eI7t61GPBrY0IYnJVaNMxDQAAAAAAAA== --Apple-Mail-8--683362100-- --===============0075690425== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0075690425==-- From tcpm-bounces@ietf.org Tue Jun 12 16:02:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCZo-0008FO-MD; Tue, 12 Jun 2007 16:02:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNs-0007m7-Mn; Tue, 12 Jun 2007 15:50:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCNs-0001if-Cc; Tue, 12 Jun 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 51686175F3; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005kw-2i; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc4138bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , 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 : Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP Author(s) : P. Sarolahti, et al. Filename : draft-ietf-tcpm-rfc4138bis-00.txt Pages : 17 Date : 2007-6-12 Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-rfc4138bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-rfc4138bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-12120454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-rfc4138bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc4138bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12120454.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Jun 13 12:09:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVOr-0002Sj-0H; Wed, 13 Jun 2007 12:08:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVOp-0002Se-Qa for tcpm@ietf.org; Wed, 13 Jun 2007 12:08:47 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyVOo-0003s1-V1 for tcpm@ietf.org; Wed, 13 Jun 2007 12:08:47 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5DG8PhQ016352 for ; Wed, 13 Jun 2007 19:08:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:08:40 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:08:40 +0300 Received: from [172.21.34.186] ([172.21.34.186]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:08:40 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Message-Id: <465B140D-E654-40B7-B7E1-38E69E6B9D85@nokia.com> From: Pasi Sarolahti Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc4138bis-00.txt Date: Wed, 13 Jun 2007 19:07:31 +0300 To: tcpm@ietf.org X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Jun 2007 16:08:40.0606 (UTC) FILETIME=[1B99EBE0:01C7ADD5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1076952673==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1076952673== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-121--567295206" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-121--567295206 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Everyone, In few past IETFs there there have been requests to advance F-RTO from Experimental to Proposed Standard. F-RTO was discussed in Prague in the tcpm meeting and also mentioned in the tsv-area presentation on Windows Vista TCP features, where advancement of F-RTO was supported by the presenters. Therefore, to go forward with this process we have submitted this draft, which is based on RFC 4138 with the following diffs: * Removed description of the SACK-enhanced algorithm * Removed SCTP considerations * Removed earlier Appendix sections, except Appendix C from RFC 4138, which is now Appendix A * Clarified text about the possible response algorithms * Added section that summarizes the evaluation of RFC 4138 Related to the last point, there is a companion draft titled "Evaluation of RFC 4138" available at http://tools.ietf.org/wg/tcpm/ draft-kojo-tcpm-frto-eval-00.txt , that aims to evaluate the benefits and possible problems with F-RTO. This draft also refers to the papers about F-RTO if anyone is interested to have further reading. The reason for removing SACK and SCTP sections is that although the basic F-RTO has been implemented in a number of systems, we feel that there are no sufficient experimental experience with these variants, so they could be left out from the Proposed Standard document. Please give feedback about the above-mentioned changes or anything else related to draft. We are also looking for comments/guidance on how to move forward with the draft. Many thanks, - Pasi PS. I will be on summer holidays starting from this weekend and will not be able myself to read mails very actively, but the co-authors should be available to take part in any follow-up discussion on the list. On Jun 12, 2007, at 22:50, ext tcpm-bounces@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 : Forward RTO-Recovery (F-RTO): An Algorithm for Detecting > Spurious Retransmission Timeouts with TCP > Author(s) : P. Sarolahti, et al. > Filename : draft-ietf-tcpm-rfc4138bis-00.txt > Pages : 17 > Date : 2007-6-12 > > Spurious retransmission timeouts cause suboptimal TCP performance > because they often result in unnecessary retransmission of the > last > > window of data. This document describes the F-RTO detection > algorithm for detecting spurious TCP retransmission timeouts. > F-RTO > is a TCP sender-only algorithm that does not require any TCP > options > to operate. After retransmitting the first unacknowledged segment > triggered by a timeout, the F-RTO algorithm of the TCP sender > monitors the incoming acknowledgments to determine whether the > timeout was spurious. It then decides whether to send new > segments > or retransmit unacknowledged segments. The algorithm effectively > helps to avoid additional unnecessary retransmissions and thereby > improves TCP performance in the case of a spurious timeout. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-tcpm-rfc4138bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tcpm-rfc4138bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-6-12120454.I-D@ietf.org> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --Apple-Mail-121--567295206 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGcBZDoNa7NH1G2csRAnbIAKCHDfhPrWj6s4dh71sTr0pxzHFMBwCg6xqj w71R9Z+brHAEUqSI4effcSc= =Mf1L -----END PGP SIGNATURE----- --Apple-Mail-121--567295206-- --===============1076952673== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1076952673==-- From tcpm-bounces@ietf.org Wed Jun 13 17:12:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hya8l-00071S-6j; Wed, 13 Jun 2007 17:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hya8j-0006yE-V5 for tcpm@ietf.org; Wed, 13 Jun 2007 17:12:29 -0400 Received: from smtpout.mac.com ([17.250.248.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hya8j-0000bD-K1 for tcpm@ietf.org; Wed, 13 Jun 2007 17:12:29 -0400 Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l5DLCNAc020366; Wed, 13 Jun 2007 14:12:23 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5DLBeTw011399; Wed, 13 Jun 2007 14:11:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Date: Wed, 13 Jun 2007 14:11:38 -0700 To: tcpm X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: David Ros , =?ISO-8859-1?Q?Andr=E9s_Arcia?= , Janardhan Iyengar Subject: [tcpm] Adding Acknowledgement Congestion Control to TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I have just submitted a revised internet-draft for "Adding Acknowledgement Congestion Control to TCP", available from "http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-01.txt". The revisions, listed below, are based largely on feedback from Armando Caro and Mark Allman. Further feedback would be welcome. To the TCPM co-chairs: Can we have a slot at the July IETF to talk about this? I would probably be the presenter. The goal is for this to be taken up as a WG item for consideration as an Experimental RFC. - Sally http://www.icir.org/floyd/ Changes from draft-floyd-tcpm-ackcc-00.txt: * Added a discussion of environments where the reverse path is congested, but the TCP ACK traffic does not significantly contribute to that congestion. In this case, the goal is to minimize the negative impack of AckCC on TCP performance. Feedback from Armando Caro. * In Section 5.7, added that when ABC is used with Aggregate Congestion Control, and rate-based pacing is also used, the sender MAY increase cwnd by more than 2 MSS. Feedback from Armando Caro. * Added a section about measurements of ACK traffic and congestion. Feedback from Armando Caro. * Added a section on the possibility of a TCP receiver-imposed lower bound on the ACK Ratio. Suggested by Mark Allman. * Added to the discussion of the mimumum ACK sending rate. Suggested by Mark Allman. * Added a note that if the TCP receiver doesn't sent an ACK for every duplicate data packet, the sender's Fast Recovery procedure will have to be modified to take this into account. Feedback from Mark Allman. * Added a discussion of evaluating ACK Congestion Control. From feedback from Mark Allman. * Some general editing in response to feedback from Mark Allman. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jun 14 17:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywf1-0004W3-19; Thu, 14 Jun 2007 17:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywez-0004VL-71 for tcpm@ietf.org; Thu, 14 Jun 2007 17:15:17 -0400 Received: from smtpout.mac.com ([17.250.248.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hywcd-0002tZ-JV for tcpm@ietf.org; Thu, 14 Jun 2007 17:12:52 -0400 Received: from mac.com (smtpin03-en2 [10.13.10.148]) by smtpout.mac.com (Xserve/smtpout07/MantshX 4.0) with ESMTP id l5ELCjLv029586; Thu, 14 Jun 2007 14:12:45 -0700 (PDT) Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu [192.150.186.170]) (authenticated bits=0) by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5ELCgTa017607; Thu, 14 Jun 2007 14:12:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Date: Thu, 14 Jun 2007 14:12:40 -0700 To: tcpm X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Jitu Padhye , Mark Handley Subject: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This email is to ask the working group if RFC 2861 on Congestion Window Validation (CWV) should be left at Experimental, or whether it is time to start the process of moving it to Proposed Standard. RFC 2861, from June 2000, "describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. RFC 2861 also recommends that "the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window)". My understanding is that CWV has been included in Linux since Linux 2.4, but that it is not included in Microsoft. Are there any experience reports about CWV (positive or negative), or experience reports of problems (or the absence of problems) for TCP connections without CWV? Or are there other opinions about whether it is time to start the process of moving RFC 2861 to Proposed Standard? Any feedback would be welcome. - Sally http://www.icir.org/floyd/ In the spirit of doing due diligence with old Experimental RFCs... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jun 14 18:02:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxOE-0000YG-9A; Thu, 14 Jun 2007 18:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxOD-0000YB-8f for tcpm@ietf.org; Thu, 14 Jun 2007 18:02:01 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyxOB-0006JU-V9 for tcpm@ietf.org; Thu, 14 Jun 2007 18:02:01 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EM13nE017252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2007 18:01:03 -0400 (EDT) Date: Thu, 14 Jun 2007 18:01:03 -0400 (EDT) From: Salman Abdul Baset To: Sally Floyd Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Jitu Padhye , tcpm , Eli Brosh , Mark Handley X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org For application limited workloads such as streaming over TCP, we have found that the CW validation mechanism, which decays CW for a sufficiently long application-limited period, can increase sensitivity to timeouts. -s On Thu, 14 Jun 2007, Sally Floyd wrote: > This email is to ask the working group if RFC 2861 on Congestion > Window Validation (CWV) should be left at Experimental, or whether > it is time to start the process of moving it to Proposed Standard. > > RFC 2861, from June 2000, "describes a simple modification to TCP's > congestion control algorithms to decay the congestion window cwnd > after the transition from a sufficiently-long application-limited > period, while using the slow-start threshold ssthresh to save > information about the previous value of the congestion window. > > RFC 2861 also recommends that "the TCP sender should not increase > the congestion window when the TCP sender has been application-limited > (and therefore has not fully used the current congestion window)". > > My understanding is that CWV has been included in Linux since > Linux 2.4, but that it is not included in Microsoft. > > Are there any experience reports about CWV (positive or negative), > or experience reports of problems (or the absence of problems) for > TCP connections without CWV? Or are there other opinions about > whether it is time to start the process of moving RFC 2861 to > Proposed Standard? Any feedback would be welcome. > > - Sally > http://www.icir.org/floyd/ > > In the spirit of doing due diligence with old Experimental RFCs... > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 15 06:25:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8zc-0006JA-7K; Fri, 15 Jun 2007 06:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8zb-0006J5-IL for tcpm@ietf.org; Fri, 15 Jun 2007 06:25:23 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8za-00051P-8V for tcpm@ietf.org; Fri, 15 Jun 2007 06:25:23 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5FAORQW012852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jun 2007 06:24:29 -0400 (EDT) Date: Fri, 15 Jun 2007 06:24:27 -0400 (EDT) From: Salman Abdul Baset To: Jitu Padhye Subject: RE: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tcpm , Eli Brosh , Mark Handley , Murari Sridharan X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Consider this example: Suppose there is a flow which sends one packet per RTT and RFC 3390 was inplace so initial window was four. Also, suppose there was no loss. Since the application was sending one packet per RTT, the cwnd should be adjusted to one (is this correct?) after an application limited period. Is this an acceptable behavior? -s On Thu, 14 Jun 2007, Jitu Padhye wrote: > This concern was mentioned by Murari as well. (adding Murari to discussion). > > - Jitu > > -----Original Message----- > From: Salman Abdul Baset [mailto:salman@cs.columbia.edu] > Sent: Thursday, June 14, 2007 3:01 PM > To: Sally Floyd > Cc: tcpm; Jitu Padhye; Mark Handley; Eli Brosh > Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? > > For application limited workloads such as streaming over TCP, we have > found that the CW validation mechanism, which decays CW for a sufficiently > long application-limited period, can increase sensitivity to timeouts. > -s > > > On Thu, 14 Jun 2007, Sally Floyd wrote: > >> This email is to ask the working group if RFC 2861 on Congestion >> Window Validation (CWV) should be left at Experimental, or whether >> it is time to start the process of moving it to Proposed Standard. >> >> RFC 2861, from June 2000, "describes a simple modification to TCP's >> congestion control algorithms to decay the congestion window cwnd >> after the transition from a sufficiently-long application-limited >> period, while using the slow-start threshold ssthresh to save >> information about the previous value of the congestion window. >> >> RFC 2861 also recommends that "the TCP sender should not increase >> the congestion window when the TCP sender has been application-limited >> (and therefore has not fully used the current congestion window)". >> >> My understanding is that CWV has been included in Linux since >> Linux 2.4, but that it is not included in Microsoft. >> >> Are there any experience reports about CWV (positive or negative), >> or experience reports of problems (or the absence of problems) for >> TCP connections without CWV? Or are there other opinions about >> whether it is time to start the process of moving RFC 2861 to >> Proposed Standard? Any feedback would be welcome. >> >> - Sally >> http://www.icir.org/floyd/ >> >> In the spirit of doing due diligence with old Experimental RFCs... >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jun 15 06:26:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz90J-0006QN-HY; Fri, 15 Jun 2007 06:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz90H-0006Pu-Uu for tcpm@ietf.org; Fri, 15 Jun 2007 06:26:05 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz90G-0005Be-HS for tcpm@ietf.org; Fri, 15 Jun 2007 06:26:05 -0400 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:26:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2007 11:26:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making draft-moncaster-tcpm-rcv-cheat-01 a working group item? Thread-Index: AcevN5f7FHoqwiWMSWuaUzpNRP48Eg== From: To: X-OriginalArrivalTime: 15 Jun 2007 10:26:03.0685 (UTC) FILETIME=[938C3550:01C7AF37] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: faber@ISI.EDU, mallman@icir.org Subject: [tcpm] Making draft-moncaster-tcpm-rcv-cheat-01 a working group item? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi All, We believe that the revised version of our draft "A TCP Test to Allow Senders to Identify Receiver Non-Compliance" addresses all the earlier concerns raised by people on this list. We would therefore like to request that it be considered for working group item. For those of you that haven't had a chance to read the revised version yet it is at We would like to present the revised draft at Chicago. If agenda slots are being assigned yet could we request one please? Thanks, Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 18 18:24:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Pdm-00010K-KS; Mon, 18 Jun 2007 18:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0PYg-0000WD-M2 for tcpm@ietf.org; Mon, 18 Jun 2007 18:18:50 -0400 Received: from [2001:5e8:2:42:2e0:81ff:fe30:e898] (helo=mailer2.psc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0PVp-00019P-Cy for tcpm@ietf.org; Mon, 18 Jun 2007 18:15:54 -0400 Received: from [128.182.154.132] (ice.wlan.psc.edu [128.182.154.132]) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id l5IMFlks020575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2007 18:15:47 -0400 (EDT) Message-ID: <46770412.8090307@psc.edu> Date: Mon, 18 Jun 2007 18:15:46 -0400 From: John Heffner User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Sally Floyd Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed Standard? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Jitu Padhye , tcpm , Mark Handley X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Sally Floyd wrote: > This email is to ask the working group if RFC 2861 on Congestion > Window Validation (CWV) should be left at Experimental, or whether > it is time to start the process of moving it to Proposed Standard. > > RFC 2861, from June 2000, "describes a simple modification to TCP's > congestion control algorithms to decay the congestion window cwnd > after the transition from a sufficiently-long application-limited > period, while using the slow-start threshold ssthresh to save > information about the previous value of the congestion window. > > RFC 2861 also recommends that "the TCP sender should not increase > the congestion window when the TCP sender has been application-limited > (and therefore has not fully used the current congestion window)". > > My understanding is that CWV has been included in Linux since > Linux 2.4, but that it is not included in Microsoft. > > Are there any experience reports about CWV (positive or negative), > or experience reports of problems (or the absence of problems) for > TCP connections without CWV? Or are there other opinions about > whether it is time to start the process of moving RFC 2861 to > Proposed Standard? Any feedback would be welcome. There have been enough reports of performance problems with intrinsically bursty applications that an option was added to Linux to disable cwnd decay. (It is still enabled by default.) I'm not aware of any issues with the "not raising cwnd when application-limited" part. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jun 18 19:51:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0R03-0005uB-LH; Mon, 18 Jun 2007 19:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0R02-0005u5-3g for tcpm@ietf.org; Mon, 18 Jun 2007 19:51:10 -0400 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0R00-0004OA-NR for tcpm@ietf.org; Mon, 18 Jun 2007 19:51:10 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l5INp7ME017253 for ; Mon, 18 Jun 2007 16:51:07 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id F024CBEF558 for ; Mon, 18 Jun 2007 19:51:01 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2A48223B275 for ; Mon, 18 Jun 2007 19:50:34 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Cheap Sunglasses MIME-Version: 1.0 Date: Mon, 18 Jun 2007 19:50:34 -0400 Message-Id: <20070618235034.2A48223B275@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [tcpm] Lakshminath Dondeti: Request to forward the Nomcom 2007-8 Announcement to lists you manage X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1880544323==" Errors-To: tcpm-bounces@ietf.org --===============1880544323== Content-Type: multipart/signed; boundary="==_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --==_bOundary Content-Type: multipart/mixed; boundary="=_bOundary" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline forwarded on bahalf of the nomcom chair --=_bOundary Content-Type: message/rfc822; charset=us-ascii Content-Disposition: attachment; filename=678 Content-Description: forwarded message Return-Path: ldondeti@qualcomm.com Delivery-Date: Sat Jun 16 12:55:34 2007 Return-Path: X-Original-To: mallman@localhost Delivered-To: mallman@localhost.icir.org Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 11F9EBDF99B for ; Sat, 16 Jun 2007 12:55:34 -0400 (EDT) Received: from mailhost.icsi.berkeley.edu [192.150.186.11] by guns.icir.org with IMAP (fetchmail-6.3.8) for (single-drop); Sat, 16 Jun 2007 12:55:34 -0400 (EDT) Received: from pork.ICSI.Berkeley.EDU (pork [192.150.186.19]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id l5GGtN8O021762 for ; Sat, 16 Jun 2007 09:55:23 -0700 (PDT) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l5GGtNZG002939 for ; Sat, 16 Jun 2007 09:55:23 -0700 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbYO-0005cj-Ua; Sat, 16 Jun 2007 12:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzbYN-0005Re-Sd; Sat, 16 Jun 2007 12:55:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzbYM-00054K-HK; Sat, 16 Jun 2007 12:55:11 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5GGt8I4018830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 16 Jun 2007 09:55:09 -0700 Received: from [10.50.73.110] (qconnect-10-50-73-110.qualcomm.com [10.50.73.110]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5GGt8OT011960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Jun 2007 09:55:08 -0700 (PDT) Message-ID: <467415E9.7010009@qualcomm.com> Date: Sat, 16 Jun 2007 09:55:05 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: wgchairs@ietf.org, irsg@isi.edu, bofchairs@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: Request to forward the Nomcom 2007-8 Announcement to lists you manage X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: wgchairs-bounces@ietf.org X-ClamAV: OK X-SpamProbe: GOOD 0.0000691 718a51859f4e5d4e6b98ec073daab362 X-mallman-sequence: iman iman2 Folks, We have around 50 volunteers so far for Nomcom 2007-8 voting member selection. We need a lot more! Not everyone subscribes to the IETF-Announce list. Could you please forward the announcement https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234 to WG, RG, BoF, Area lists that you manage? Thanks in advance. best regards, Lakshminath --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGdxpJWyrrWs4yIs4RAktUAJ4rEIBfvVdxlhSAe7RtMRukGgPfMgCfa5Wr JrH/1Hv8MAy9sgsHotMnLMQ= =RrOY -----END PGP SIGNATURE----- --==_bOundary-- --===============1880544323== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1880544323==-- From tcpm-bounces@ietf.org Wed Jun 20 02:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tbU-0000MQ-Ll; Wed, 20 Jun 2007 02:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tbT-0000IX-Jg for tcpm@ietf.org; Wed, 20 Jun 2007 02:23:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0tbS-0004v0-8M for tcpm@ietf.org; Wed, 20 Jun 2007 02:23:43 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2007 23:23:41 -0700 X-IronPort-AV: i="4.16,441,1175497200"; d="vcf'?scan'208,217"; a="168534662:sNHT164435193" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5K6NfpK026105 for ; Tue, 19 Jun 2007 23:23:41 -0700 Received: from [10.21.105.99] (sjc-vpnasa-353.cisco.com [10.21.105.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5K6NftV019191 for ; Wed, 20 Jun 2007 06:23:43 GMT Message-ID: <4678C7E0.9090309@cisco.com> Date: Tue, 19 Jun 2007 23:23:28 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: multipart/mixed; boundary="------------030808000901020806060209" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25865; t=1182320621; x=1183184621; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20draft-mahesh-persist-timeout-01 |Sender:=20; bh=1FV7epqP7B/bbtzvTBkX1wSgLO1+GT2+Y6YoiasrmUg=; b=bhm3LMAQ8CuYog8FFMJbH2i21peXWkQelOxypnVOOUarVaE1EPbGbEq0qwS7G+eO79fMlLNi Jp8JT5j9RYtxFGIVU8+5GukpGJN/ak7W3o0409HYnhrF6pscS1wj30z4; Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 Subject: [tcpm] draft-mahesh-persist-timeout-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------030808000901020806060209 Content-Type: multipart/alternative; boundary="------------090901080303080903090405" --------------090901080303080903090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Wanted to bring to this mailing list some of the discussion we have had off the list regarding the following draft. http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-01.txt "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 7-Mar-07, Erik Nordmark wrote: > As we discussed in Prague, using a fixed timeout for zero-window is > too simplistic. > I don't know how much detail it makes sense to go into in the draft on > more elaborate schemes. Kacheong Poon wrote: > I am not too sure if the proposed scheme is effective for > more clever attacks. For example, an attacker can always > make sure that the receive window is not completely close. > So TCP will never enter persist state. But the effect of > the attack is still the same. And an attacker may just want > the victim to be in such a memory shortage state temporarily > for some reason. The use of a timer (even as modified as the > above) is not that useful. I suspect that there are other > schemes which can "work around" the method as suggested. > > It seems to me that an OS should provide some form of > protection in a more general context for this kind of outside > attack. But I guess it probably does not belong to IETF as > it is more an OS security/resource control topic, and does not > need to be "interoperable." Kacheong Poon wrote: > I'm curious what the gaming server will do in this case. The > write to the connection will block. Will it just close the > connection after write is blocked for a long time? I know that > TCP will still keep the connection around after the close. I'm > just wondering if a "force abort after close" timer is also > useful. It is more or less a super-set of the FIN-WAIT-2 timer. > And the difference between this and your scheme is that the timer > starts even if TCP is not in persist state. This may be easier > to comprehend by a sys admin or app programmer as it does not > involve any TCP protocol knowledge. Just a thought. Mahesh Jethanandani wrote: >> I'm curious what the gaming server will do in this case. The >> write to the connection will block. Will it just close the >> connection after write is blocked for a long time? I know that >> TCP will still keep the connection around after the close. I'm >> just wondering if a "force abort after close" timer is also >> useful. It is more or less a super-set of the FIN-WAIT-2 timer. >> And the difference between this and your scheme is that the timer >> starts even if TCP is not in persist state. This may be easier >> to comprehend by a sys admin or app programmer as it does not >> involve any TCP protocol knowledge. Just a thought. >> >> > The assumption is that the gaming server had no more data to send. In > this particular case it did. Because the client had not closed the > connection, the gaming server had to continue to send updates to the > client. When the write returned a block, application did not know if > the write is blocked because of issues in the network or because the > client was reliably sending a zero window. I think it is important to > distinguish between the two cases as the latter has the tone of a DoS > attack. The draft specifically addresses the latter case. > > It is also not clear what "long time" is. What might be a long time in > application terms might be a death knell for TCP when it is dealing > with hundred of these kind of connections. That is why we talk about a > LRU scheme in TCP itself to knock out connections that are in persist > state and are not moving data. Anantha Ramaiah wrote: > I'm curious what the gaming server will do in this case. The > > write to the connection will block. Will it just close the > > connection after write is blocked for a long time? I know > > > Well, it depends on the application. > > >> > that TCP will still keep the connection around after the >> > close. I'm just wondering if a "force abort after close" >> > > Even if closes the connection, it moves FINWAIT1, but would never get an > ACK since according to RFC > > "If the RCV.WND is zero, no segments will be acceptable, but > special allowance should be made to accept valid ACKs, URGs and > RSTs." > > Since most likely, the segment len would be > 0. [Since there may still > be data in the retransmit queue] > > >> > timer is also >> > useful. It is more or less a super-set of the > >> > FIN-WAIT-2 timer. >> > And the difference between this and your scheme is that the >> > timer starts even if TCP is not in persist state. This may >> > be easier to comprehend by a sys admin or app programmer as >> > it does not involve any TCP protocol knowledge. Just a thought. >> > > Assuming you get to FINWAIT2. The point here is, the situation described > in the draft is a "special case" which when hit adversly affects the > robustness of the protocol, since it is a potential DOS scenario. > > One other thing is that the draft is targetted to be an informational > one and also this attempts to document the incorrectness found in the > RFC 1122's verbiage. (This response comes from your other observation > about whether this really belongs to standards or simply an OS issue) > > >> > >> > >> > >> >>> > > We have implemented it for NetBSD. The changes are fai Kacheong Poon wrote: > that TCP will still keep the connection around after the > >> close. I'm just wondering if a "force abort after close" > > > > > Even if closes the connection, it moves FINWAIT1, but would never get an > > ACK since according to RFC > > > > "If the RCV.WND is zero, no segments will be acceptable, but > > special allowance should be made to accept valid ACKs, URGs and > > RSTs." > > > > Since most likely, the segment len would be > 0. [Since there may still > > be data in the retransmit queue] > > > > Suppose the other side is advertising a zero window. I think > after the close of a socket, TCP will not send out a FIN to the > other side as there is still unsent data. This means that TCP > will not move to FIN-WAIT-1 state. Could you elaborate on what > you referred to above? > > The idea of a "force abort after close" is regardless of > what state a TCP connection is in, the timer will abort, > meaning sending a RST, the connection. For example, a clever > attacker can make sure that the receive window is not really 0 > such that the connection is not in persist state, but is still > alive. One way is to acknowledge one byte in, say every 60 seconds. > This is effectively the same kind of attack described in your > draft. If we have a "force abort after close" timer, it means > that TCP will abort the connection even in the above case. Note > that the timeout value should be chosen carefully. > > > > > >> > Assuming you get to FINWAIT2. The point here is, the situation described >> > in the draft is a "special case" which when hit adversly affects the >> > robustness of the protocol, since it is a potential DOS scenario. >> > > > If the state is FIN-WAIT-2, it means that there is no > un-acknowledged data and TCP does not have anything in the > send buffer. I suppose there is no problem. And I think > most, if not all, TCP implementations have a FIN-WAIT-2 timer > to kill the hanging PCB. It is generally not a problem. > > > >> > One other thing is that the draft is targetted to be an informational >> > one and also this attempts to document the incorrectness found in the >> > RFC 1122's verbiage. (This response comes from your other observation >> > about whether this really belongs to standards or simply an OS issue) >> > > > The question I referred to is a more general resource control > mechanism in an OS. It does not seem to me that a TCP timer > is very effective in protecting many different kinds of attacks, > one of which is described in your draft. I am not saying that > we should not do anything in this particular problem. But > I guess we probably need a more general mechanism for the wider > scoped issue. > Anantha Ramaiah wrote: > Anantha Ramaiah (ananth) wrote: > > > >>> > >> that TCP will still keep the connection around after the >>> > > close. I'm > >>> > >> just wondering if a "force abort after close" >>> >> > > >> > > Even if closes the connection, it moves FINWAIT1, but would >> > > never get > >> > > an ACK since according to RFC >> > > >> > > "If the RCV.WND is zero, no segments will be acceptable, >> > > but special > >> > > allowance should be made to accept valid ACKs, URGs and RSTs." >> > > >> > > Since most likely, the segment len would be > 0. [Since there may >> > > still be data in the retransmit queue] >> > > > > > > Suppose the other side is advertising a zero window. I think > > after the close of a socket, TCP will not send out a FIN to > > the other side as there is still unsent data. This means > > that TCP will not move to FIN-WAIT-1 state. Could you > > elaborate on what you referred to above? > > > Yes, that is correct and I stand corrected. TCP wouldn't move to > FINWAIT1 at all. Looks like I mis-understood your original text, so if I > understand correcty you are suggesting an timeout for each state of the > TCB? Typically we don't have TIMEOUT's on FINWAIT1 state. In any case to > get back to focus on the current draft, it all arises since RFC 1122 > indefinetely recommends persist state. > > >> > >> > The idea of a "force abort after close" is regardless of what >> > state a TCP connection is in, the timer will abort, meaning >> > sending a RST, the connection. For example, a clever >> > attacker can make sure that the receive window is not really >> > 0 such that the connection is not in persist state, but is >> > still alive. One way is to acknowledge one byte in, say >> > every 60 seconds. >> > > Well, assuming that the application does timeout, so applications would > have the responsibility to timeout. > --------------090901080303080903090405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Wanted to bring to this mailing list some of the discussion we have had off the list regarding the following draft.

 http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-01.txt
  "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 7-Mar-07, <draft-mahesh-persist-timeout-01.txt> 


Erik Nordmark wrote:
As we discussed in Prague, using a fixed timeout for zero-window is too simplistic.
I don't know how much detail it makes sense to go into in the draft on more elaborate schemes.
Kacheong Poon wrote:
I am not too sure if the proposed scheme is effective for
more clever attacks.  For example, an attacker can always
make sure that the receive window is not completely close.
So TCP will never enter persist state.  But the effect of
the attack is still the same.  And an attacker may just want
the victim to be in such a memory shortage state temporarily
for some reason.  The use of a timer (even as modified as the
above) is not that useful.  I suspect that there are other
schemes which can "work around" the method as suggested.

It seems to me that an OS should provide some form of
protection in a more general context for this kind of outside
attack.  But I guess it probably does not belong to IETF as
it is more an OS security/resource control topic, and does not
need to be "interoperable."
Kacheong Poon wrote:
I'm curious what the gaming server will do in this case.  The
write to the connection will block.  Will it just close the
connection after write is blocked for a long time?  I know that
TCP will still keep the connection around after the close.  I'm
just wondering if a "force abort after close" timer is also
useful.  It is more or less a super-set of the FIN-WAIT-2 timer.
And the difference between this and your scheme is that the timer
starts even if TCP is not in persist state.  This may be easier
to comprehend by a sys admin or app programmer as it does not
involve any TCP protocol knowledge.  Just a thought.
Mahesh Jethanandani wrote:
I'm curious what the gaming server will do in this case.  The
write to the connection will block.  Will it just close the
connection after write is blocked for a long time?  I know that
TCP will still keep the connection around after the close.  I'm
just wondering if a "force abort after close" timer is also
useful.  It is more or less a super-set of the FIN-WAIT-2 timer.
And the difference between this and your scheme is that the timer
starts even if TCP is not in persist state.  This may be easier
to comprehend by a sys admin or app programmer as it does not
involve any TCP protocol knowledge.  Just a thought.
The assumption is that the gaming server had no more data to send. In this particular case it did. Because the client had not closed the connection, the gaming server had to continue to send updates to the client. When the write returned a block, application did not know if the write is blocked because of issues in the network or because the client was reliably sending a zero window. I think it is important to distinguish between the two cases as the latter has the tone of a DoS attack. The draft specifically addresses the latter case.

It is also not clear what "long time" is. What might be a long time in application terms might be a death knell for TCP when it is dealing with hundred of these kind of connections. That is why we talk about a LRU scheme in TCP itself to knock out connections that are in persist state and are not moving data.

Anantha Ramaiah wrote:
I'm curious what the gaming server will do in this case.  The 
> write to the connection will block.  Will it just close the 
> connection after write is blocked for a long time?  I know 
  

Well, it depends on the application. 

  
> that TCP will still keep the connection around after the 
> close.  I'm just wondering if a "force abort after close" 
    

Even if closes the connection, it moves FINWAIT1, but would never get an
ACK since according to RFC
 
"If the RCV.WND is zero, no segments will be acceptable, but
 special allowance should be made to accept valid ACKs, URGs and
 RSTs."

Since most likely, the segment len would be > 0. [Since there may still
be data in the retransmit queue]

  
> timer is also 
    
useful.  It is more or less a super-set of the 
  
> FIN-WAIT-2 timer.
> And the difference between this and your scheme is that the 
> timer starts even if TCP is not in persist state.  This may 
> be easier to comprehend by a sys admin or app programmer as 
> it does not involve any TCP protocol knowledge.  Just a thought.
    

Assuming you get to FINWAIT2. The point here is, the situation described
in the draft is a "special case" which when hit adversly affects the
robustness of the protocol, since it is a potential DOS scenario. 

One other thing is that the draft is targetted to be an informational
one and also this attempts to document the incorrectness found in the
RFC 1122's verbiage. (This response comes from your other observation
about whether this really belongs to standards or simply an OS issue) 

  
> 
> 
> 
    
> > We have implemented it for NetBSD. The changes are fai
Kacheong Poon wrote:
that TCP will still keep the connection around after the 
>> close.  I'm just wondering if a "force abort after close" 
  
> 
> Even if closes the connection, it moves FINWAIT1, but would never get an
> ACK since according to RFC
>  
> "If the RCV.WND is zero, no segments will be acceptable, but
>  special allowance should be made to accept valid ACKs, URGs and
>  RSTs."
> 
> Since most likely, the segment len would be > 0. [Since there may still
> be data in the retransmit queue]
  


Suppose the other side is advertising a zero window.  I think
after the close of a socket, TCP will not send out a FIN to the
other side as there is still unsent data.  This means that TCP
will not move to FIN-WAIT-1 state.  Could you elaborate on what
you referred to above?

The idea of a "force abort after close" is regardless of
what state a TCP connection is in, the timer will abort,
meaning sending a RST, the connection.  For example, a clever
attacker can make sure that the receive window is not really 0
such that the connection is not in persist state, but is still
alive.  One way is to acknowledge one byte in, say every 60 seconds.
This is effectively the same kind of attack described in your
draft.  If we have a "force abort after close" timer, it means
that TCP will abort the connection even in the above case.  Note
that the timeout value should be chosen carefully.




  
> Assuming you get to FINWAIT2. The point here is, the situation described
> in the draft is a "special case" which when hit adversly affects the
> robustness of the protocol, since it is a potential DOS scenario. 
    


If the state is FIN-WAIT-2, it means that there is no
un-acknowledged data and TCP does not have anything in the
send buffer.  I suppose there is no problem.  And I think
most, if not all, TCP implementations have a FIN-WAIT-2 timer
to kill the hanging PCB.  It is generally not a problem.


  
> One other thing is that the draft is targetted to be an informational
> one and also this attempts to document the incorrectness found in the
> RFC 1122's verbiage. (This response comes from your other observation
> about whether this really belongs to standards or simply an OS issue) 
    


The question I referred to is a more general resource control
mechanism in an OS.  It does not seem to me that a TCP timer
is very effective in protecting many different kinds of attacks,
one of which is described in your draft.  I am not saying that
we should not do anything in this particular problem.  But
I guess we probably need a more general mechanism for the wider
scoped issue.
Anantha Ramaiah wrote:
Anantha Ramaiah (ananth) wrote:
> 
  
> >> that TCP will still keep the connection around after the 
      
> close.  I'm 
  
> >> just wondering if a "force abort after close"
      
> > 
> > Even if closes the connection, it moves FINWAIT1, but would 
    
> never get 
  
> > an ACK since according to RFC
> >  
> > "If the RCV.WND is zero, no segments will be acceptable, 
    
> but  special 
  
> > allowance should be made to accept valid ACKs, URGs and  RSTs."
> > 
> > Since most likely, the segment len would be > 0. [Since there may 
> > still be data in the retransmit queue]
    
> 
> 
> Suppose the other side is advertising a zero window.  I think 
> after the close of a socket, TCP will not send out a FIN to 
> the other side as there is still unsent data.  This means 
> that TCP will not move to FIN-WAIT-1 state.  Could you 
> elaborate on what you referred to above?
  

Yes, that is correct and I stand corrected. TCP wouldn't move to
FINWAIT1 at all. Looks like I mis-understood your original text, so if I
understand correcty you are suggesting an timeout for each state of the
TCB? Typically we don't have TIMEOUT's on FINWAIT1 state. In any case to
get back to focus on the current draft, it all arises since RFC 1122
indefinetely recommends persist state.

  
> 
> The idea of a "force abort after close" is regardless of what 
> state a TCP connection is in, the timer will abort, meaning 
> sending a RST, the connection.  For example, a clever 
> attacker can make sure that the receive window is not really 
> 0 such that the connection is not in persist state, but is 
> still alive.  One way is to acknowledge one byte in, say 
> every 60 seconds.
    

Well, assuming that the application does timeout, so applications would
have the responsibility to timeout.
  




--------------090901080303080903090405--

--------------030808000901020806060209
Content-Type: text/x-vcard; charset=utf-8;
 name="mahesh.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="mahesh.vcf"

begin:vcard
fn:Mahesh Jethanandani
n:Jethanandani;Mahesh
email;internet:mahesh@cisco.com
tel;work:408 527-8230
tel;fax:408 527-8230
x-mozilla-html:TRUE
version:2.1
end:vcard


--------------030808000901020806060209
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://www1.ietf.org/mailman/listinfo/tcpm

--------------030808000901020806060209--




From tcpm-bounces@ietf.org Mon Jun 25 15:51:44 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I2uat-0001Hj-3Y; Mon, 25 Jun 2007 15:51:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I2uaT-0000e3-8e; Mon, 25 Jun 2007 15:51:01 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1I2uZW-0003vM-VA; Mon, 25 Jun 2007 15:50:03 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A110126E69;
	Mon, 25 Jun 2007 19:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1I2uZW-0000gu-GW; Mon, 25 Jun 2007 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: 
Date: Mon, 25 Jun 2007 15:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: tcpm@ietf.org
Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-06.txt 
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
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's Reaction to Soft Errors
	Author(s)	: F. Gont
	Filename	: draft-ietf-tcpm-tcp-soft-errors-06.txt
	Pages		: 15
	Date		: 2007-6-25
	
This document describes a non-standard, but widely implemented,
   modification to TCP's handling of ICMP soft error messages, that
   rejects pending connection-requests when those error messages are
   received.  This behavior reduces the likelihood of long delays
   between connection establishment attempts that may arise in a number
   of scenarios, including one in which dual stack nodes that have IPv6
   enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
   environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-tcpm-tcp-soft-errors-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-6-25144927.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-tcpm-tcp-soft-errors-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-6-25144927.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/tcpm

--NextPart--





From tcpm-bounces@ietf.org Wed Jun 27 15:44:18 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3dQq-0007bs-CD; Wed, 27 Jun 2007 15:44:04 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dQp-0007XY-2X
	for tcpm@ietf.org; Wed, 27 Jun 2007 15:44:03 -0400
Received: from pork.icsi.berkeley.edu ([192.150.186.19])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3dQo-00087l-Ok
	for tcpm@ietf.org; Wed, 27 Jun 2007 15:44:02 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
	[69.222.35.58])
	by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id
	l5RJhjCY020833; Wed, 27 Jun 2007 12:43:45 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net
	[69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id AA3F1C3808E;
	Wed, 27 Jun 2007 15:43:40 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP id 316A7247B03;
	Wed, 27 Jun 2007 15:42:57 -0400 (EDT)
To: tcpm@ietf.org
From: Mark Allman 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Lonesome Day
MIME-Version: 1.0
Date: Wed, 27 Jun 2007 15:42:57 -0400
Message-Id: <20070627194257.316A7247B03@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Ted Faber 
Subject: [tcpm] agenda requests
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0499751340=="
Errors-To: tcpm-bounces@ietf.org

--===============0499751340==
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=_bOundary
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

 
Folks-

Please send agenda requests to Ted and I.  I have a list of folks who
have pinged me, but assume I have dropped a bit because folks started
pinging pretty early this time and so I am not sure I have everything.
We need the speaker's name, the I-D you wish to discuss [*] and a time
request.

[*] Discussing something that is not an I-D can be proposed, but we will
    prioritize requests with I-Ds ahead of such requests.

Thanks,
allman




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGgr3AWyrrWs4yIs4RApisAJ9xQoYoshpiVnGvoMwYAk6CDfdvKQCdFALu
UrpWmidQIax/zQC2B7GSX2k=
=bOW3
-----END PGP SIGNATURE-----
--=_bOundary--


--===============0499751340==
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://www1.ietf.org/mailman/listinfo/tcpm

--===============0499751340==--




From tcpm-bounces@ietf.org Wed Jun 27 18:23:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3fvG-00053H-Ab; Wed, 27 Jun 2007 18:23:38 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fvE-00053C-FN
	for tcpm@ietf.org; Wed, 27 Jun 2007 18:23:36 -0400
Received: from smtpout.mac.com ([17.250.248.171])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fvE-0007pO-4d
	for tcpm@ietf.org; Wed, 27 Jun 2007 18:23:36 -0400
Received: from mac.com (smtpin03-en2 [10.13.10.148])
	by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id
	l5RMNAFc022180; Wed, 27 Jun 2007 15:23:11 -0700 (PDT)
Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu
	[192.150.186.170]) (authenticated bits=0)
	by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5RMN9wq007411; 
	Wed, 27 Jun 2007 15:23:09 -0700 (PDT)
In-Reply-To: <20070627194257.316A7247B03@lawyers.icir.org>
References: <20070627194257.316A7247B03@lawyers.icir.org>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <61941176f0ba73d543b2cb704c3929d6@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd 
Subject: Re: [tcpm] agenda requests
Date: Wed, 27 Jun 2007 15:23:09 -0700
To: mallman@icir.org
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: tcpm@ietf.org, Ted Faber 
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

I have several requests for slots:

#1:
Speaker: Sally Floyd
ID: Adding Acknowledgement Congestion Control to TCP,
      draft-floyd-tcpm-ackcc-01.txt
Time: 10-15 minutes

This is new since the last IETF.  We would like it to be
accepted as a tcpm work.  It is targeted for Experimental.


#2:
Speaker: Sally Floyd
ID: Adding Explicit Congestion Notification (ECN) Capability to TCP's 
SYN/ACK Packets,
      draft-ietf-tcpm-ecnsyn-01 (expired, but a new version will be 
submitted)
Time: 5-10 minutes

This is an old draft, which has been on hold for two issues to be 
resolved.
We hope to have the results in time to submit a revised draft by July 9.


#3 (only if there is time)"
Speaker: Sally Floyd
ID: RFC 2861 on TCP Congestion Window Validation.
Time: 5 minutes

We raised the question on the mailing list of whether this Experimental
draft should progress to Proposed Standard.  From the feedback on the
mailing list, one would think not.  But *if* there was time, it could be
discussed in Chicago.

Many thanks.
- Sally
http://www.icir.org/floyd/


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm



From tcpm-bounces@ietf.org Wed Jun 27 19:06:21 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3gaa-0000XZ-0X; Wed, 27 Jun 2007 19:06:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gaZ-0000XR-7u
	for tcpm@ietf.org; Wed, 27 Jun 2007 19:06:19 -0400
Received: from smtpout.mac.com ([17.250.248.185])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3gaG-00059K-VM
	for tcpm@ietf.org; Wed, 27 Jun 2007 19:06:19 -0400
Received: from mac.com (smtpin03-en2 [10.13.10.148])
	by smtpout.mac.com (Xserve/smtpout15/MantshX 4.0) with ESMTP id
	l5RN57JO003176; Wed, 27 Jun 2007 16:05:07 -0700 (PDT)
Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu
	[192.150.186.170]) (authenticated bits=0)
	by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5RN54x7023940; 
	Wed, 27 Jun 2007 16:05:05 -0700 (PDT)
In-Reply-To: 
References: 
	
	
	
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Sally Floyd 
Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed
	Standard?
Date: Wed, 27 Jun 2007 16:05:04 -0700
To: Salman Abdul Baset 
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: Murari Sridharan ,
	Jitu Padhye , tcpm ,
	Eli Brosh , Mark Handley 
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

> Suppose there is a flow which sends one packet per RTT and RFC 3390 
> was inplace so initial window was four. Also, suppose there was no 
> loss. Since the application was sending one packet per RTT, the cwnd 
> should be adjusted to one (is this correct?) after an application 
> limited period. Is this an acceptable behavior?

That is what is described in RFC 2861 (which was written before RFC 
3390).

However, I think that the correct way to update RFC 2861 in light of 
RFC 3390
would be to say that cwnd is never reduced to less than the *initial 
window*
in response to an application-limited period.  This is pretty much what
TFRC does (in Section 4.4 of RFC 3448, which came *after* RFC 3390,
but which uses ideas from RFC 2861).

This is also quite explicit in Section 5.1 of CCID-3 (RFC 4342) for the
response to idle periods:

    "In [RFC3448], Section 4.4, the allowed
    sending rate is never reduced to fewer than two packets per round-
    trip time as the result of an idle period.  CCID 3 revises this to
    take into account the larger initial windows allowed by [RFC3390]:
    the allowed sending rate is never reduced to less than the [RFC3390]
    initial sending rate as the result of an idle period.  If the allowed
    sending rate is less than the initial sending rate upon entry to the
    idle period, then it will still be less than the initial sending rate
    when the idle period is exited.  However, if the allowed sending rate
    is greater than or equal to the initial sending rate upon entry to
    the idle period, then it should not be reduced below the initial
    sending rate no matter how long the idle period lasts."

(We should make this change even if we leave RFC 2861 as
Experimental, so that cwnd is not reduced to below the initial window
after an idle or application-limited period.  It would be nice if I 
could do
that just with an Errata...)

- Sally
http://www.icir.org/floyd/




>> -----Original Message-----
>> From: Salman Abdul Baset [mailto:salman@cs.columbia.edu]
>> Sent: Thursday, June 14, 2007 3:01 PM
>> To: Sally Floyd
>> Cc: tcpm; Jitu Padhye; Mark Handley; Eli Brosh
>> Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to 
>> Proposed Standard?
>>
>> For application limited workloads such as streaming over TCP, we have
>> found that the CW validation mechanism, which decays CW for a 
>> sufficiently
>> long application-limited period, can increase sensitivity to timeouts.
>> -s
>>
>>
>> On Thu, 14 Jun 2007, Sally Floyd wrote:
>>
>>> This email is to ask the working group if RFC 2861 on Congestion
>>> Window Validation (CWV) should be left at Experimental, or whether
>>> it is time to start the process of moving it to Proposed Standard.
>>>
>>> RFC 2861, from June 2000, "describes a simple modification to TCP's
>>> congestion control algorithms to decay the congestion window cwnd
>>> after the transition from a sufficiently-long application-limited
>>> period, while using the slow-start threshold ssthresh to save
>>> information about the previous value of the congestion window.
>>>
>>> RFC 2861 also recommends that "the TCP sender should not increase
>>> the congestion window when the TCP sender has been 
>>> application-limited
>>> (and therefore has not fully used the current congestion window)".
>>>
>>> My understanding is that CWV has been included in Linux since
>>> Linux 2.4, but that it is not included in Microsoft.
>>>
>>> Are there any experience reports about CWV (positive or negative),
>>> or experience reports of problems (or the absence of problems) for
>>> TCP connections without CWV?  Or are there other opinions about
>>> whether it is time to start the process of moving RFC 2861 to
>>> Proposed Standard?  Any feedback would be welcome.
>>>
>>> - Sally
>>> http://www.icir.org/floyd/
>>>
>>> In the spirit of doing due diligence with old Experimental RFCs...
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/tcpm
>>>


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm



From tcpm-bounces@ietf.org Wed Jun 27 19:46:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3hCv-0005tb-D6; Wed, 27 Jun 2007 19:45:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I3hCu-0005tP-Ab
	for tcpm@ietf.org; Wed, 27 Jun 2007 19:45:56 -0400
Received: from smtpout.mac.com ([17.250.248.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3hCG-0008ID-1v
	for tcpm@ietf.org; Wed, 27 Jun 2007 19:45:56 -0400
Received: from mac.com (smtpin03-en2 [10.13.10.148])
	by smtpout.mac.com (Xserve/smtpout02/MantshX 4.0) with ESMTP id
	l5RNj20o004523; Wed, 27 Jun 2007 16:45:02 -0700 (PDT)
Received: from [192.150.186.170] (laptop170.icsi.berkeley.edu
	[192.150.186.170]) (authenticated bits=0)
	by mac.com (Xserve/smtpin03/MantshX 4.0) with ESMTP id l5RNix1h008806; 
	Wed, 27 Jun 2007 16:45:00 -0700 (PDT)
In-Reply-To: <46770412.8090307@psc.edu>
References: 
	<46770412.8090307@psc.edu>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <46ffa03042528d92a9ea2875e1764b19@mac.com>
Content-Transfer-Encoding: 7bit
From: Sally Floyd 
Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed
	Standard?
Date: Wed, 27 Jun 2007 16:44:45 -0700
To: John Heffner 
X-Mailer: Apple Mail (2.624)
X-Brightmail-Tracker: AAAAAA==
X-Brightmail-scanned: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: Murari Sridharan ,
	Jitu Padhye , tcpm ,
	Mark Handley 
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

John -

(Apologies, as always, for the late reply.)

> There have been enough reports of performance problems with 
> intrinsically bursty applications that an option was added to Linux to 
> disable cwnd decay.  (It is still enabled by default.)  I'm not aware 
> of any issues with the "not raising cwnd when application-limited" 
> part.

I understand that bursty applications would often rather not reduce
cwnd after an idle or application-limited periiod.  (It *might* be
in their own interests, if it helps the flow to avoid unnecessary
packet drops, but it *might not* be in their own interests, e.g.,
if that flow doesn't receive any packet drops when bursting after
an idle period.

But the following question also matters:

(1) What about when there are N possibly-bursty flows sharing the
same congested link?  Are there any reports about whether the *N
flows* do better when all flows use CWV, or whether they do better
when none of them use CWV, and none of them reduce cwnd after an
idle period?

(If there is no congestion, I would expect that the N flows do
better without CWV.   If there *is* congestion, I would expect that
the N flows in general do better *with* CWV, as opposed to not
reducing cwnd after idle periods.  But it is not something that one
could tell from reports from individual users...)

------------------------------------------------------------------

The current Proposed Standard behavior in this area, from Section
4.1 of RFC 2581, says that TCP "SHOULD" reduce cwnd to the initial
window after an idle period exceeding the RTO.  RFC 2861 is
considerably more moderate than this.  Does anyone know if there
are TCP implementations out there that follow the "SHOULD" from
RFC 2581, just out of curiosity?

Is the feedback that the Congestion Window Validation mechanism in
RFC 2861 should be modified?  Or that CWV is useful but is just
fine to be left as Experimental?  (That would be fine by me.
Less work...)

- Sally
http://www.icir.org/floyd/


Original email:

> Sally Floyd wrote:
>> This email is to ask the working group if RFC 2861 on Congestion
>> Window Validation (CWV) should be left at Experimental, or whether
>> it is time to start the process of moving it to Proposed Standard.
>> RFC 2861, from June 2000, "describes a simple modification to TCP's
>> congestion control algorithms to decay the congestion window cwnd
>> after the transition from a sufficiently-long application-limited
>> period, while using the slow-start threshold ssthresh to save
>> information about the previous value of the congestion window.
>> RFC 2861 also recommends that "the TCP sender should not increase
>> the congestion window when the TCP sender has been application-limited
>> (and therefore has not fully used the current congestion window)".
>> My understanding is that CWV has been included in Linux since
>> Linux 2.4, but that it is not included in Microsoft.
>> Are there any experience reports about CWV (positive or negative),
>> or experience reports of problems (or the absence of problems) for
>> TCP connections without CWV?  Or are there other opinions about
>> whether it is time to start the process of moving RFC 2861 to
>> Proposed Standard?  Any feedback would be welcome.


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm



From tcpm-bounces@ietf.org Thu Jun 28 04:34:56 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3pSn-0000ud-Bb; Thu, 28 Jun 2007 04:34:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pSl-0000ov-Cr
	for tcpm@ietf.org; Thu, 28 Jun 2007 04:34:51 -0400
Received: from smtp4.smtp.bt.com ([217.32.164.151])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3pRs-0002gg-27
	for tcpm@ietf.org; Thu, 28 Jun 2007 04:34:51 -0400
Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.62]) by
	smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 28 Jun 2007 09:33:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [tcpm] agenda requests
Date: Thu, 28 Jun 2007 09:30:27 +0100
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] agenda requests
Thread-Index: Ace484dKXa+k4hqGR7ueSb8vilCJJwAaeq4M
References: <20070627194257.316A7247B03@lawyers.icir.org>
From: 
To: ,
	
X-OriginalArrivalTime: 28 Jun 2007 08:33:21.0303 (UTC)
	FILETIME=[FC395A70:01C7B95E]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: faber@isi.edu
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

Hi Mark,
=20
as mentioned before, can we have a slot to present the new version of =
our draft:
=20
speaker: Toby Moncaster
draft title: A TCP Test to Allow Senders to Identify Receiver =
Non-Compliance
http://www.ietf.org/internet-drafts/draft-moncaster-tcpm-rcv-cheat-01.txt=

Time: 10 minutes
We are hoping the changes since Prague will prove sufficient to get this =
accepted as a working group item.
=20
Thanks,
=20
Toby
________________________________________________________________
Toby Moncaster,  Networks Research Centre, BT =
Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473 =
648734


________________________________

From: Mark Allman [mailto:mallman@icir.org]
Sent: Wed 27/06/2007 20:42
To: tcpm@ietf.org
Cc: Ted Faber
Subject: [tcpm] agenda requests




Folks-

Please send agenda requests to Ted and I.  I have a list of folks who
have pinged me, but assume I have dropped a bit because folks started
pinging pretty early this time and so I am not sure I have everything.
We need the speaker's name, the I-D you wish to discuss [*] and a time
request.

[*] Discussing something that is not an I-D can be proposed, but we will
    prioritize requests with I-Ds ahead of such requests.

Thanks,
allman






_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm



From tcpm-bounces@ietf.org Thu Jun 28 09:47:48 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I3uLa-0004tQ-KH; Thu, 28 Jun 2007 09:47:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uLY-0004qO-Q6
	for tcpm@ietf.org; Thu, 28 Jun 2007 09:47:44 -0400
Received: from frantic-dmz.weston.borman.com ([206.196.54.22]
	helo=frantic.weston.borman.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3uKd-0007mN-4A
	for tcpm@ietf.org; Thu, 28 Jun 2007 09:47:44 -0400
Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33])
	by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id
	l5SDkirK005010; Thu, 28 Jun 2007 08:46:44 -0500 (CDT)
In-Reply-To: <20070627194257.316A7247B03@lawyers.icir.org>
References: <20070627194257.316A7247B03@lawyers.icir.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: David Borman 
Subject: Re: [tcpm] agenda requests
Date: Thu, 28 Jun 2007 08:46:42 -0500
To: mallman@icir.org
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: tcpm@ietf.org, Ted Faber 
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

I'd like to have a slot for the revision of RFC 1323.  I plan on  
submitting the current revision of the I-D either later today or  
tomorrow.
			-David Borman

On Jun 27, 2007, at 2:42 PM, Mark Allman wrote:

>
> Folks-
>
> Please send agenda requests to Ted and I.  I have a list of folks who
> have pinged me, but assume I have dropped a bit because folks started
> pinging pretty early this time and so I am not sure I have everything.
> We need the speaker's name, the I-D you wish to discuss [*] and a time
> request.
>
> [*] Discussing something that is not an I-D can be proposed, but we  
> will
>     prioritize requests with I-Ds ahead of such requests.
>
> Thanks,
> allman
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm



From tcpm-bounces@ietf.org Fri Jun 29 16:47:33 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I4NN5-00062i-9u; Fri, 29 Jun 2007 16:47:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NN4-000618-MF
	for tcpm@ietf.org; Fri, 29 Jun 2007 16:47:14 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4NMq-0001Pq-91
	for tcpm@ietf.org; Fri, 29 Jun 2007 16:47:14 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 29 Jun 2007 13:46:59 -0700
X-IronPort-AV: i="4.16,476,1175497200"; 
	d="scan'208"; a="174574733:sNHT97449066"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5TKkxd9014208; 
	Fri, 29 Jun 2007 13:46:59 -0700
Received: from [171.69.75.156] (dhcp-171-69-75-156.cisco.com [171.69.75.156])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TKkwXH017708;
	Fri, 29 Jun 2007 20:46:58 GMT
Message-ID: <46856FC2.90309@cisco.com>
Date: Fri, 29 Jun 2007 13:46:58 -0700
From: Mahesh Jethanandani 
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: John Heffner 
Subject: Re: [tcpm] New I-D
References: <20070221144454.3D3E01827FD@lawyers.icir.org>
	<45DCC9BB.4010302@psc.edu>
In-Reply-To: <45DCC9BB.4010302@psc.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1014; t=1183150019;
	x=1184014019; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mahesh@cisco.com;
	z=From:=20Mahesh=20Jethanandani=20
	|Subject:=20Re=3A=20[tcpm]=20New=20I-D |Sender:=20;
	bh=Ydu5QqQ6SicWEqMegLjxMCt4pjw9/nheew6toA58fTw=;
	b=VUi7MCxTHz8+FLPwufI9je4q4TUMKDFQ5gE/3tkdbVkH0MxzeTKv0EC9bhfxVeI4X0VU3P0/
	3QUp9WYmIHKtaZkAd3mBrbWc1dt+Rm0+qvo83CUTJoBBmiEj3/mxQtgO;
Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: tcpm@ietf.org, weddy@grc.nasa.gov, mallman@icir.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

Context is the draft - 
http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt

John Heffner wrote:
> As proof of concept, I wrote up a simple script (I think only about 30 
> lines of python) that used the TCP ESTATS MIB to monitor connections, 
> and kill off ones making no progress while consuming the most memory. 
> This proved an effective defense against netkill, and I think would 
> solve the problem described in the draft as well.  It would be easy 
> enough to write a kernel thread to do the same if the system doesn't 
> do ESTATS.
>
>   -John
John,

The issue with Netkill or any other application trying to kill 
connections is that they cannot distinguish between connections that are 
held up because of network issues where packets are getting dropped and 
connections that are in persist state because the client refuses to open 
the zero window. TCP can distinguish between the connections and 
determine which ones need to go. Wouldn't you agree?

m/

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm



From tcpm-bounces@ietf.org Fri Jun 29 22:30:26 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I4SjA-0004n8-88; Fri, 29 Jun 2007 22:30:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Sj9-0004gd-C8
	for tcpm@ietf.org; Fri, 29 Jun 2007 22:30:23 -0400
Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4Sj3-0004gi-CP
	for tcpm@ietf.org; Fri, 29 Jun 2007 22:30:23 -0400
Received: (qmail 11404 invoked from network); 30 Jun 2007 02:23:37 -0000
Received: from unknown (HELO ?192.168.1.5?)
	(janaiyengar@sbcglobal.net@76.214.41.150 with plain)
	by smtp103.sbc.mail.mud.yahoo.com with SMTP; 30 Jun 2007 02:23:35 -0000
X-YMail-OSG: PpTmbzMVM1kfO8mI_AoBJI0nainTz3nBeQxGGU5N0ATqCNY0rTSyCGWnZ7LEq6C0olKVBSFBuxSZznz0oUzHf.hcTXq0UpDkydo5uY_.O_7VPwqBg04-
Message-ID: <4685BEA0.8070705@mail.eecis.udel.edu>
Date: Fri, 29 Jun 2007 22:23:28 -0400
From: Janardhan Iyengar 
Organization: University of Delaware
User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509)
MIME-Version: 1.0
To: Sally Floyd 
Subject: Re: [tcpm] taking RFC 2861 (Congestion Window Validation) to Proposed
	Standard?
References: 	<46770412.8090307@psc.edu>
	<46ffa03042528d92a9ea2875e1764b19@mac.com>
In-Reply-To: <46ffa03042528d92a9ea2875e1764b19@mac.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: Murari Sridharan ,
	Jitu Padhye , tcpm ,
	Mark Handley 
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iyengar@cis.udel.edu
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: tcpm-bounces@ietf.org

Sally/all,

I'm not sure what it takes for an experimental RFC to go to proposed.

I'm generally happy enough with RFC 2861 to support it to go to Proposed 
Standard. But, if we do not know more (or enough) about the implications 
of CWV than we did when RFC2861 was published, on what basis do we 
recommend that it change status?

A show of hands by folks who know that it is used and has not caused 
complaints would also be very useful, IMHO.

- jana

Sally Floyd wrote:
> John -
> 
> (Apologies, as always, for the late reply.)
> 
>> There have been enough reports of performance problems with 
>> intrinsically bursty applications that an option was added to Linux to 
>> disable cwnd decay.  (It is still enabled by default.)  I'm not aware 
>> of any issues with the "not raising cwnd when application-limited" part.
> 
> I understand that bursty applications would often rather not reduce
> cwnd after an idle or application-limited periiod.  (It *might* be
> in their own interests, if it helps the flow to avoid unnecessary
> packet drops, but it *might not* be in their own interests, e.g.,
> if that flow doesn't receive any packet drops when bursting after
> an idle period.
> 
> But the following question also matters:
> 
> (1) What about when there are N possibly-bursty flows sharing the
> same congested link?  Are there any reports about whether the *N
> flows* do better when all flows use CWV, or whether they do better
> when none of them use CWV, and none of them reduce cwnd after an
> idle period?
> 
> (If there is no congestion, I would expect that the N flows do
> better without CWV.   If there *is* congestion, I would expect that
> the N flows in general do better *with* CWV, as opposed to not
> reducing cwnd after idle periods.  But it is not something that one
> could tell from reports from individual users...)
> 
> ------------------------------------------------------------------
> 
> The current Proposed Standard behavior in this area, from Section
> 4.1 of RFC 2581, says that TCP "SHOULD" reduce cwnd to the initial
> window after an idle period exceeding the RTO.  RFC 2861 is
> considerably more moderate than this.  Does anyone know if there
> are TCP implementations out there that follow the "SHOULD" from
> RFC 2581, just out of curiosity?
> 
> Is the feedback that the Congestion Window Validation mechanism in
> RFC 2861 should be modified?  Or that CWV is useful but is just
> fine to be left as Experimental?  (That would be fine by me.
> Less work...)
> 
> - Sally
> http://www.icir.org/floyd/
> 
> 
> Original email:
> 
>> Sally Floyd wrote:
>>> This email is to ask the working group if RFC 2861 on Congestion
>>> Window Validation (CWV) should be left at Experimental, or whether
>>> it is time to start the process of moving it to Proposed Standard.
>>> RFC 2861, from June 2000, "describes a simple modification to TCP's
>>> congestion control algorithms to decay the congestion window cwnd
>>> after the transition from a sufficiently-long application-limited
>>> period, while using the slow-start threshold ssthresh to save
>>> information about the previous value of the congestion window.
>>> RFC 2861 also recommends that "the TCP sender should not increase
>>> the congestion window when the TCP sender has been application-limited
>>> (and therefore has not fully used the current congestion window)".
>>> My understanding is that CWV has been included in Linux since
>>> Linux 2.4, but that it is not included in Microsoft.
>>> Are there any experience reports about CWV (positive or negative),
>>> or experience reports of problems (or the absence of problems) for
>>> TCP connections without CWV?  Or are there other opinions about
>>> whether it is time to start the process of moving RFC 2861 to
>>> Proposed Standard?  Any feedback would be welcome.
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm