From wesley.m.eddy@nasa.gov Tue Nov 3 12:17:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF103A6896 for ; Tue, 3 Nov 2009 12:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljm6FIOcBw5v for ; Tue, 3 Nov 2009 12:17:10 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id CB71C3A6885 for ; Tue, 3 Nov 2009 12:17:10 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id AA968A8431 for ; Tue, 3 Nov 2009 14:17:31 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nA3KHVh9014400 for ; Tue, 3 Nov 2009 14:17:31 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 3 Nov 2009 14:17:31 -0600 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: "tcpm@ietf.org" Date: Tue, 3 Nov 2009 14:17:30 -0600 Thread-Topic: Authentication Option Combined WGLC Thread-Index: Acpcwquw+lLELdIqRgi0F/BN2hujIw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-03_11:2009-10-29, 2009-11-03, 2009-11-03 signatures=0 Subject: [tcpm] Authentication Option Combined WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:17:11 -0000 David and I would like to start a combined Working Group Last Call on the two documents related to the TCP Authentication Option to be submitted for Proposed Standard: The TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt Cryptographic Algorithms for TCP's Authentication Option, TCP-AO http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt This WGLC will last 3 weeks, ending on November 24. Please submit comments the list. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From Donald.Smith@qwest.com Tue Nov 3 14:45:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1214F3A684E for ; Tue, 3 Nov 2009 14:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibT0fRs7VYM8 for ; Tue, 3 Nov 2009 14:45:54 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 06D7D3A682B for ; Tue, 3 Nov 2009 14:45:53 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id nA3MkEMe024484; Tue, 3 Nov 2009 16:46:14 -0600 (CST) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id nA3MjjKp022148; Tue, 3 Nov 2009 16:46:08 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 3 Nov 2009 15:46:00 -0700 From: "Smith, Donald" To: "'Eddy, Wesley M. (GRC-MS00)[Verizon]'" , "'tcpm@ietf.org'" Date: Tue, 3 Nov 2009 15:45:57 -0700 Thread-Topic: Authentication Option Combined WGLC Thread-Index: Acpcwquw+lLELdIqRgi0F/BN2hujIwAEx2WA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Authentication Option Combined WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:45:55 -0000 This makes TCP-AO of little value to protect against spoofed source resets = within the window size of the current Ack number. "TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets typically occur after peer crashes, either in response to new connection attempts or when data is sent on stale connections; in either case, the recovering endpoint may lack the connection key required (e.g., if lost during the crash). This may result in time- outs, rather than more responsive recovery after such a crash. As Touch Expires April 27, 2010 [Page 39] Internet-Draft The TCP Simple Authentication Option October 2009 noted in Section 7.2, such cases may also result in persistent TCP state for old connections that cannot be cleared, and so implementations should be capable of detecting an excess of such connections and clearing their state if needed to protect memory utilization [Ba09]." The BIGGEST problem with the current MD5 implementation isn't the algorithm= being used its the fact that implementers of BGP took the original md5 sta= tement about connection resets to mean they didn't have to send resets with= AUTH. It was an easy out for them and very few vendors do the lookups need= ed to do an authenticated reset if no connection state exists in their stat= e table. It is not hard for a bgp speaker to first check to see if a packet with src= _port or dst_port is 179 and coming from a neighbor. In cases where a non-i= nitial packet is coming from a neighbor if there is no current state for th= at connection the router has all the information needed (current packet plu= s M the shared key) to send an authenticated reset. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon] > Sent: Tuesday, November 03, 2009 1:18 PM > To: tcpm@ietf.org > Subject: [tcpm] Authentication Option Combined WGLC > > David and I would like to start a combined Working Group Last Call on > the two documents related to the TCP Authentication Option to be > submitted for Proposed Standard: > > The TCP Authentication Option > http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt > > Cryptographic Algorithms for TCP's Authentication Option, TCP-AO > http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > > > This WGLC will last 3 weeks, ending on November 24. Please submit > comments the list. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Tue Nov 3 15:25:59 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10953A6A5A for ; Tue, 3 Nov 2009 15:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg5p83ed89xf for ; Tue, 3 Nov 2009 15:25:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E6EA03A6936 for ; Tue, 3 Nov 2009 15:25:58 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA3NPrVt023873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 15:25:56 -0800 (PST) Message-ID: <4AF0BC00.9000809@isi.edu> Date: Tue, 03 Nov 2009 15:25:52 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Authentication Option Combined WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 23:26:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Smith, Donald wrote: > This makes TCP-AO of little value to protect against spoofed source > resets within the window size of the current Ack number. TCP-AO will drop spoofed resets, because the signature won't match. How is that not protected? (the note below focuses on connectionless resets, e.g., after a reboot, when state from previous connections - such as the ISNs on which the traffic keys are based - is lost.) > "TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets > typically occur after peer crashes, either in response to new > connection attempts or when data is sent on stale connections; in > either case, the recovering endpoint may lack the connection key > required (e.g., if lost during the crash). This may result in time- > outs, rather than more responsive recovery after such a crash. As > Touch Expires April 27, 2010 [Page 39] > Internet-Draft The TCP Simple Authentication Option October 2009 > noted in Section 7.2, such cases may also result in persistent TCP > state for old connections that cannot be cleared, and so > implementations should be capable of detecting an excess of such > connections and clearing their state if needed to protect memory > utilization [Ba09]." > > > The BIGGEST problem with the current MD5 implementation isn't the > algorithm being used its the fact that implementers of BGP took the > original md5 statement about connection resets to mean they didn't have > to send resets with AUTH. It was an easy out for them and very few > vendors do the lookups needed to do an authenticated reset if no > connection state exists in their state table. If you send resets without the AUTH, one of two things will be true: - - if the endpoint still thinks the connection is TCP-AO protected, it will drop the reset silently - - if the endpoint doesn't think the connection is TCP-AO protected, the reset will work as usual > It is not hard for a bgp speaker to first check to see if a packet > with src_port or dst_port is 179 and coming from a neighbor. In cases > where a non-initial packet is coming from a neighbor if there is no > current state for that connection the router has all the information > needed (current packet plus M the shared key) to send an authenticated > reset. That presumes it has the ISNs and the SNEs. Without those - e.g., after a reboot - the reset MUST be dropped if the connection remains protected. Such stale connections need to be cleaned up using out of band techniques (timer based garbage collection). Note that if you retain the ISNs and SNEs, as well as the MKTs - e.g., in persistent storage - then you can recover from a reboot and authenticate resets fine. Two questions: - - does this address your concern? - - if so, does the doc need to be updated to clarify? Joe >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon] >> Sent: Tuesday, November 03, 2009 1:18 PM >> To: tcpm@ietf.org >> Subject: [tcpm] Authentication Option Combined WGLC >> >> David and I would like to start a combined Working Group Last Call on >> the two documents related to the TCP Authentication Option to be >> submitted for Proposed Standard: >> >> The TCP Authentication Option >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt >> >> Cryptographic Algorithms for TCP's Authentication Option, TCP-AO >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt >> >> >> This WGLC will last 3 weeks, ending on November 24. Please submit >> comments the list. >> >> --------------------------- >> Wes Eddy >> Network & Systems Architect >> Verizon FNS / NASA GRC >> Office: (216) 433-6682 >> --------------------------- >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrwvAAACgkQE5f5cImnZrvglQCfcXPiB056c/qsqihAM4iTu/iF O4AAn19gXhiOTvdBeNbj87uyWA36eqFp =sRuk -----END PGP SIGNATURE----- From Donald.Smith@qwest.com Tue Nov 3 15:57:54 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EEF23A689A for ; Tue, 3 Nov 2009 15:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6p63N+cC4Zq for ; Tue, 3 Nov 2009 15:57:53 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id EBF753A6841 for ; Tue, 3 Nov 2009 15:57:52 -0800 (PST) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id nA3NwDUh021186; Tue, 3 Nov 2009 16:58:13 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id nA3Nw2Pn009802; Tue, 3 Nov 2009 17:58:07 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Tue, 3 Nov 2009 16:58:04 -0700 From: "Smith, Donald" To: "'Joe Touch'" Date: Tue, 3 Nov 2009 16:58:03 -0700 Thread-Topic: [tcpm] Authentication Option Combined WGLC Thread-Index: Acpc3Q9c/jntp5qJSyOaWdC/SMilTwAApQNA Message-ID: References: <4AF0BC00.9000809@isi.edu> In-Reply-To: <4AF0BC00.9000809@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Authentication Option Combined WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 23:57:54 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Tuesday, November 03, 2009 4:26 PM > To: Smith, Donald > Cc: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'tcpm@ietf.org' > Subject: Re: [tcpm] Authentication Option Combined WGLC > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Smith, Donald wrote: > > This makes TCP-AO of little value to protect against spoofed source > > resets within the window size of the current Ack number. > > TCP-AO will drop spoofed resets, because the signature won't > match. How > is that not protected? It will drop the spoofed resets and the connectionless resets too. Thus many ISPs will not enable it. > > (the note below focuses on connectionless resets, e.g., after > a reboot, > when state from previous connections - such as the ISNs on which the > traffic keys are based - is lost.) ISN may be lost but a keep alive or any other packet from your peer has all= the information you need excluding the shared secret. > > > "TCP-AO, like TCP MD5, may inhibit connectionless resets. > Such resets > > typically occur after peer crashes, either in response to new > > connection attempts or when data is sent on stale connections; in > > either case, the recovering endpoint may lack the connection key > > required (e.g., if lost during the crash). This may > result in time- > > outs, rather than more responsive recovery after such a crash. As > > Touch Expires April 27, 2010 > [Page 39] > > Internet-Draft The TCP Simple Authentication Option > October 2009 > > noted in Section 7.2, such cases may also result in > persistent TCP > > state for old connections that cannot be cleared, and so > > implementations should be capable of detecting an excess of such > > connections and clearing their state if needed to protect memory > > utilization [Ba09]." > > > > > > The BIGGEST problem with the current MD5 implementation isn't the > > algorithm being used its the fact that implementers of BGP took the > > original md5 statement about connection resets to mean they > didn't have > > to send resets with AUTH. It was an easy out for them and very few > > vendors do the lookups needed to do an authenticated reset if no > > connection state exists in their state table. > > If you send resets without the AUTH, one of two things will be true: > > - - if the endpoint still thinks the connection is TCP-AO > protected, it > will drop the reset silently In a connectionless reset it will think the end point is still protected. It has no way to know that the other end has rebooted/reset its bgp. > > - - if the endpoint doesn't think the connection is TCP-AO > protected, the > reset will work as usual > > > It is not hard for a bgp speaker to first check to see if a packet > > with src_port or dst_port is 179 and coming from a > neighbor. In cases > > where a non-initial packet is coming from a neighbor if there is no > > current state for that connection the router has all the information > > needed (current packet plus M the shared key) to send an > authenticated > > reset. > > That presumes it has the ISNs and the SNEs. Without those - > e.g., after > a reboot - the reset MUST be dropped if the connection remains It has them. They are in the next packet the bgp speaker that didn't reboot= /reset sends. There is even an AUTH so the rebooted bgp speaker "knows" this is coming fr= om a neighbor with AUTH enabled. > protected. Such stale connections need to be cleaned up using out of > band techniques (timer based garbage collection). > > Note that if you retain the ISNs and SNEs, as well as the MKTs - e.g., > in persistent storage - then you can recover from a reboot and > authenticate resets fine. > > Two questions: > > - - does this address your concern? If you mean storing ISN and SNE (along with MKTs which have to be stored in= persistent storage) this could address it but I don't think its required. The incoming keep alive or other traffic has all but the MKTs (shared secre= t). > > - - if so, does the doc need to be updated to clarify? > > Joe > > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > >> Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon] > >> Sent: Tuesday, November 03, 2009 1:18 PM > >> To: tcpm@ietf.org > >> Subject: [tcpm] Authentication Option Combined WGLC > >> > >> David and I would like to start a combined Working Group > Last Call on > >> the two documents related to the TCP Authentication Option to be > >> submitted for Proposed Standard: > >> > >> The TCP Authentication Option > >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt > >> > >> Cryptographic Algorithms for TCP's Authentication Option, TCP-AO > >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > >> > >> > >> This WGLC will last 3 weeks, ending on November 24. Please submit > >> comments the list. > >> > >> --------------------------- > >> Wes Eddy > >> Network & Systems Architect > >> Verizon FNS / NASA GRC > >> Office: (216) 433-6682 > >> --------------------------- > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >> > > > > This communication is the property of Qwest and may contain > confidential or > > privileged information. Unauthorized use of this > communication is strictly > > prohibited and may be unlawful. If you have received this > communication > > in error, please immediately notify the sender by reply > e-mail and destroy > > all copies of the communication and any attachments. > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAkrwvAAACgkQE5f5cImnZrvglQCfcXPiB056c/qsqihAM4iTu/iF > O4AAn19gXhiOTvdBeNbj87uyWA36eqFp > =3DsRuk > -----END PGP SIGNATURE----- > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From touch@ISI.EDU Tue Nov 3 17:26:06 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0AD3A6919 for ; Tue, 3 Nov 2009 17:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbU3zqAkx+OC for ; Tue, 3 Nov 2009 17:26:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3B57F3A6820 for ; Tue, 3 Nov 2009 17:26:05 -0800 (PST) Received: from [75.213.246.17] (17.sub-75-213-246.myvzw.com [75.213.246.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nA41Q94x020932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 17:26:12 -0800 (PST) Message-ID: <4AF0D830.8030206@isi.edu> Date: Tue, 03 Nov 2009 17:26:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Smith, Donald" References: <4AF0BC00.9000809@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] Authentication Option Combined WGLC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 01:26:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Donald, ... >> > Smith, Donald wrote: >>> > > This makes TCP-AO of little value to protect against spoofed source >>> > > resets within the window size of the current Ack number. >> > >> > TCP-AO will drop spoofed resets, because the signature won't >> > match. How >> > is that not protected? > > It will drop the spoofed resets and the connectionless resets too. That's the point - connectionless resets cannot be distinguished from spoofed ones. Either both are dropped - which is secure, but can cause buildup if endpoints restart frequently, or both are allowed - which is a security hole. > Thus many ISPs will not enable it. I don't see this as a configurable option. It's discussed, but IMO both MUST be dropped. >> > (the note below focuses on connectionless resets, e.g., after >> > a reboot, >> > when state from previous connections - such as the ISNs on which the >> > traffic keys are based - is lost.) > > ISN may be lost but a keep alive or any other packet from your peer > has all the information you need excluding the shared secret. The traffic key is computed using the ISN pair and the SNEs. Those are not available in-band - they're initialized at connection start (ISNs as exchanged, SNEs to 0) and maintained during the connection. They are not available in any segment information. ... >> > If you send resets without the AUTH, one of two things will be true: >> > >> > - - if the endpoint still thinks the connection is TCP-AO >> > protected, it >> > will drop the reset silently > > In a connectionless reset it will think the end point is still protected. > It has no way to know that the other end has rebooted/reset its bgp. The packets won't be ACKd - ever. There will be no RST. Eventually, TCP will time-out and close the connection, since it has data to send and the other end is failing to respond - see RFC 1122 Sec. 4.2.3.5. ... >> > That presumes it has the ISNs and the SNEs. Without those - >> > e.g., after >> > a reboot - the reset MUST be dropped if the connection remains > > It has them. They are in the next packet the bgp speaker that didn't reboot/reset sends. ISNs are sent during the SYN exchange only. They cannot be determined from other segments. SNEs are never sent on the wire, and the BGP speaker may know the SNEs for both ends, but there is no way to communicate this to the receiver. > There is even an AUTH so the rebooted bgp speaker "knows" this is coming from a neighbor with AUTH enabled. Yes, but it doesn't have sufficient information to calculate the traffic key needed to verify the segment, so the segment will be dropped before *any* action is taken (including 'knowing' whether the other side has AUTH enabled - that is on a per-connection basis only, and acting on *any* non-verified segment would pose a security hole). >> > protected. Such stale connections need to be cleaned up using out of >> > band techniques (timer based garbage collection). >> > >> > Note that if you retain the ISNs and SNEs, as well as the MKTs - e.g., >> > in persistent storage - then you can recover from a reboot and >> > authenticate resets fine. >> > >> > Two questions: >> > >> > - - does this address your concern? > > If you mean storing ISN and SNE (along with MKTs which have to be stored in persistent storage) > this could address it but I don't think its required. As per above, it seems to be. SNEs need to be updated when they increment too. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkrw2DAACgkQE5f5cImnZrsQAgCguUy84xA+wHEtOGKpL3c3PN4A NUIAnjSxL7T9FZasCNc2n93cvpI+5QGz =ekXX -----END PGP SIGNATURE----- From carsten.wolff@rwth-aachen.de Wed Nov 4 04:48:42 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738D93A68DD for ; Wed, 4 Nov 2009 04:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jnSG+WUQzHW for ; Wed, 4 Nov 2009 04:48:41 -0800 (PST) Received: from h1346787.stratoserver.net (h1346787.stratoserver.net [85.214.49.182]) by core3.amsl.com (Postfix) with ESMTP id 964DA3A683E for ; Wed, 4 Nov 2009 04:48:41 -0800 (PST) Received: from [137.226.12.96] (helo=latitude.localnet) by h1346787.stratoserver.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N5fIC-00012X-90; Wed, 04 Nov 2009 13:48:52 +0100 From: Carsten Wolff To: Matt Mathis Date: Wed, 4 Nov 2009 13:48:51 +0100 User-Agent: KMail/1.12.1 (Linux/2.6.29-1-686-latitude; KDE/4.3.2; i686; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200911041348.51548.carsten.wolff@rwth-aachen.de> X-IterationX-MailScanner-ID: 1N5fIC-00012X-90 X-IterationX-MailScanner: Found to be clean X-IterationX-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-IterationX-MailScanner-From: carsten.wolff@rwth-aachen.de Cc: tcpm Extensions WG Subject: [tcpm] Curiosity about draft-mathis-tcp-ratehalving X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 12:48:42 -0000 Hello Matt, everyone, I'm curious about draft-mathis-tcp-ratehalving (http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt) and why it never exceeded version 00 and expired years ago. It seems, several of the ideas (fack, ratehalving, the concept of rhcwnd) in this paper made it into the Linux TCP implementation in some form, which means they're part of a big chunk of today's web servers and other Internet hosts. Why has there been no interest in taking this draft further? Cheers, Carsten From rs@netapp.com Mon Nov 9 04:56:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1390A3A6B35 for ; Mon, 9 Nov 2009 04:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BHyGu0A8Nnj for ; Mon, 9 Nov 2009 04:56:49 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id E82053A6998 for ; Mon, 9 Nov 2009 04:56:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,708,1249282800"; d="scan'208";a="102977650" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 09 Nov 2009 04:57:11 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nA9CvBuR029136 for ; Mon, 9 Nov 2009 04:57:11 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 12:57:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 12:57:10 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A04B7BDD2@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) Thread-Index: AcpgvctD7c1gi066QDSC+UtyVkoUcAAeqhnQ From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 09 Nov 2009 12:57:11.0228 (UTC) FILETIME=[26E9F7C0:01CA613C] Subject: Re: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 12:56:51 -0000 Hi Alexander et al., This will be the first post to this group, so excuse me if I act = inappropriately. I'm curious about one little tidbit which has been bugging me for the = better part of the last two monts, and which is closely related with TCP = SACK operations (thus it might belong to this thread?) The implicit assumption for TCP fast recovery is, that packet loss = happens randomly (ie. to different segments each time) with low = correlation between the drop events. Also, a drop event is used as a = implicit signal to indicate congestion. So far, so good. It seems to me, that the focus of most developments has been the = internet environment - where statistical assumptions like the above = mentioned arguably hold true. However, certain high-speed LANs seem to exhibit characteristics, which = don't play well with these implicit assumptions (uncorrelated packet = loss) - the smaller the network, the more deviation from an "good = seasoned" link (exhibiting some form of congestion) is likely to occur. Also, as has been noted in prior research, many internet routers do use = more "tcp-friendly" RED or WRED queue policies, over the simplistic = TailDrop most often encountered in LANs (default policy of L2 switches = and L3 routers). In one extreme, I have found a (misbehaving=B4?) TCP stack/host, which = sends out a burst of segments (4-6) @ 10GbE wirespeed, which immediately = cause queue buffer overload and TailDrop in the first hop L2 Switch, = when two such high performance hosts try to establish a high speed = communication. With other words, the hosts themselves seem to make sure = that there is a high correlation between TCP (fast) recovery and further = packet loss. But what puzzles me the most - even with SACK enabled TCP stacks, = virtually no implementation can detect / act upon detection of the loss = of a retransmitted segment during fast recovery. This despite the fact, = that the stipulations in RFC3517 requires the receiver to make the = information to detect such an event implicitly available to the sender. = The first SACK option has to reflect the last segment, which triggered = this SACK.=20 Together with the scoreboard held at the sender, it should be rather = easy to find out if the left edge of the lowest hole (relative to stream = octets) closes. If that left edge stays constant for "DupThresh" number of ACKs, which = reduce the overall number of octets in holes (any one hole might close = due to the retransmitted packets still received), AND the sender = retransmits beginning with the lowest hole first, this would be a clear = indication of another segment retransmit loss... Even a less speedy detection logic would work for SACK-enabled sessions: = once the fast recovery is finished from the sender's point of view, if = the receiver still complains about missing segments (indicated by having = the SACK rightmost edge - in the first slot SACK option - at a segment = higher than when fast recovery started), another round of fast recovery = could be invoked, rather than waiting for RTO. Of course, the first approach would be better for low cwnd sessions with = only very few segments in transit - and both could be combined with the = proposed sack recovery speed-ups... (Reducing DupThresh for low cwnd = sessions / when little data is being sent). Congestion control should act to this event (it will now, but only one = RTO later...), and the SACK retransmit vector (HighRxt) reset, using = LimitedTransmit for sending out the retransmission segments - once cwnd = + pipe allows; any retransmitted segments still in the network will = close their respective SACK holes before the new HighRxt advances to = them. And, RTO should be reduce (I guess to nearly zero, between SACK-enabled = hosts). I have run numerous tests, to check the behavior of different TCP Stacks = (FreeBSD 4.2 - 8.0; windows xp, vista, 7, 2003; Linux 2.6.16 and = others). All these stacks seem to exhibit this issue; What I don't know yet is = the percentage of multi-loss segement events triggering RTO - but I = assume that the majority of RTOs happen because of this. In LAN environments (ie. 10 GbE over 1 km @ 2 ms latency due to the L2 = hops in between) featuring relatively few streams, the effect of any = single RTO can be quite tremendeous - taking considerable theoretical = bandwidth away from the session (ie. 1 sec minimum RTO equals 1.2 GB; = even with more recent RTO values around 0.2 - 0.4 sec, each RTO is still = a few hundred MB "lost" capacity under optimal circumstances. Nevertheless, I cann't imagine that I am the first one to bring up this = issue (despite having failed to find any study of this effect). :) One more clarification, which came up after I looked at the FreeBSD = implementation of Limited Transmit; this might be a nit-pick, but when = RFC 3042 is active, shouldn't ABC also be used during LimitedTransmit / = FastRecovery? (FreeBSD MAIN is increasing cwnd by 1 mss for each new = ACK, instead for the amount of data in that ack... Thanks a lot! Best regards, =20 Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com =20 Franz-Klein-Gasse 5 1190 Wien=20 * To: "tcpm at ietf.org WG Extensions" = > * Subject: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC = 3717 (SACK-TCP) * From: Alexander Zimmermann > * Date: Wed, 21 Oct 2009 12:22:50 +0200 _____ =20 Hi folks, based on the fact that the draft "draft-ietf-tcpm-sack-recovery-entry" = is adopted as WG item now and intended to be a "standards track" = document, I would like to start a poll/discussion whether the draft = should update RFC 3517 or not? Moreover, should we produce a separate = document or an update of RFC 3517?=20 a) separate document, do not update RFC 3517 b) separate document, update RFC 3517 c) RFC3517bis, obsolete RFC 3517 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann at cs.rwth-aachen.de // web: http://www.umic-mesh.net // From hannemann@i4.informatik.rwth-aachen.de Mon Nov 9 07:21:16 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939B93A6B14 for ; Mon, 9 Nov 2009 07:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQZ3NAQAd00A for ; Mon, 9 Nov 2009 07:21:15 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 9D18B3A6B75 for ; Mon, 9 Nov 2009 07:21:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSU0070GLC46MH0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 09 Nov 2009 16:21:40 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,708,1249250400"; d="scan'208";a="33056735" Received: from relay-2.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.75]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 09 Nov 2009 16:21:41 +0100 Received: from [137.226.12.85] (informatik-4-137-226-12-85.nn.RWTH-Aachen.DE [137.226.12.85] (may be forged)) by relay.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id nA9FLer8001750; Mon, 09 Nov 2009 16:21:40 +0100 (CET) Message-id: <4AF8336B.1050005@i4.informatik.rwth-aachen.de> Date: Mon, 09 Nov 2009 16:21:15 +0100 From: Arnd Hannemann User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: rs@netapp.com References: <5FDC413D5FA246468C200652D63E627A04B7BDD2@LDCMVEXC1-PRD.hq.netapp.com> In-reply-to: <5FDC413D5FA246468C200652D63E627A04B7BDD2@LDCMVEXC1-PRD.hq.netapp.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:21:16 -0000 Scheffenegger, Richard schrieb: > But what puzzles me the most - even with SACK enabled TCP stacks, virtually no > implementation can detect / act upon detection of the loss of a retransmitted > segment during fast recovery. This despite the fact, that the stipulations in > RFC3517 requires the receiver to make the information to detect such an event > implicitly available to the sender. The first SACK option has to reflect the > last segment, which triggered this SACK. Some implementations actually do detect lost retransmissions. (see Linux tcp_mark_lost_retrans()) However, currently only for FACK enabled flows. (Comments indicate, it would be non-trivial / too-expensive for SACK enabled flows.) > Together with the scoreboard held at the sender, it should be rather easy to > find out if the left edge of the lowest hole (relative to stream octets) closes > If that left edge stays constant for "DupThresh" number of ACKs, which reduce > the overall number of octets in holes (any one hole might close due to the > retransmitted packets still received), AND the sender retransmits beginning > with the lowest hole first, this would be a clear indication of another segment > retransmit loss... Sorry, I don't understand. You mean "DupThresh" number of DupACKs? Sack-blocks? After which point in time? After the first retransmit? SACK-blocks higher than recovery point? (the latter would make most sense, IMO) > Even a less speedy detection logic would work for SACK-enabled sessions: once > the fast recovery is finished from the sender's point of view, if the receiver > still complains about missing segments (indicated by having the SACK rightmost > edge - in the first slot SACK option - at a segment higher than when fast > recovery started), another round of fast recovery could be invoked, rather than > waiting for RTO. How can fast recovery be "finished" if the sender is missing packets? Best regards, Arnd Hannemann From alexander.zimmermann@nets.rwth-aachen.de Mon Nov 9 07:27:23 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD013A69A1 for ; Mon, 9 Nov 2009 07:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJW-xsUPCKyY for ; Mon, 9 Nov 2009 07:27:22 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id D98483A6B61 for ; Mon, 9 Nov 2009 07:27:15 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSU00EP0LM5LEF0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 09 Nov 2009 16:27:41 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,708,1249250400"; d="scan'208";a="33057856" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 09 Nov 2009 16:27:41 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSU00JNWLM5HI60@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 09 Nov 2009 16:27:41 +0100 (CET) From: Alexander Zimmermann Content-transfer-encoding: quoted-printable Date: Mon, 09 Nov 2009 16:27:42 +0100 Message-id: <2D6C2761-5FC9-46E3-95D4-FDE632D4469C@nets.rwth-aachen.de> To: Richard Scheffenegger X-Mailer: Apple Mail (2.1076) Cc: "tcpm@ietf.org Extensions WG" Subject: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:27:23 -0000 Hi Richard, firstly welcome on the list :-) Since your question in not really related to the poll I change the =20 title... Comments inline. Am 09.11.2009 um 13:57 schrieb Scheffenegger, Richard: > > > Hi Alexander et al., > > This will be the first post to this group, so excuse me if I act =20 > inappropriately. > > I'm curious about one little tidbit which has been bugging me for =20 > the better part of the last two monts, and which is closely related =20= > with TCP SACK operations (thus it might belong to this thread?) > > > The implicit assumption for TCP fast recovery is, that packet loss =20 > happens randomly (ie. to different segments each time) with low =20 > correlation between the drop events. Also, a drop event is used as a =20= > implicit signal to indicate congestion. So far, so good. > > It seems to me, that the focus of most developments has been the =20 > internet environment - where statistical assumptions like the above =20= > mentioned arguably hold true. > > However, certain high-speed LANs seem to exhibit characteristics, =20 > which don't play well with these implicit assumptions (uncorrelated =20= > packet loss) - the smaller the network, the more deviation from an =20 > "good seasoned" link (exhibiting some form of congestion) is likely =20= > to occur. > > Also, as has been noted in prior research, many internet routers do =20= > use more "tcp-friendly" RED or WRED queue policies, over the =20 > simplistic TailDrop most often encountered in LANs (default policy =20 > of L2 switches and L3 routers). > > In one extreme, I have found a (misbehaving=C2=B4?) TCP stack/host, = which =20 > sends out a burst of segments (4-6) @ 10GbE wirespeed, which =20 > immediately cause queue buffer overload and TailDrop in the first =20 > hop L2 Switch, when two such high performance hosts try to establish =20= > a high speed communication. With other words, the hosts themselves =20 > seem to make sure that there is a high correlation between TCP =20 > (fast) recovery and further packet loss. > > > But what puzzles me the most - even with SACK enabled TCP stacks, =20 > virtually no implementation can detect / act upon detection of the =20 > loss of a retransmitted segment during fast recovery. This despite =20 > the fact, that the stipulations in RFC3517 requires the receiver to =20= > make the information to detect such an event implicitly available to =20= > the sender. The first SACK option has to reflect the last segment, =20 > which triggered this SACK. > > Together with the scoreboard held at the sender, it should be rather =20= > easy to find out if the left edge of the lowest hole (relative to =20 > stream octets) closes. What do you with "left edge of the lowest hole"? Do you mean SND.UNA? =20= If ACK covers SND.UNA then it is an cumulative ACK. > > If that left edge stays constant for "DupThresh" number of ACKs, =20 > which reduce the overall number of octets in holes (any one hole =20 > might close due to the retransmitted packets still received), AND =20 > the sender retransmits beginning with the lowest hole first, this =20 > would be a clear indication of another segment retransmit loss... Sorry, I don't understand. If we have 20 segments in flight and one =20 segment gets lost, you will retransmit after 3 DUPACKS the oldest =20 outstanding segment. Then, assuming no reordering and no further lost, you will get 17 =20 DUPACKS (without Limited Transmit) before your hole is closed. What do I miss here? Can you give me an example? > > Even a less speedy detection logic would work for SACK-enabled =20 > sessions: once the fast recovery is finished from the sender's point =20= > of view, if the receiver still complains about missing segments =20 > (indicated by having the SACK rightmost edge - in the first slot =20 > SACK option - at a segment higher than when fast recovery started), =20= > another round of fast recovery could be invoked, rather than waiting =20= > for RTO. > > Of course, the first approach would be better for low cwnd sessions =20= > with only very few segments in transit - and both could be combined =20= > with the proposed sack recovery speed-ups... (Reducing DupThresh for =20= > low cwnd sessions / when little data is being sent). > > > > Congestion control should act to this event (it will now, but only =20 > one RTO later...), and the SACK retransmit vector (HighRxt) reset, =20 > using LimitedTransmit for sending out the retransmission segments - =20= > once cwnd + pipe allows; any retransmitted segments still in the =20 > network will close their respective SACK holes before the new =20 > HighRxt advances to them. > > And, RTO should be reduce (I guess to nearly zero, between SACK-=20 > enabled hosts). > > > I have run numerous tests, to check the behavior of different TCP =20 > Stacks (FreeBSD 4.2 - 8.0; windows xp, vista, 7, 2003; Linux 2.6.16 =20= > and others). > > > All these stacks seem to exhibit this issue; What I don't know yet =20 > is the percentage of multi-loss segement events triggering RTO - but =20= > I assume that the majority of RTOs happen because of this. > > In LAN environments (ie. 10 GbE over 1 km @ 2 ms latency due to the =20= > L2 hops in between) featuring relatively few streams, the effect of =20= > any single RTO can be quite tremendeous - taking considerable =20 > theoretical bandwidth away from the session (ie. 1 sec minimum RTO =20 > equals 1.2 GB; even with more recent RTO values around 0.2 - 0.4 =20 > sec, each RTO is still a few hundred MB "lost" capacity under =20 > optimal circumstances. > > > Nevertheless, I cann't imagine that I am the first one to bring up =20 > this issue (despite having failed to find any study of this =20 > effect). :) > > > One more clarification, which came up after I looked at the FreeBSD =20= > implementation of Limited Transmit; this might be a nit-pick, but =20 > when RFC 3042 is active, shouldn't ABC also be used during =20 > LimitedTransmit / FastRecovery? Why? One reason for ABC are lying receivers (ACK Division). So, the =20 worst case is Slow-Start... > (FreeBSD MAIN is increasing cwnd by 1 mss for each new ACK, instead =20= > for the amount of data in that ack... What do you describe here? Slow-Start? RFC 3042 says: "The congestion window (cwnd) MUST NOT be changed when =20= these new segments are transmitted." > > Thanks a lot! > > > Best regards, Alex > > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > * To: "tcpm at ietf.org WG = Extensions" =20 > > > * Subject: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry = update =20 > RFC 3717 (SACK-TCP) > * From: Alexander Zimmermann > > * Date: Wed, 21 Oct 2009 12:22:50 +0200 > > _____ > > Hi folks, > > based on the fact that the draft "draft-ietf-tcpm-sack-recovery-=20 > entry" is adopted as WG item now and intended to be a "standards =20 > track" document, I would like to start a poll/discussion whether the =20= > draft should update RFC 3517 or not? Moreover, should we produce a =20 > separate document or an update of RFC 3517? > > a) separate document, do not update RFC 3517 > b) separate document, update RFC 3517 > c) RFC3517bis, obsolete RFC 3517 > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann at cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From rs@netapp.com Mon Nov 9 09:27:18 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC063A67B2 for ; Mon, 9 Nov 2009 09:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_7x5=0.8, SARE_BAYES_8x5=0.8, SARE_BAYES_9x5=1.2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfmpoTJLvWBj for ; Mon, 9 Nov 2009 09:27:16 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id EC2253A6403 for ; Mon, 9 Nov 2009 09:27:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,710,1249282800"; d="scan'208";a="103030348" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 09 Nov 2009 09:27:40 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nA9HRe2C002658; Mon, 9 Nov 2009 09:27:40 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 17:27:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 17:27:10 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A06491679@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detect Lost Retransmit with SACK Thread-Index: AcphUPVmAHvrINqeQEyz/nm2u8XmcwACuYPg From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 09 Nov 2009 17:27:40.0159 (UTC) FILETIME=[F01C50F0:01CA6161] Cc: tcpm@ietf.org Subject: Re: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:27:18 -0000 Hi Alexander,=20 Thanks for the welcome :)=20 I fork another thread with the LimitedTransport||FastRecovery / ABC = interaction... I will try to sketch up an example to demonstrate what problem I'm = trying to address: Let's assume the cwnd is already open for at least 7 segments, before = the segment with sequence number 10000 is the first one to be dropped by the network. Also, let's assume that FastRetransmit runs from the left edge of the = leftmost hole=20 (SND.UNA) upwards, and that per ACK only a single segment is sent.=20 =20 Triggering ACK Left Right Left Right Segment Edge 1 Edge 1 Edge 2 Edge 2 9000 9000 10000 (lost) * 11000 (lost) 12000 (lost) 13000 (lost) 14000 (lost) 15000 10000 15000 16000 16000 10000 15000 17000 17000 10000 15000 18000 3 ACKs trigger fast retransmit 10000 (lost again)=20 11000 10000 11000 12000 15000 18000 12000 10000 11000 13000 15000 18000 13000 10000 11000 14000 15000 18000 -> here we have again 3 ACKs indicating a another loss of one of the = retransmitted=20 packets. The leftmost hole did not change, while the overall number of = SACKed octets did decrease for 3 consecutive ACKs (4; 3 and 2 segments marked = by SACK). Current behaviour of investigated TCP Stacks: 14000 10000 11000 18000 (normal transmit resumes) 18000 10000 11000 19000 19000 10000 11000 20000 20000 10000 11000 21000 21000 10000 11000 22000 22000 10000 11000 23000 :: :: :: :: Eventually, RTO trips off, retransmitting the lost segment; this happens = RTO later, followed by slow-start... 50000 10000 11000 50000 :: :: 10000 50000 However, this can be somewhere between 0.2 and 1.0 sec later with a = "fresh" TCP=20 session (no prior connection properties known (cached) by sender). Most = likely, the cwnd has filled up already way sooner (as demonstated, the problem = seems to be most prominent in Highspeed LANs), so that for nearly as long, no data = is actually transmitted. =20 Proposed behaviour:=20 Triggering ACK Left Right Left Right Segment Edge 1 Edge 1 Edge 2 Edge 2 9000 9000 10000 (lost) * 11000 (lost) 12000 (lost) 13000 (lost) 14000 (lost) 15000 10000 15000 16000 16000 10000 15000 17000 17000 10000 15000 18000 3 ACKs trigger fast retransmit 10000 (lost again) * 11000 10000 11000 12000 15000 18000 12000 10000 11000 13000 15000 18000 13000 10000 11000 14000 15000 18000 Once the ACK + SACK options indicate that the leftmost hole is not = shrinking, while the SACKed octets are increasing (to deal with clients which send = one=20 retransmission segment and one new segment interspaced, or when multiple = holes exist which are being filled, or when network reordering occurs, or when = some=20 wore segments get lost again):=20 Reset the Rexmit vector to the beginning of the Hole-List (SND.UNA), = clear counter to count duplicates (just in case one segment gets lost again = during retransmit), and keep the DUPACK detection logic armed... Also, this reaction should not occur before 1 RTT - so ACKs subsequent = to the=20 three which indicated the "lost again" segment will take care (in the = typical case) that no segments are retransmitted needlessly. ACK processing has to = occur before deciding which segment (retransmit / new) to send next. Holes will then = be marked=20 fully retransmitted, before the 2nd retransmission round would advance = to them). 10000 14000 15000 18000 14000 18000 (normal transmit resumes, but with cwnd shrunk by 2 congestion events) 18000 19000 19000 20000 And yes, I was unclear with the use of the terminology; I should have = probably=20 stated "pipe" instead of "cwnd" below, as cwnd is not touched during = LimitedTransmit / FastRetransmit... Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Alexander Zimmermann [mailto:zimmermann@nets.rwth-aachen.de]=20 Sent: Montag, 9. November 2009 16:26 To: Scheffenegger, Richard Cc: tcpm@ietf.org Extensions WG Subject: Detect Lost Retransmit with SACK Hi Richard, firstly welcome on the list :-) Since your question in not really related to the poll I change the = title... Comments inline. Am 09.11.2009 um 13:57 schrieb Scheffenegger, Richard: > > > Hi Alexander et al., > > This will be the first post to this group, so excuse me if I act=20 > inappropriately. > > I'm curious about one little tidbit which has been bugging me for the=20 > better part of the last two monts, and which is closely related with=20 > TCP SACK operations (thus it might belong to this thread?) > > > The implicit assumption for TCP fast recovery is, that packet loss =20 > happens randomly (ie. to different segments each time) with low =20 > correlation between the drop events. Also, a drop event is used as a =20 > implicit signal to indicate congestion. So far, so good. > > It seems to me, that the focus of most developments has been the =20 > internet environment - where statistical assumptions like the above =20 > mentioned arguably hold true. > > However, certain high-speed LANs seem to exhibit characteristics, =20 > which don't play well with these implicit assumptions (uncorrelated =20 > packet loss) - the smaller the network, the more deviation from an =20 > "good seasoned" link (exhibiting some form of congestion) is likely =20 > to occur. > > Also, as has been noted in prior research, many internet routers do =20 > use more "tcp-friendly" RED or WRED queue policies, over the =20 > simplistic TailDrop most often encountered in LANs (default policy =20 > of L2 switches and L3 routers). > > In one extreme, I have found a (misbehaving=B4?) TCP stack/host, which = =20 > sends out a burst of segments (4-6) @ 10GbE wirespeed, which =20 > immediately cause queue buffer overload and TailDrop in the first =20 > hop L2 Switch, when two such high performance hosts try to establish =20 > a high speed communication. With other words, the hosts themselves =20 > seem to make sure that there is a high correlation between TCP =20 > (fast) recovery and further packet loss. > > > But what puzzles me the most - even with SACK enabled TCP stacks, =20 > virtually no implementation can detect / act upon detection of the =20 > loss of a retransmitted segment during fast recovery. This despite =20 > the fact, that the stipulations in RFC3517 requires the receiver to =20 > make the information to detect such an event implicitly available to =20 > the sender. The first SACK option has to reflect the last segment, =20 > which triggered this SACK. > > Together with the scoreboard held at the sender, it should be rather =20 > easy to find out if the left edge of the lowest hole (relative to =20 > stream octets) closes. What do you with "left edge of the lowest hole"? Do you mean SND.UNA? =20 If ACK covers SND.UNA then it is an cumulative ACK. > > If that left edge stays constant for "DupThresh" number of ACKs, =20 > which reduce the overall number of octets in holes (any one hole =20 > might close due to the retransmitted packets still received), AND =20 > the sender retransmits beginning with the lowest hole first, this =20 > would be a clear indication of another segment retransmit loss... Sorry, I don't understand. If we have 20 segments in flight and one =20 segment gets lost, you will retransmit after 3 DUPACKS the oldest =20 outstanding segment. Then, assuming no reordering and no further lost, you will get 17 =20 DUPACKS (without Limited Transmit) before your hole is closed. What do I miss here? Can you give me an example? > > Even a less speedy detection logic would work for SACK-enabled =20 > sessions: once the fast recovery is finished from the sender's point =20 > of view, if the receiver still complains about missing segments =20 > (indicated by having the SACK rightmost edge - in the first slot =20 > SACK option - at a segment higher than when fast recovery started), =20 > another round of fast recovery could be invoked, rather than waiting =20 > for RTO. > > Of course, the first approach would be better for low cwnd sessions =20 > with only very few segments in transit - and both could be combined =20 > with the proposed sack recovery speed-ups... (Reducing DupThresh for =20 > low cwnd sessions / when little data is being sent). > > > > Congestion control should act to this event (it will now, but only =20 > one RTO later...), and the SACK retransmit vector (HighRxt) reset, =20 > using LimitedTransmit for sending out the retransmission segments - =20 > once cwnd + pipe allows; any retransmitted segments still in the =20 > network will close their respective SACK holes before the new =20 > HighRxt advances to them. > > And, RTO should be reduce (I guess to nearly zero, between SACK-=20 > enabled hosts). > > > I have run numerous tests, to check the behavior of different TCP =20 > Stacks (FreeBSD 4.2 - 8.0; windows xp, vista, 7, 2003; Linux 2.6.16 =20 > and others). > > > All these stacks seem to exhibit this issue; What I don't know yet =20 > is the percentage of multi-loss segement events triggering RTO - but =20 > I assume that the majority of RTOs happen because of this. > > In LAN environments (ie. 10 GbE over 1 km @ 2 ms latency due to the =20 > L2 hops in between) featuring relatively few streams, the effect of =20 > any single RTO can be quite tremendeous - taking considerable =20 > theoretical bandwidth away from the session (ie. 1 sec minimum RTO =20 > equals 1.2 GB; even with more recent RTO values around 0.2 - 0.4 =20 > sec, each RTO is still a few hundred MB "lost" capacity under =20 > optimal circumstances. > > > Nevertheless, I cann't imagine that I am the first one to bring up =20 > this issue (despite having failed to find any study of this =20 > effect). :) > > > One more clarification, which came up after I looked at the FreeBSD =20 > implementation of Limited Transmit; this might be a nit-pick, but =20 > when RFC 3042 is active, shouldn't ABC also be used during =20 > LimitedTransmit / FastRecovery? Why? One reason for ABC are lying receivers (ACK Division). So, the =20 worst case is Slow-Start... > (FreeBSD MAIN is increasing cwnd by 1 mss for each new ACK, instead =20 > for the amount of data in that ack... What do you describe here? Slow-Start? RFC 3042 says: "The congestion window (cwnd) MUST NOT be changed when =20 these new segments are transmitted." > > Thanks a lot! > > > Best regards, Alex > > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > * To: "tcpm at ietf.org WG Extensions" =20 > > > * Subject: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update =20 > RFC 3717 (SACK-TCP) > * From: Alexander Zimmermann > > * Date: Wed, 21 Oct 2009 12:22:50 +0200 > > _____ > > Hi folks, > > based on the fact that the draft "draft-ietf-tcpm-sack-recovery-=20 > entry" is adopted as WG item now and intended to be a "standards =20 > track" document, I would like to start a poll/discussion whether the =20 > draft should update RFC 3517 or not? Moreover, should we produce a =20 > separate document or an update of RFC 3517? > > a) separate document, do not update RFC 3517 > b) separate document, update RFC 3517 > c) RFC3517bis, obsolete RFC 3517 > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann at cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From rs@netapp.com Mon Nov 9 09:37:35 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A623A698E for ; Mon, 9 Nov 2009 09:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnEMB6Lm6+z2 for ; Mon, 9 Nov 2009 09:37:34 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id BD68E3A6945 for ; Mon, 9 Nov 2009 09:37:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,710,1249282800"; d="scan'208";a="113327567" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 09 Nov 2009 09:37:59 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nA9HbwOU003479; Mon, 9 Nov 2009 09:37:59 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 17:37:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 17:37:29 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A06491683@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LimitedTransport||FastRecovery / ABC interaction Thread-Index: AcphUPVmAHvrINqeQEyz/nm2u8XmcwAEP/Jg From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 09 Nov 2009 17:37:58.0971 (UTC) FILETIME=[60F388B0:01CA6163] Cc: tcpm@ietf.org Subject: [tcpm] LimitedTransport||FastRecovery / ABC interaction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:37:35 -0000 [removed other thread stuff] Alex, Again the scenario where the sender is in FastRetransmit or LimitedTransmit=20 mode, following a congestion (drop) event. Shouldn't a sender, fully honoring RFC 3042, increase the pipe only by the amount=20 of newly ACKed / SACKed octets, rather then increasing the pipe by 1*mss per received ACK? If the sender has a decent cwnd, and a misbehaving (not to say lying) receiver all of a sudden sends individual SACKs, ACKing one more octet, and SACKing every other octet, each in an individual ACK. This might lure the sender to bloat it's (retransmission / limited transmit) pipe to become much larger than cwnd (I'm not sure if all implementations limit the pipe to min(cwnd, pipe).... But really, I think this is mostly a nit-pick; worst case would be a burst of traffic, potentially causing momentarily queue overflows in the network, and=20 (lot's) of retransmissions... But that later part should be better, when bursty loss can be dealt with better :) Regards, =20 Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Alexander Zimmermann [mailto:zimmermann@nets.rwth-aachen.de]=20 Sent: Montag, 9. November 2009 16:26 To: Scheffenegger, Richard Cc: tcpm@ietf.org Extensions WG Subject: Detect Lost Retransmit with SACK Hi Richard, firstly welcome on the list :-) Since your question in not really related to the poll I change the title... Comments inline. Am 09.11.2009 um 13:57 schrieb Scheffenegger, Richard: > > One more clarification, which came up after I looked at the FreeBSD =20 > implementation of Limited Transmit; this might be a nit-pick, but =20 > when RFC 3042 is active, shouldn't ABC also be used during =20 > LimitedTransmit / FastRecovery? Why? One reason for ABC are lying receivers (ACK Division). So, the =20 worst case is Slow-Start... > (FreeBSD MAIN is increasing cwnd by 1 mss for each new ACK, instead =20 > for the amount of data in that ack... What do you describe here? Slow-Start? RFC 3042 says: "The congestion window (cwnd) MUST NOT be changed when =20 these new segments are transmitted." > > Thanks a lot! > > > Best regards, Alex From rs@netapp.com Mon Nov 9 10:06:02 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6B23A6916 for ; Mon, 9 Nov 2009 10:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.232 X-Spam-Level: X-Spam-Status: No, score=-4.232 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_7x5=0.8, SARE_BAYES_8x5=0.8, SARE_BAYES_9x5=1.2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCssxJKtCU+m for ; Mon, 9 Nov 2009 10:06:00 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 13D3C3A67B2 for ; Mon, 9 Nov 2009 10:05:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,710,1249282800"; d="scan'208";a="103035994" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 09 Nov 2009 10:06:24 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nA9I6OBw005579; Mon, 9 Nov 2009 10:06:24 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:06:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 18:05:53 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0649169F@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A06491679@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Detect Lost Retransmit with SACK Thread-Index: AcphUPVmAHvrINqeQEyz/nm2u8XmcwACuYPgAAHdeFA= From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 09 Nov 2009 18:06:25.0018 (UTC) FILETIME=[59D5A5A0:01CA6167] Cc: tcpm@ietf.org Subject: Re: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:06:02 -0000 Hi group, I forgot to mention the actual testing scenario I was doing, to profile = all these TCP stack against. Basically, I used a userland TCP "forging" tool, where each frame can be = individually crafted (content, timing, loss). My test opens a tcp session (http get request, for simplicity's sake), = with SACK=20 negotiated and then counts the segments being received, behaving = (mostly) like a=20 well-behaving TCP client. However, the segments with these numbers: 200, 250, 253, 255, 257, 258, 259, 260, 265, 267 are dropped this number of times they are seen in the stream: 1, 1, 1, 1, 1, 2, 1, 1, 1, 1 =20 The grace period of 200 packets is to have a decently wide open cwnd; = the drop at Segment 200 also serves to check if the cwnd is larger than 50 segments = when the Burst drop (250-267) occurs, and also to "prime" the SACK scoreboard = (preventing the sender from fastpathing). The burst in this case is in the time axis = and, with segment number 258, sequence space axis... None of the TCP Stacks I have investigated so far, were able to recover = without a RTO (between 0.2 and 1 sec later; Windows 7 was particularly peculiar, = as it starts shifting the original segments after the 2nd or 3rd dropped = segment; it seems to retransmit 1/2 1 1 1 1/2 segments if a contingeous hole > 1 = segment is being announced by SACK... :) But my code still drops the one = containing the 258th sequence number again, leading even Win7 to a RTO... And, on another front, I have checked a few systems in the field (our = gear Is run typically in high-speed (1/10 Gbps) LANs; I found one example = where Nearly 50% of the retransmissions where followed by a RTO, and even the Less loaded systems showed a quite high number of RTOs (15-35%) after Retransmissions. I assume at this point, that only a minority of the RTOs is "legitimate" = in=20 the sense that=20 *) TCP Session is not running with SACK *) Client was forcefully removed from the network (loss of connectivity) Which leaves probably between 70 and 95% or the RTO events as "burst = loss" candidates, where keeping the DUPACK detection armed during = FastRetransmit would help. I will see to it, that I get statistically more relevant data, and also Put this into context (i.e. total segments transmitted per week vs. = total=20 retransmitted segments per week vs. retransmit timeout events per week). (Actually, I got scared at first, when I saw that high-load system = reporting=20 50% of all retransmissions are followed by RTOs... :) ). Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Scheffenegger, Richard=20 Sent: Montag, 9. November 2009 18:27 To: Alexander Zimmermann Cc: tcpm@ietf.org Subject: Re: [tcpm] Detect Lost Retransmit with SACK Hi Alexander,=20 Thanks for the welcome :)=20 I fork another thread with the LimitedTransport||FastRecovery / ABC = interaction... I will try to sketch up an example to demonstrate what problem I'm = trying to address: Let's assume the cwnd is already open for at least 7 segments, before = the segment with sequence number 10000 is the first one to be dropped by = the network. Also, let's assume that FastRetransmit runs from the left edge of the = leftmost hole (SND.UNA) upwards, and that per ACK only a single segment is sent.=20 =20 Triggering ACK Left Right Left Right Segment Edge 1 Edge 1 Edge 2 Edge 2 9000 9000 10000 (lost) * 11000 (lost) 12000 (lost) 13000 (lost) 14000 (lost) 15000 10000 15000 16000 16000 10000 15000 17000 17000 10000 15000 18000 3 ACKs trigger fast retransmit 10000 (lost again)=20 11000 10000 11000 12000 15000 18000 12000 10000 11000 13000 15000 18000 13000 10000 11000 14000 15000 18000 -> here we have again 3 ACKs indicating a another loss of one of the = retransmitted=20 packets. The leftmost hole did not change, while the overall number of = SACKed octets did decrease for 3 consecutive ACKs (4; 3 and 2 segments marked = by SACK). Current behaviour of investigated TCP Stacks: 14000 10000 11000 18000 (normal transmit resumes) 18000 10000 11000 19000 19000 10000 11000 20000 20000 10000 11000 21000 21000 10000 11000 22000 22000 10000 11000 23000 :: :: :: :: Eventually, RTO trips off, retransmitting the lost segment; this happens = RTO later, followed by slow-start... 50000 10000 11000 50000 :: :: 10000 50000 However, this can be somewhere between 0.2 and 1.0 sec later with a = "fresh" TCP=20 session (no prior connection properties known (cached) by sender). Most = likely, the cwnd has filled up already way sooner (as demonstated, the problem = seems to be most prominent in Highspeed LANs), so that for nearly as long, no data = is actually transmitted. =20 Proposed behaviour:=20 Triggering ACK Left Right Left Right Segment Edge 1 Edge 1 Edge 2 Edge 2 9000 9000 10000 (lost) * 11000 (lost) 12000 (lost) 13000 (lost) 14000 (lost) 15000 10000 15000 16000 16000 10000 15000 17000 17000 10000 15000 18000 3 ACKs trigger fast retransmit 10000 (lost again) * 11000 10000 11000 12000 15000 18000 12000 10000 11000 13000 15000 18000 13000 10000 11000 14000 15000 18000 Once the ACK + SACK options indicate that the leftmost hole is not = shrinking, while the SACKed octets are increasing (to deal with clients which send = one=20 retransmission segment and one new segment interspaced, or when multiple = holes exist which are being filled, or when network reordering occurs, or when = some=20 wore segments get lost again):=20 Reset the Rexmit vector to the beginning of the Hole-List (SND.UNA), = clear counter to count duplicates (just in case one segment gets lost again = during retransmit), and keep the DUPACK detection logic armed... Also, this reaction should not occur before 1 RTT - so ACKs subsequent = to the=20 three which indicated the "lost again" segment will take care (in the = typical case) that no segments are retransmitted needlessly. ACK processing has to = occur before deciding which segment (retransmit / new) to send next. Holes will then = be marked=20 fully retransmitted, before the 2nd retransmission round would advance = to them). 10000 14000 15000 18000 14000 18000 (normal transmit resumes, but with cwnd shrunk by 2 congestion events) 18000 19000 19000 20000 And yes, I was unclear with the use of the terminology; I should have = probably=20 stated "pipe" instead of "cwnd" below, as cwnd is not touched during = LimitedTransmit / FastRetransmit... Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Alexander Zimmermann [mailto:zimmermann@nets.rwth-aachen.de]=20 Sent: Montag, 9. November 2009 16:26 To: Scheffenegger, Richard Cc: tcpm@ietf.org Extensions WG Subject: Detect Lost Retransmit with SACK Hi Richard, firstly welcome on the list :-) Since your question in not really related to the poll I change the = title... Comments inline. Am 09.11.2009 um 13:57 schrieb Scheffenegger, Richard: > > > Hi Alexander et al., > > This will be the first post to this group, so excuse me if I act=20 > inappropriately. > > I'm curious about one little tidbit which has been bugging me for the=20 > better part of the last two monts, and which is closely related with=20 > TCP SACK operations (thus it might belong to this thread?) > > > The implicit assumption for TCP fast recovery is, that packet loss =20 > happens randomly (ie. to different segments each time) with low =20 > correlation between the drop events. Also, a drop event is used as a =20 > implicit signal to indicate congestion. So far, so good. > > It seems to me, that the focus of most developments has been the =20 > internet environment - where statistical assumptions like the above =20 > mentioned arguably hold true. > > However, certain high-speed LANs seem to exhibit characteristics, =20 > which don't play well with these implicit assumptions (uncorrelated =20 > packet loss) - the smaller the network, the more deviation from an =20 > "good seasoned" link (exhibiting some form of congestion) is likely =20 > to occur. > > Also, as has been noted in prior research, many internet routers do =20 > use more "tcp-friendly" RED or WRED queue policies, over the =20 > simplistic TailDrop most often encountered in LANs (default policy =20 > of L2 switches and L3 routers). > > In one extreme, I have found a (misbehaving=B4?) TCP stack/host, which = =20 > sends out a burst of segments (4-6) @ 10GbE wirespeed, which =20 > immediately cause queue buffer overload and TailDrop in the first =20 > hop L2 Switch, when two such high performance hosts try to establish =20 > a high speed communication. With other words, the hosts themselves =20 > seem to make sure that there is a high correlation between TCP =20 > (fast) recovery and further packet loss. > > > But what puzzles me the most - even with SACK enabled TCP stacks, =20 > virtually no implementation can detect / act upon detection of the =20 > loss of a retransmitted segment during fast recovery. This despite =20 > the fact, that the stipulations in RFC3517 requires the receiver to =20 > make the information to detect such an event implicitly available to =20 > the sender. The first SACK option has to reflect the last segment, =20 > which triggered this SACK. > > Together with the scoreboard held at the sender, it should be rather =20 > easy to find out if the left edge of the lowest hole (relative to =20 > stream octets) closes. What do you with "left edge of the lowest hole"? Do you mean SND.UNA? =20 If ACK covers SND.UNA then it is an cumulative ACK. > > If that left edge stays constant for "DupThresh" number of ACKs, =20 > which reduce the overall number of octets in holes (any one hole =20 > might close due to the retransmitted packets still received), AND =20 > the sender retransmits beginning with the lowest hole first, this =20 > would be a clear indication of another segment retransmit loss... Sorry, I don't understand. If we have 20 segments in flight and one =20 segment gets lost, you will retransmit after 3 DUPACKS the oldest =20 outstanding segment. Then, assuming no reordering and no further lost, you will get 17 =20 DUPACKS (without Limited Transmit) before your hole is closed. What do I miss here? Can you give me an example? > > Even a less speedy detection logic would work for SACK-enabled =20 > sessions: once the fast recovery is finished from the sender's point =20 > of view, if the receiver still complains about missing segments =20 > (indicated by having the SACK rightmost edge - in the first slot =20 > SACK option - at a segment higher than when fast recovery started), =20 > another round of fast recovery could be invoked, rather than waiting =20 > for RTO. > > Of course, the first approach would be better for low cwnd sessions =20 > with only very few segments in transit - and both could be combined =20 > with the proposed sack recovery speed-ups... (Reducing DupThresh for =20 > low cwnd sessions / when little data is being sent). > > > > Congestion control should act to this event (it will now, but only =20 > one RTO later...), and the SACK retransmit vector (HighRxt) reset, =20 > using LimitedTransmit for sending out the retransmission segments - =20 > once cwnd + pipe allows; any retransmitted segments still in the =20 > network will close their respective SACK holes before the new =20 > HighRxt advances to them. > > And, RTO should be reduce (I guess to nearly zero, between SACK-=20 > enabled hosts). > > > I have run numerous tests, to check the behavior of different TCP =20 > Stacks (FreeBSD 4.2 - 8.0; windows xp, vista, 7, 2003; Linux 2.6.16 =20 > and others). > > > All these stacks seem to exhibit this issue; What I don't know yet =20 > is the percentage of multi-loss segement events triggering RTO - but =20 > I assume that the majority of RTOs happen because of this. > > In LAN environments (ie. 10 GbE over 1 km @ 2 ms latency due to the =20 > L2 hops in between) featuring relatively few streams, the effect of =20 > any single RTO can be quite tremendeous - taking considerable =20 > theoretical bandwidth away from the session (ie. 1 sec minimum RTO =20 > equals 1.2 GB; even with more recent RTO values around 0.2 - 0.4 =20 > sec, each RTO is still a few hundred MB "lost" capacity under =20 > optimal circumstances. > > > Nevertheless, I cann't imagine that I am the first one to bring up =20 > this issue (despite having failed to find any study of this =20 > effect). :) > > > One more clarification, which came up after I looked at the FreeBSD =20 > implementation of Limited Transmit; this might be a nit-pick, but =20 > when RFC 3042 is active, shouldn't ABC also be used during =20 > LimitedTransmit / FastRecovery? Why? One reason for ABC are lying receivers (ACK Division). So, the =20 worst case is Slow-Start... > (FreeBSD MAIN is increasing cwnd by 1 mss for each new ACK, instead =20 > for the amount of data in that ack... What do you describe here? Slow-Start? RFC 3042 says: "The congestion window (cwnd) MUST NOT be changed when =20 these new segments are transmitted." > > Thanks a lot! > > > Best regards, Alex > > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > * To: "tcpm at ietf.org WG Extensions" =20 > > > * Subject: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update =20 > RFC 3717 (SACK-TCP) > * From: Alexander Zimmermann > > * Date: Wed, 21 Oct 2009 12:22:50 +0200 > > _____ > > Hi folks, > > based on the fact that the draft "draft-ietf-tcpm-sack-recovery-=20 > entry" is adopted as WG item now and intended to be a "standards =20 > track" document, I would like to start a poll/discussion whether the =20 > draft should update RFC 3517 or not? Moreover, should we produce a =20 > separate document or an update of RFC 3517? > > a) separate document, do not update RFC 3517 > b) separate document, update RFC 3517 > c) RFC3517bis, obsolete RFC 3517 > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann at cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Mon Nov 9 11:39:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBD03A68C1 for ; Mon, 9 Nov 2009 11:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.674 X-Spam-Level: X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBSxcDhndkp9 for ; Mon, 9 Nov 2009 11:39:47 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 82C2E28C23B for ; Mon, 9 Nov 2009 11:39:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,711,1249282800"; d="scan'208";a="103048909" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 09 Nov 2009 11:39:47 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nA9JdlBs012350; Mon, 9 Nov 2009 11:39:47 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:39:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 19:39:17 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A064916CA@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4AF8336B.1050005@i4.informatik.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) Thread-Index: AcphUFwankudnmboRwSABGd1Or8yBAAF0r2g From: "Scheffenegger, Richard" To: "Arnd Hannemann" X-OriginalArrivalTime: 09 Nov 2009 19:39:47.0346 (UTC) FILETIME=[65150F20:01CA6174] Cc: tcpm@ietf.org Subject: Re: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:39:48 -0000 Hello Arnd, Thanks for your comment; unfortunately, I'm not supposed to get inspiration from GPL'ed code :)=20 Do you know which kernel versions feature this? I've checked 2.6.16 and=20 2.6.18 (commercial distributions), but none of the most recent ones... FACK as described here http://www.psc.edu/networking/papers/FACKnotes/current/ seems to be a sender-only algorithm; Thus if the receiver is implementing SACK, the sender should be able to use it, right? I just rechecked - the trace does show the hallmark signs of FACK, but no sign of a retransmission of a lost retransmitted segment before a (comparatively) long Period (assuingly RTO) starting a limited slow start (as the slow start ACKs Are still SACKs for a large sequence space)... (Using CentOS53, kernel 2.6.18 in this quick test). Hmm... Running a 2nd check (this time with cached session parameters), the Linux Kernel seems to do a 2nd sack recovery - even though not optimally so (not at the very first possibility w/ 3 SACK-ACKs indicating that it=20 would be possible...). The first trace appears to have run into a RTO with The very first dropped segment (and the stream took ages...) 3rd test: 237 msec delay (RTO?), with the last new segment being set 36 ms after the 2nd drop (so, nearly exactly 200 ms after sending the last new segment, And receiveing about 80 uninterrupted ACKs... So, the linux stack seems to have the capability, but it's not reliably invoked... Thanks for pointing this out! Regarding the other two question - for the first one, please see The diagram I sent earlier; I hope this clarifies what I mean. If I am mistaken somewhere, please let me know... And with the last statement (fastretransmission finished) I referred To the point in time, when the sender has sent all segments being flagged By SACK to have been missing, before noticing (one RTT later) that another One might be missing; this might be a special case, though, as I assumed That retransmission would end prior to the receiver detecting the=20 2nd loss... I guess a time-flow diagram would help :) Best regards, Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Arnd Hannemann [mailto:hannemann@i4.informatik.rwth-aachen.de]=20 Sent: Montag, 9. November 2009 16:21 To: Scheffenegger, Richard Cc: tcpm@ietf.org Subject: Re: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP) Scheffenegger, Richard schrieb: > But what puzzles me the most - even with SACK enabled TCP stacks,=20 > virtually no implementation can detect / act upon detection of the=20 > loss of a retransmitted segment during fast recovery. This despite the > fact, that the stipulations in > RFC3517 requires the receiver to make the information to detect such=20 > an event implicitly available to the sender. The first SACK option has > to reflect the last segment, which triggered this SACK. Some implementations actually do detect lost retransmissions. (see Linux tcp_mark_lost_retrans()) However, currently only for FACK enabled flows. (Comments indicate, it would be non-trivial / too-expensive for SACK enabled flows.) > Together with the scoreboard held at the sender, it should be rather=20 > easy to find out if the left edge of the lowest hole (relative to=20 > stream octets) closes > If that left edge stays constant for "DupThresh" number of ACKs, which > reduce the overall number of octets in holes (any one hole might close > due to the retransmitted packets still received), AND the sender=20 > retransmits beginning with the lowest hole first, this would be a=20 > clear indication of another segment retransmit loss... Sorry, I don't understand. You mean "DupThresh" number of DupACKs? Sack-blocks? After which point in time? After the first retransmit? SACK-blocks higher than recovery point? (the latter would make most sense, IMO) > Even a less speedy detection logic would work for SACK-enabled=20 > sessions: once the fast recovery is finished from the sender's point=20 > of view, if the receiver still complains about missing segments=20 > (indicated by having the SACK rightmost edge - in the first slot SACK=20 > option - at a segment higher than when fast recovery started), another > round of fast recovery could be invoked, rather than waiting for RTO. How can fast recovery be "finished" if the sender is missing packets? Best regards, Arnd Hannemann From andrew.knutsen@bluecoat.com Mon Nov 9 11:50:23 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEA23A6AA8 for ; Mon, 9 Nov 2009 11:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKgwRAfDgFXp for ; Mon, 9 Nov 2009 11:50:22 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id B2D513A6BAB for ; Mon, 9 Nov 2009 11:50:04 -0800 (PST) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nA9JoVdQ017046 for ; Mon, 9 Nov 2009 11:50:31 -0800 (PST) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:50:26 -0800 Message-ID: <4AF87281.4070109@bluecoat.com> Date: Mon, 09 Nov 2009 11:50:25 -0800 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2009 19:50:26.0158 (UTC) FILETIME=[E1D808E0:01CA6175] Cc: ron.frederick@bluecoat.com, jamshid.mahdavi@bluecoat.com, qing.li@bluecoat.com, weijen.yeh@bluecoat.com Subject: [tcpm] New Version Notification for draft-knutsen-tcpm-middlebox-discovery-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 19:50:23 -0000 This new version includes the changes I mentioned in my last email, which didn't make it in before the meeting deadline. We appreciate your attention to this draft. We'd like to move it to the next step ASAP. Andrew A new version of I-D, draft-knutsen-tcpm-middlebox-discovery-03.txt has been successfuly submitted by Andrew Knutsen and posted to the IETF repository. Filename: draft-knutsen-tcpm-middlebox-discovery Revision: 03 Title: TCP Option for Transparent Middlebox Discovery Creation_date: 2009-11-09 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document describes a TCP option intended to facilitate transparent detection of middleboxes (or services playing that role) along the path of a TCP connection as the connection is made. The option has no effect if an appropriate middlebox is not on the path. The IETF Secretariat. From mallman@icir.org Mon Nov 9 12:50:42 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C1C3A6B78 for ; Mon, 9 Nov 2009 12:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbhxG48g9yzP for ; Mon, 9 Nov 2009 12:50:41 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 6FD203A687B for ; Mon, 9 Nov 2009 12:50:41 -0800 (PST) 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 nA9KosbR019107; Mon, 9 Nov 2009 12:50:54 -0800 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 A30143E5D646; Mon, 9 Nov 2009 15:50:49 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B536759FA3C; Mon, 9 Nov 2009 15:50:48 -0500 (EST) To: tcpm@ietf.org From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma32934-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 09 Nov 2009 15:50:48 -0500 Sender: mallman@icir.org Message-Id: <20091109205048.B536759FA3C@lawyers.icir.org> Cc: k.avrachenkov@sophia.inria.fr, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:50:42 -0000 ----------ma32934-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- > We believe we have addressed all comments we received on the early > retranmsit ID. I just went to submit a new version and have missed the > cut-off. I have set a bit to submit when the system opens again on > Nov/9. However, until then I put the version I was going to submit here > ... > > http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt > > Comments are very welcome. Since TCPM is not meeting this week Lars got this draft approved for posting. So, it is now at the usual place (as "-02" not "-02a). Our hit is that it seems finished. Please yell if there is more to do. allman ----------ma32934-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkr4gKgACgkQWyrrWs4yIs6c+wCglzDtzKjJ6vxjdAnSaDLluERm db8AnRAhV2LKv42SYxliZiRssurwnCcc =35mR -----END PGP SIGNATURE----- ----------ma32934-1-- From rs@netapp.com Mon Nov 9 16:09:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE403A6972 for ; Mon, 9 Nov 2009 16:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6OtRu0W0P-S for ; Mon, 9 Nov 2009 16:09:09 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 76F613A677E for ; Mon, 9 Nov 2009 16:09:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,711,1249282800"; d="scan'208";a="103083817" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 09 Nov 2009 16:09:33 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAA09Xcw026778; Mon, 9 Nov 2009 16:09:33 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 00:09:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 00:09:02 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0649172D@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re:[tcpm] Curiosity about draft-mathis-tcp-ratehalving Thread-Index: AcphmgJZPZYXtx46RIq6HN0XY38Ywg== From: "Scheffenegger, Richard" To: , X-OriginalArrivalTime: 10 Nov 2009 00:09:33.0102 (UTC) FILETIME=[148B6CE0:01CA619A] Cc: tcpm@ietf.org Subject: Re: [tcpm] Curiosity about draft-mathis-tcp-ratehalving X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:09:10 -0000 Hello Carsten, This is a very good question indeed. Keeping the ACK clock running, and avoiding bursts of segments delivered all at once in a single burst to a L2 LAN network is something where my interests are too... (as todays hosts are increasingly capable of oversaturating slightly dated network equipment with full wire speed traffic). Is there a procedure to revive / adopt a dead draft? I have not spent much time on this issue, but noted the burst behavior After fastretransmit. As RateHalving extended the scope of Limited Transmit (with the similar goal), shouldn't this be discussed for inclusion in a RFC 3042bis? Since certain other congestion algorithms have a beta of less than 0.5=20 (ie. BIC, CUBIC use 0.8) when selecting a new ssthresh, perhaps the effect of RateHalfing, but with 2 out of 3 (0.66) policy or 3 out of 4 (0.75) at the end of the RTT should be investigated? (To be less conservative When reducing the sending rate). One extension to the draft might be the discussion on how to deal with RFC 3465 (ABC) during rate halving; with SACK, ABC could still be employed, And a new segment triggered only, when 2*MSS has been covered by the new SACKs... Regards, Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com =20 Franz-Klein-Gasse 5 1190 Wien=20 * To: Matt Mathis > * Subject: [tcpm] Curiosity about draft-mathis-tcp-ratehalving * From: Carsten Wolff > * Date: Wed, 4 Nov 2009 13:48:51 +0100 _____ =20 Hello Matt, everyone, I'm curious about draft-mathis-tcp-ratehalving=20 (http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt) and why it=20 never exceeded version 00 and expired years ago. It seems, several of the=20 ideas (fack, ratehalving, the concept of rhcwnd) in this paper made it into=20 the Linux TCP implementation in some form, which means they're part of a big=20 chunk of today's web servers and other Internet hosts. Why has there been no=20 interest in taking this draft further? Cheers, Carsten From root@core3.amsl.com Mon Nov 9 23:30:02 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2342F3A6882; Mon, 9 Nov 2009 23:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091110073002.2342F3A6882@core3.amsl.com> Date: Mon, 9 Nov 2009 23:30:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-01.txt Pages : 13 Date : 2009-11-09 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-urgent-data-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-09232618.I-D@ietf.org> --NextPart-- From alexander.zimmermann@nets.rwth-aachen.de Tue Nov 10 00:39:46 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6133A6927 for ; Tue, 10 Nov 2009 00:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEipU980h1TT for ; Tue, 10 Nov 2009 00:39:46 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 768E93A6889 for ; Tue, 10 Nov 2009 00:39:23 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSV00LJGXEDUVA0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 09:39:49 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,715,1249250400"; d="scan'208";a="33147701" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 10 Nov 2009 09:39:49 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSV0011RXEDUN80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 09:39:49 +0100 (CET) From: Alexander Zimmermann In-reply-to: <20091109205048.B536759FA3C@lawyers.icir.org> Date: Tue, 10 Nov 2009 09:39:49 +0100 Message-id: References: <20091109205048.B536759FA3C@lawyers.icir.org> To: "tcpm@ietf.org Extensions WG" X-Mailer: Apple Mail (2.1077) Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:39:46 -0000 Hi Mark, give me one or two days more to look over the document again... Alex Am 09.11.2009 um 21:50 schrieb Mark Allman: > > Folks- > >> We believe we have addressed all comments we received on the early >> retranmsit ID. I just went to submit a new version and have missed the >> cut-off. I have set a bit to submit when the system opens again on >> Nov/9. However, until then I put the version I was going to submit here >> ... >> >> http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt >> >> Comments are very welcome. > > Since TCPM is not meeting this week Lars got this draft approved for > posting. So, it is now at the usual place (as "-02" not "-02a). > > Our hit is that it seems finished. Please yell if there is more to do. > > allman > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From hannemann@i4.informatik.rwth-aachen.de Tue Nov 10 04:03:41 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15ED928C18C for ; Tue, 10 Nov 2009 04:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07LrMXM0ekBw for ; Tue, 10 Nov 2009 04:03:40 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id DC5D33A6AAD for ; Tue, 10 Nov 2009 04:03:39 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSW00LVV6UTVZH0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 13:04:05 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,715,1249250400"; d="scan'208";a="33194213" Received: from relay-2.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.75]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 10 Nov 2009 13:04:06 +0100 Received: from [137.226.12.85] (informatik-4-137-226-12-85.nn.RWTH-Aachen.DE [137.226.12.85] (may be forged)) by relay.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id nAAC45gM009669; Tue, 10 Nov 2009 13:04:05 +0100 (CET) Message-id: <4AF9569C.80306@i4.informatik.rwth-aachen.de> Date: Tue, 10 Nov 2009 13:03:40 +0100 From: Arnd Hannemann User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: rs@netapp.com References: <5FDC413D5FA246468C200652D63E627A064916CA@LDCMVEXC1-PRD.hq.netapp.com> In-reply-to: <5FDC413D5FA246468C200652D63E627A064916CA@LDCMVEXC1-PRD.hq.netapp.com> Cc: Alexander Zimmermann , tcpm@ietf.org Subject: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:03:41 -0000 Hi, Scheffenegger, Richard schrieb: > Thanks for your comment; unfortunately, I'm not supposed to get > inspiration from GPL'ed code :) > > > Do you know which kernel versions feature this? I've checked 2.6.16 and > 2.6.18 (commercial distributions), but none of the most recent ones... At least 2.6.24 (Ubuntu 8.04 LTS) and newer have this. > > FACK as described here > http://www.psc.edu/networking/papers/FACKnotes/current/ > seems to be a sender-only algorithm; Thus if the receiver is > implementing > SACK, the sender should be able to use it, right? As far as I remember the advantage of FACK for detecting lost retransmissions is, that you can be sure that after invoking "Fast Retransmit" you retransmitted all holes up to RecoveryPoint before sending any new data. Now you can use any ACK containing a SACK block above RecoveryPoint for an indication of a lost retransmission. But note, that FACK has serious problems with reordering. In my opinion SACK-TCP you would need to track a lot more. Thinking of it, maybe it would be enough to store highest seq sent so-far for each retransmit. And then check this for incoming SACKs individually for each retransmit. Might be still too expensive... [Shortened E-mail] > > And with the last statement (fastretransmission finished) I referred > To the point in time, when the sender has sent all segments being > flagged > By SACK to have been missing, before noticing (one RTT later) that > another > One might be missing; this might be a special case, though, as I assumed > That retransmission would end prior to the receiver detecting the > 2nd loss... Don't forget that with SACK-TCP the TCP sender will mix retransmissions and new segments all the time during recovery. The interesting part is: How does the TCP sender detect, that a retransmission might be missing? Simply checking against RecoveryPoint would not work... Or only for the "first hole". > > I guess a time-flow diagram would help :) Yes please! Best regards, Arnd Hannemann From alexander.zimmermann@nets.rwth-aachen.de Tue Nov 10 04:50:06 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD933A69E4 for ; Tue, 10 Nov 2009 04:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.865 X-Spam-Level: X-Spam-Status: No, score=-3.865 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FD68MWjaHMl for ; Tue, 10 Nov 2009 04:50:05 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 7B7BF3A683C for ; Tue, 10 Nov 2009 04:50:05 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSW009N6906KSG0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 13:50:30 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,716,1249250400"; d="scan'208";a="33202792" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 10 Nov 2009 13:50:30 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSW005U8906E630@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 13:50:30 +0100 (CET) From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A06491679@LDCMVEXC1-PRD.hq.netapp.com> Date: Tue, 10 Nov 2009 13:50:30 +0100 Message-id: <2C92861C-3B66-4E7F-9255-66AE6C2B1BB1@nets.rwth-aachen.de> References: <5FDC413D5FA246468C200652D63E627A06491679@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:50:07 -0000 Hi Richard, I discussed your example with Arnd (he is a line-of-sight colleague). Your "algorithms" may workwhen you have only one bust lost per cwnd. If you have multiple non-burst loss (e.g. WLAN), IMHO, is doesn't work. Am 09.11.2009 um 18:27 schrieb Scheffenegger, Richard: > > Hi Alexander, > > Thanks for the welcome :) > > I fork another thread with the LimitedTransport||FastRecovery / ABC interaction... > > > I will try to sketch up an example to demonstrate what problem I'm trying to address: > > > Let's assume the cwnd is already open for at least 7 segments, before the segment with > sequence number 10000 is the first one to be dropped by the network. > > Also, let's assume that FastRetransmit runs from the left edge of the leftmost hole > (SND.UNA) upwards, and that per ACK only a single segment is sent. > > > Triggering ACK Left Right Left Right > Segment Edge 1 Edge 1 Edge 2 Edge 2 > > 9000 9000 > 10000 (lost) * > 11000 (lost) > 12000 (lost) > 13000 (lost) > 14000 (lost) > 15000 10000 15000 16000 > 16000 10000 15000 17000 > 17000 10000 15000 18000 Ok, I count 9 segments ;-) Anyway, your example is a little bit strange. You assume you send 9 segment in a burst. Then your ACK for 9000 will trigger the segment 18000. Then the 2 DUPACKs for 15000 and 16000 will trigger 19000, 20000 respectively (Limited Transmit). The third DUPACK will trigger the Fast Retransmit 10000. Since NextSeq() and pipe allow you retransmit 11000, 12000. At this point you have to wait since the pipe is full (if I calculate pipe in a rush correctly). A RTT later you will get 3 Dupacks, even if the 10000 is not lost. OK, I think you can adjust your example so that it works for the given case, however in other scenarios (multiple loss, reordering, packet duplication,...) it will be much more complicated. I suggest writing examples as Ilpo does in http://tools.ietf.org/html/draft-ietf-tcpm-sack-recovery-entry-00. It's much more easier to read. > > 3 ACKs trigger fast retransmit > > 10000 (lost again) > 11000 10000 11000 12000 15000 18000 > 12000 10000 11000 13000 15000 18000 > 13000 10000 11000 14000 15000 18000 > -> here we have again 3 ACKs indicating a another loss of one of the retransmitted > packets. The leftmost hole did not change, while the overall number of SACKed > octets did decrease for 3 consecutive ACKs (4; 3 and 2 segments marked by SACK). > Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From rs@netapp.com Tue Nov 10 05:33:00 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0442F3A6A19 for ; Tue, 10 Nov 2009 05:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.682 X-Spam-Level: X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKoovndnnL0y for ; Tue, 10 Nov 2009 05:32:58 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 05B0B3A672F for ; Tue, 10 Nov 2009 05:32:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,716,1249282800"; d="scan'208";a="113483676" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Nov 2009 05:33:23 -0800 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAADXNB0001015; Tue, 10 Nov 2009 05:33:23 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 14:33:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 13:32:52 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A065D0DE2@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4AF9569C.80306@i4.informatik.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detect Lost Retransmit mit SACK Thread-Index: Acph/fBeHBrVQHiMQHOlKJKlWKT7ZAAA9sUg From: "Scheffenegger, Richard" To: "Arnd Hannemann" X-OriginalArrivalTime: 10 Nov 2009 13:33:23.0479 (UTC) FILETIME=[6016EA70:01CA620A] Cc: Alexander Zimmermann , tcpm@ietf.org Subject: Re: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:33:00 -0000 Hi Arnd, Let's think about what would be required to track a lost retransmitted segment. A) the sender can only know about this one RTT after it send out the first=20 retransmission at the earliest. A1) With TSOpt, they could be used to "remember" when Retransmission started;=20 When an ACKs with TSEcn > (TSOpt + RTT) is seen by the sender, it can=20 re-arm the DUPACK detector. A2) With SACK, tracking SND.NXT and HOLEBYTES (number of octets in all current holes)=20 can be employed to track RTT (they need to be initialized when the first=20 retransmitted segment is sent). When an ACK contains a SACK for = >=3D SND.NXT, or the=20 HOLEBYTES are smaller than when retransmission started, the DUPACK detector can=20 be re-armed. A3) If neither TSOpt nor SACK is used, revert to current behavior (RTO timeout to detect a lost retransmit). B) DUPACK detector would need to be enhanced over what is currently in the RFCs (but=20 I think most of that is already in Drafts, ie.=20 http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 ). B1) With SACK enabled, fully duplicate ACKs (ACK and SACK have been seen before, and=20 prev_HOLEBYTES =3D=3D HOLEBYTES) can be discarded; lost ACKs would count for two=20 (prev_HOLEBYTES < HOLEBYTES - SMSS). B2) With TSOpt, if another RTT passes without advancing SND.UNA,=20 increase DupAcks +=3D DupThresh=20 When DupThresh # of ACKs are received, reset HighRxt =3D SND.UNA, = DupAcks =3D 0; *) There are two comments I would like to make: A) Latency: if the sender first sends out the entire range of holes, before reacting to a detectable lost retransmitted packet, the latency observed by the application on the receiver side will increase needlessly. It might take a number of RTTs under certain circumstances, before all the holes have been retransmitted once...=20 B) Complexity: As soon as any congestion event is encountered, TCP won't be in fastpath mode any longer; the added computational complexity to (reliably, see my check on FACK with Linux 2.6.18 yesterday) trigger another retransmission of an already retransmitted segment is neglegible, compared to current best practise (waiting for RTO), when you need to move data around as quickly (low latency AND high bandwidth) as possible. As mentioned, my background is not so much the global internet (with statistically valid implict assumptions), but rather High-Speed, short Range, (lossy) LANs, with only very few active TCP sessions at any one time. The hosts I deal with might have as few as 10-20 TCP sessions, of which only 1-4 are pushing data, but those might run over dedicated 10GbE ports (overloading L2 switches in the process, and exhibiting Burst Loss (correlated packet loss) ). Thus my view might deviate from a "typical" view in certain aspects. I might even be=20 in error and would like to hear, why some things cann't work like depicted. However,=20 I would place more emphasis on the timely recovery of any lost (or re-lost) segment,=20 over making sure that no single segment is re-transmitted needlessly; better retransmit=20 a little (!) too much too soon, instead of waiting for RTO :) I want to point out the=20 "little" though, as overwhelming a already lossy network with too much retransmissions=20 (ie. Setting RTO =3D 0/1 tick, with a TCP clock runnig in msec), will = only cause more loss... *) reducing the segment size for this generation of retransmission might also be=20 advisable; I have seen odd gear (but that's actually a long time ago), which simply=20 would choke on certain bit-patterns. Reducing the mss might break such bit/byte=20 patterns, so that the always-lost segment now looks differently and makes it through...=20 But really, this shouldn't be necessary any more, I think. Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Arnd Hannemann [mailto:hannemann@i4.informatik.rwth-aachen.de]=20 Sent: Dienstag, 10. November 2009 13:04 To: Scheffenegger, Richard Cc: tcpm@ietf.org; Alexander Zimmermann Subject: Detect Lost Retransmit mit SACK Hi, Scheffenegger, Richard schrieb: > Thanks for your comment; unfortunately, I'm not supposed to get > inspiration from GPL'ed code :)=20 >=20 >=20 > Do you know which kernel versions feature this? I've checked 2.6.16 and=20 > 2.6.18 (commercial distributions), but none of the most recent ones... At least 2.6.24 (Ubuntu 8.04 LTS) and newer have this. >=20 > FACK as described here > http://www.psc.edu/networking/papers/FACKnotes/current/ > seems to be a sender-only algorithm; Thus if the receiver is > implementing > SACK, the sender should be able to use it, right? As far as I remember the advantage of FACK for detecting lost retransmissions is, that you can be sure that after invoking "Fast Retransmit" you retransmitted all holes up to RecoveryPoint before sending any new data. Now you can use any ACK containing a SACK block above RecoveryPoint for an indication of a lost retransmission. But note, that FACK has serious problems with reordering. In my opinion SACK-TCP you would need to track a lot more. Thinking of it, maybe it would be enough to store highest seq sent so-far for each retransmit. And then check this for incoming SACKs individually for each retransmit. Might be still too expensive... [Shortened E-mail] >=20 > And with the last statement (fastretransmission finished) I referred > To the point in time, when the sender has sent all segments being > flagged > By SACK to have been missing, before noticing (one RTT later) that > another > One might be missing; this might be a special case, though, as I assumed > That retransmission would end prior to the receiver detecting the=20 > 2nd loss... Don't forget that with SACK-TCP the TCP sender will mix retransmissions and new segments all the time during recovery. The interesting part is: How does the TCP sender detect, that a retransmission might be missing? Simply checking against RecoveryPoint would not work... Or only for the "first hole". >=20 > I guess a time-flow diagram would help :) Yes please! Best regards, Arnd Hannemann From rs@netapp.com Tue Nov 10 06:34:21 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448F73A672F for ; Tue, 10 Nov 2009 06:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZsVooGlt1N2 for ; Tue, 10 Nov 2009 06:34:19 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id A87D63A67F0 for ; Tue, 10 Nov 2009 06:34:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,716,1249282800"; d="scan'208";a="113497021" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Nov 2009 06:34:44 -0800 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAAEYiF5008532; Tue, 10 Nov 2009 06:34:44 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 15:34:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 14:34:12 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A065D0E76@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <2C92861C-3B66-4E7F-9255-66AE6C2B1BB1@nets.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detect Lost Retransmit with SACK Thread-Index: AcpiBGYLGyWQ0mcASf2LP8IRMC6nHQABnQnw From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 10 Nov 2009 14:34:44.0181 (UTC) FILETIME=[F1F57850:01CA6212] Cc: tcpm@ietf.org Subject: Re: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:34:21 -0000 Thanks Alex, I will try to give my example in another form: (RWND =3D 40000;=20 the timing might not be perfectly depicted). ACK Transmitted Received ACK Sent Received Segment Segment (Including SACK Blocks) =09 0- 999 1000- 1999 0- 999=09 1000 1000 1000- 1999 2000- 2999 2000 2000 3000- 3999 4000- 4999 2000- 2999 5000- 5999 3000 3000 6000- 6999 3000- 3999 7000- 7999 4000 4000 8000- 8999 4000- 4999 9000- 9999 5000 5000 10000-10999 5000- 5999 11000-11999 6000 6000 12000-12999 6000- 6999 13000-13999 7000 7000 7000- 7999 14000-14999 8000 8000 8000- 8999 15000-15999 9000 9000 9000-10000 16000-16999 10000 10000 (dropped) 17000-17999 (dropped) . =09 (dropped) . =09 (dropped) . (dropped) .=09 15000-15999 10000, SACK=3D15k-16k 10000, SACK=3D15k-16k 16000-16999 18000-18999 10000, SACK=3D15k-17k 10000, SACK=3D15k-17k 17000-17999 19000-19999 10000, SACK=3D15k-18k 10000, SACK=3D15k-18k . 10000-10999 18000-18999 10000, SACK=3D15k-19k 10000, SACK=3D15k-19k 19000-19999 11000-11999 10000, SACK=3D15k-20k 10000, SACK=3D15k-20k (dropped) 12000-12999 =09 11000-11999 10000, SACK=3D11k-12k;15k-20k 10000, SACK=3D11k-12k;15k-20k 12000-12999 13000-13999 10000, SACK=3D11k-13k;15k-20k 10000, SACK=3D11k-13k;15k-20k 14000-14999 13000-13999 10000, SACK=3D11k-14k;15k-20k 10000, SACK=3D11k-14k;15k-20k 14000-14999 !*A 20000-20999 10000, SACK=3D11k-20k ! 10000, SACK=3D11k-20k ! 21000-21999 20000-20999 ! 22000-22999 10000, SACK=3D11k-21k ! 10000, SACK=3D11k-21k ! 23000-23999 21000-21999 ! 24000-24999 10000, SACK=3D11k-22k ! 10000, SACK=3D11k-22k 22000-22999 ! 25000-25999 10000, SACK=3D11k-23k ! 10000, SACK=3D11k-23k 23000-23999 !*B 26000-26999 10000, SACK=3D11k-24k ! :: :: :: :: !RWND Full: 10000, SACK=3D11k-50k ! 10000, SACK=3D11k-50k ! =20 ! :: :: :: :: ! !RTO: ! 10000-10999 ! 50000 !Slow-Start =20 All the Lines marked with ! Indicate current best practise behaviour=20 (RFC, no drafts), if I'm not mistaken - left out LimitedTransmit for=20 simplicity's sake. At point *A (or one ACK later), the sender would have the earliest=20 possibility to detect a lost retransmission, taking into account the=20 usual 3 ACK reordering hold-down... In this example, this happens by=20 coincidence at the same time, that the sender has finished fast=20 retransmission (and would go into fastrecovery, restoring CWND, etc;=20 this is NOT a requirement....; Actually, the cwnd is likely to be in the order of 100reds of segments, and most of the time, the sender will have finished the retransmission episode before one RTT is up) At point *B, the sender could detect with 100% certainty (2*RTT) that=20 one retransmitted segment was lost. However, current practise (excluding Linux with FACK for now, as=20 that's not in RFCs) is to continue sending SND.NXT, until RWND is=20 full or RTO expires... Note that the suggested algorithm will never trigger if no=20 retransmitted packet is lost - if would behave exactly the same as=20 currently. Only when *A or *B marks are detected, the DUPACK detection logic=20 would re-arm (a more complex implementation could re-arm at the first=20 sign of retransmission loss, and dis-arm if a ACK within DupAck=20 distance ACKs the segment, for which it armed before). Thus, a lost retransmission would be retried close to the earliest=20 possibility, instead of waiting until RTO (a bit like what FACK seems=20 to try to do, but with low reliability as it seems). Multiple Burst loss events, each lossing a different segment in=20 one cwnd would be handled by SACK. If there are extended periods of time, where no communication is=20 possible (the same segment doesn't get lost only twice, but multiple=20 times), RTO would eventually fire and, using the RTO backoff=20 algorithm, retry at ever increasing intervals with very low=20 (1-2 segments) rate... Do you have a test bed, where you can deliberately drop the same segment twice (or n times) and check the TCP Behaviour for yourself? Best regards, Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 -----Original Message----- From: Alexander Zimmermann [mailto:alexander.zimmermann@nets.rwth-aachen.de]=20 Sent: Dienstag, 10. November 2009 13:51 To: Scheffenegger, Richard Cc: tcpm@ietf.org Subject: Re: Detect Lost Retransmit with SACK Hi Richard, I discussed your example with Arnd (he is a line-of-sight colleague). Your "algorithms" may workwhen you have only one bust lost per cwnd. If you have multiple non-burst loss (e.g. WLAN), IMHO, is doesn't work. Am 09.11.2009 um 18:27 schrieb Scheffenegger, Richard: >=20 > Hi Alexander, >=20 > Thanks for the welcome :) >=20 > I fork another thread with the LimitedTransport||FastRecovery / ABC interaction... >=20 >=20 > I will try to sketch up an example to demonstrate what problem I'm trying to address: >=20 >=20 > Let's assume the cwnd is already open for at least 7 segments, before the segment with > sequence number 10000 is the first one to be dropped by the network. >=20 > Also, let's assume that FastRetransmit runs from the left edge of the leftmost hole > (SND.UNA) upwards, and that per ACK only a single segment is sent. >=20 >=20 > Triggering ACK Left Right Left Right > Segment Edge 1 Edge 1 Edge 2 Edge 2 >=20 > 9000 9000 > 10000 (lost) * > 11000 (lost) > 12000 (lost) > 13000 (lost) > 14000 (lost) > 15000 10000 15000 16000 > 16000 10000 15000 17000 > 17000 10000 15000 18000 Ok, I count 9 segments ;-) Anyway, your example is a little bit strange. You assume you send 9 segment in a burst. Then your ACK for 9000 will trigger the segment 18000. Then the 2 DUPACKs for 15000 and 16000 will trigger 19000, 20000 respectively (Limited Transmit). The third DUPACK will trigger the Fast Retransmit 10000. Since NextSeq() and pipe allow you retransmit 11000, 12000. At this point you have to wait since the pipe is full (if I calculate pipe in a rush correctly). A RTT later you will get 3 Dupacks, even if the 10000 is not lost. OK, I think you can adjust your example so that it works for the given case, however in other scenarios (multiple loss, reordering, packet duplication,...) it will be much more complicated. I suggest writing examples as Ilpo does in http://tools.ietf.org/html/draft-ietf-tcpm-sack-recovery-entry-00. It's much more easier to read. >=20 > 3 ACKs trigger fast retransmit >=20 > 10000 (lost again) > 11000 10000 11000 12000 15000 18000 > 12000 10000 11000 13000 15000 18000 > 13000 10000 11000 14000 15000 18000 > -> here we have again 3 ACKs indicating a another loss of one of the retransmitted > packets. The leftmost hole did not change, while the overall number of SACKed > octets did decrease for 3 consecutive ACKs (4; 3 and 2 segments marked by SACK). >=20 Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From Alexander.Zimmermann@nets.rwth-aachen.de Tue Nov 10 07:13:21 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF6628C137 for ; Tue, 10 Nov 2009 07:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg+eqc++CGSt for ; Tue, 10 Nov 2009 07:13:19 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 2904328C1C8 for ; Tue, 10 Nov 2009 07:13:19 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSW008BBFMXN570@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 16:13:45 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,716,1249250400"; d="scan'208";a="33228142" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 10 Nov 2009 16:13:45 +0100 Received: from 43-047.eduroam.rwth-aachen.de ([unknown] [134.61.43.47]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSW005JWFMWE660@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 16:13:45 +0100 (CET) From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A065D0E76@LDCMVEXC1-PRD.hq.netapp.com> Date: Tue, 10 Nov 2009 16:13:44 +0100 Message-id: <489EB3AF-F3B9-4196-A25C-F19B1B67079F@nets.rwth-aachen.de> References: <5FDC413D5FA246468C200652D63E627A065D0E76@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 15:13:21 -0000 Hi Richard, thanks for the updated example. However, since your mailer is a little bit too eager in formatting emails, could you send your example as an attached file? Alex Am 10.11.2009 um 15:34 schrieb Scheffenegger, Richard: > > Thanks Alex, > > I will try to give my example in another form: (RWND = 40000; > the timing might not be perfectly depicted). > > ACK Transmitted Received ACK Sent > Received Segment Segment (Including SACK Blocks) > > > 0- 999 > 1000- 1999 > 0- 999 > 1000 > 1000 1000- 1999 > 2000- 2999 2000 > 2000 3000- 3999 > 4000- 4999 2000- 2999 > 5000- 5999 3000 > 3000 6000- 6999 3000- 3999 > 7000- 7999 4000 > 4000 8000- 8999 4000- 4999 > 9000- 9999 5000 > 5000 10000-10999 5000- 5999 > 11000-11999 6000 > 6000 12000-12999 6000- 6999 > 13000-13999 7000 > 7000 7000- 7999 > 14000-14999 8000 > 8000 8000- 8999 > 15000-15999 9000 > 9000 9000-10000 > 16000-16999 10000 > 10000 (dropped) > 17000-17999 > (dropped) > . > (dropped) > . > (dropped) > . > (dropped) > . > 15000-15999 > 10000, > SACK=15k-16k > 10000, SACK=15k-16k 16000-16999 > 18000-18999 10000, > SACK=15k-17k > 10000, SACK=15k-17k 17000-17999 > 19000-19999 10000, > SACK=15k-18k > 10000, SACK=15k-18k . > 10000-10999 > 18000-18999 > 10000, > SACK=15k-19k > 10000, SACK=15k-19k 19000-19999 > 11000-11999 10000, > SACK=15k-20k > 10000, SACK=15k-20k (dropped) > 12000-12999 > 11000-11999 > 10000, > SACK=11k-12k;15k-20k > 10000, SACK=11k-12k;15k-20k 12000-12999 > 13000-13999 10000, > SACK=11k-13k;15k-20k > 10000, SACK=11k-13k;15k-20k > 14000-14999 13000-13999 > 10000, > SACK=11k-14k;15k-20k > 10000, SACK=11k-14k;15k-20k 14000-14999 > !*A 20000-20999 10000, > SACK=11k-20k > ! 10000, SACK=11k-20k > ! 21000-21999 20000-20999 > ! 22000-22999 10000, > SACK=11k-21k > ! 10000, SACK=11k-21k > ! 23000-23999 21000-21999 > ! 24000-24999 10000, > SACK=11k-22k > ! 10000, SACK=11k-22k 22000-22999 > ! 25000-25999 10000, > SACK=11k-23k > ! 10000, SACK=11k-23k 23000-23999 > !*B 26000-26999 10000, > SACK=11k-24k > ! :: :: :: :: > !RWND Full: 10000, SACK=11k-50k > ! 10000, SACK=11k-50k > ! > ! :: :: :: :: > ! > !RTO: > ! 10000-10999 > ! 50000 > !Slow-Start > > > All the Lines marked with ! Indicate current best practise behaviour > (RFC, no drafts), if I'm not mistaken - left out LimitedTransmit for > simplicity's sake. > > At point *A (or one ACK later), the sender would have the earliest > possibility to detect a lost retransmission, taking into account the > usual 3 ACK reordering hold-down... In this example, this happens by > coincidence at the same time, that the sender has finished fast > retransmission (and would go into fastrecovery, restoring CWND, etc; > this is NOT a requirement....; Actually, the cwnd is likely to be in > the order of 100reds of segments, and most of the time, the sender > will have finished the retransmission episode before one RTT is up) > > At point *B, the sender could detect with 100% certainty (2*RTT) that > one retransmitted segment was lost. > > However, current practise (excluding Linux with FACK for now, as > that's not in RFCs) is to continue sending SND.NXT, until RWND is > full or RTO expires... > > Note that the suggested algorithm will never trigger if no > retransmitted packet is lost - if would behave exactly the same as > currently. > > Only when *A or *B marks are detected, the DUPACK detection logic > would re-arm (a more complex implementation could re-arm at the first > sign of retransmission loss, and dis-arm if a ACK within DupAck > distance ACKs the segment, for which it armed before). > > Thus, a lost retransmission would be retried close to the earliest > possibility, instead of waiting until RTO (a bit like what FACK seems > to try to do, but with low reliability as it seems). > > Multiple Burst loss events, each lossing a different segment in > one cwnd would be handled by SACK. > > If there are extended periods of time, where no communication is > possible (the same segment doesn't get lost only twice, but multiple > times), RTO would eventually fire and, using the RTO backoff > algorithm, retry at ever increasing intervals with very low > (1-2 segments) rate... > > > Do you have a test bed, where you can deliberately drop the same > segment twice (or n times) and check the TCP Behaviour for yourself? > > Best regards, > > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > > -----Original Message----- > From: Alexander Zimmermann > [mailto:alexander.zimmermann@nets.rwth-aachen.de] > Sent: Dienstag, 10. November 2009 13:51 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: Detect Lost Retransmit with SACK > > Hi Richard, > > I discussed your example with Arnd (he is a line-of-sight colleague). > Your "algorithms" > may workwhen you have only one bust lost per cwnd. If you have multiple > non-burst > loss (e.g. WLAN), IMHO, is doesn't work. > > Am 09.11.2009 um 18:27 schrieb Scheffenegger, Richard: > >> >> Hi Alexander, >> >> Thanks for the welcome :) >> >> I fork another thread with the LimitedTransport||FastRecovery / ABC > interaction... >> >> >> I will try to sketch up an example to demonstrate what problem I'm > trying to address: >> >> >> Let's assume the cwnd is already open for at least 7 segments, before > the segment with >> sequence number 10000 is the first one to be dropped by the network. >> >> Also, let's assume that FastRetransmit runs from the left edge of the > leftmost hole >> (SND.UNA) upwards, and that per ACK only a single segment is sent. >> >> >> Triggering ACK Left Right Left Right >> Segment Edge 1 Edge 1 Edge 2 Edge 2 >> >> 9000 9000 >> 10000 (lost) * >> 11000 (lost) >> 12000 (lost) >> 13000 (lost) >> 14000 (lost) >> 15000 10000 15000 16000 >> 16000 10000 15000 17000 >> 17000 10000 15000 18000 > > Ok, I count 9 segments ;-) Anyway, your example is a little bit strange. > You assume you send 9 segment in a burst. Then your ACK for 9000 will > trigger > the segment 18000. Then the 2 DUPACKs for 15000 and 16000 will trigger > 19000, > 20000 respectively (Limited Transmit). The third DUPACK will trigger the > Fast > Retransmit 10000. Since NextSeq() and pipe allow you retransmit 11000, > 12000. > > At this point you have to wait since the pipe is full (if I calculate > pipe in a rush correctly). > A RTT later you will get 3 Dupacks, even if the 10000 is not lost. > > OK, I think you can adjust your example so that it works for the given > case, however in > other scenarios (multiple loss, reordering, packet duplication,...) it > will be much more > complicated. > > I suggest writing examples as Ilpo does in > http://tools.ietf.org/html/draft-ietf-tcpm-sack-recovery-entry-00. > It's much more easier to read. > >> >> 3 ACKs trigger fast retransmit >> >> 10000 (lost again) >> 11000 10000 11000 12000 15000 18000 >> 12000 10000 11000 13000 15000 18000 >> 13000 10000 11000 14000 15000 18000 >> -> here we have again 3 ACKs indicating a another loss of one of the > retransmitted >> packets. The leftmost hole did not change, while the overall number of > SACKed >> octets did decrease for 3 consecutive ACKs (4; 3 and 2 segments marked > by SACK). >> > > Alex > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From hannemann@i4.informatik.rwth-aachen.de Tue Nov 10 08:43:03 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1393A6B44 for ; Tue, 10 Nov 2009 08:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osRraAD7M6+D for ; Tue, 10 Nov 2009 08:43:02 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 33CDB28C136 for ; Tue, 10 Nov 2009 08:43:02 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSW009HKJSGAL60@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 10 Nov 2009 17:43:28 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,717,1249250400"; d="scan'208";a="33243083" Received: from relay-2.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.75]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 10 Nov 2009 17:43:28 +0100 Received: from [137.226.12.85] (informatik-4-137-226-12-85.nn.RWTH-Aachen.DE [137.226.12.85] (may be forged)) by relay.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id nAAGhSew022693; Tue, 10 Nov 2009 17:43:28 +0100 (CET) Message-id: <4AF99817.9010307@i4.informatik.rwth-aachen.de> Date: Tue, 10 Nov 2009 17:43:03 +0100 From: Arnd Hannemann User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: rs@netapp.com References: <5FDC413D5FA246468C200652D63E627A065D0DE2@LDCMVEXC1-PRD.hq.netapp.com> In-reply-to: <5FDC413D5FA246468C200652D63E627A065D0DE2@LDCMVEXC1-PRD.hq.netapp.com> Cc: tcpm@ietf.org, Alexander Zimmermann Subject: Re: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 16:43:03 -0000 Hi Richard, Scheffenegger, Richard schrieb: > Hi Arnd, > > Let's think about what would be required to track a lost retransmitted > segment. > > A) the sender can only know about this one RTT after it send out the > first > retransmission at the earliest. > > A1) With TSOpt, they could be used to "remember" when Retransmission > started; > When an ACKs with TSEcn > (TSOpt + RTT) is seen by the sender, it > can > re-arm the DUPACK detector. This is your non-SACK scenario? Please note that a TCP receiver will NOT echo TSVal from out-of-order segments. So this won't work. > A2) With SACK, tracking SND.NXT and HOLEBYTES (number of octets in all > current holes) > can be employed to track RTT (they need to be initialized when the > first > retransmitted segment is sent). When an ACK contains a SACK for >= > SND.NXT, or the > HOLEBYTES are smaller than when retransmission started, the DUPACK > detector can > be re-armed. You should specify what you mean with SND.NXT. We are in recovery, so we may very well send out new segments. I don't see why number of holes in sack scoreboard has anything todo with RTT. > > A3) If neither TSOpt nor SACK is used, revert to current behavior (RTO > timeout to > detect a lost retransmit). > > B) DUPACK detector would need to be enhanced over what is currently in > the RFCs (but > I think most of that is already in Drafts, ie. > http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 > ). > > B1) With SACK enabled, fully duplicate ACKs (ACK and SACK have been > seen before, and > prev_HOLEBYTES == HOLEBYTES) can be discarded; lost ACKs would > count for two > (prev_HOLEBYTES < HOLEBYTES - SMSS). Now B1 is SACK enabled scenario? You try to confuse me, right? All this makes little sense to me. > > B2) With TSOpt, if another RTT passes without advancing SND.UNA, > increase DupAcks += DupThresh > > When DupThresh # of ACKs are received, reset HighRxt = SND.UNA, DupAcks > = 0; *) See above... non-SACK is not going to work. > There are two comments I would like to make: > > A) Latency: if the sender first sends out the entire range of holes, > before > reacting to a detectable lost retransmitted packet, the latency > observed > by the application on the receiver side will increase needlessly. It > might > take a number of RTTs under certain circumstances, before all the > holes > have been retransmitted once... Show me an example. where a lost retransmission is detectable, while the sender did not send out retransmissions for every other hole? Sounds weird. > > B) Complexity: As soon as any congestion event is encountered, TCP won't > be in > fastpath mode any longer; the added computational complexity to > (reliably, see my > check on FACK with Linux 2.6.18 yesterday) trigger another > retransmission > of an already retransmitted segment is neglegible, compared to > current best > practise (waiting for RTO), when you need to move data around as > quickly (low > latency AND high bandwidth) as possible. As mentioned, my background > is not > so much the global internet (with statistically valid implict > assumptions), but > rather High-Speed, short Range, (lossy) LANs, with only very few > active TCP > sessions at any one time. The hosts I deal with might have as few as > 10-20 TCP > sessions, of which only 1-4 are pushing data, but those might run > over dedicated > 10GbE ports (overloading L2 switches in the process, and exhibiting > Burst Loss > (correlated packet loss) ). This probably highly rates from case to case. If you have a huge bandwidth-delay product even SACK scoreboard handling will have computational complexity which might outweigh its benefits. As you have seem to have the equipment at hand, you could do some cpu load and throughput measurements with 10GbE and SACK versus non-SACK flows. > > > Thus my view might deviate from a "typical" view in certain aspects. I > might even be > in error and would like to hear, why some things cann't work like > depicted. However, > I would place more emphasis on the timely recovery of any lost (or > re-lost) segment, > over making sure that no single segment is re-transmitted needlessly; > better retransmit > a little (!) too much too soon, instead of waiting for RTO :) I want to > point out the > "little" though, as overwhelming a already lossy network with too much > retransmissions > (ie. Setting RTO = 0/1 tick, with a TCP clock runnig in msec), will only > cause more loss... > I think it is a good idea to detect lost retransmissions and I think it is possible with SACK. I already proposed a potential solution ;-) "Just" store highest seq, for each retransmission. And check incoming SACKs on those. My main concern is, as already said, that this might get quiet expensive. But you are free to evaluate this more deeply ;-) Anyway, maybe we should focus on your other thread... Best regards, Arnd From rs@netapp.com Tue Nov 10 10:28:09 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B893A6B68 for ; Tue, 10 Nov 2009 10:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.462 X-Spam-Level: X-Spam-Status: No, score=-5.462 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2uW4+qg2s44 for ; Tue, 10 Nov 2009 10:28:07 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id E2F9A3A6B77 for ; Tue, 10 Nov 2009 10:28:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,717,1249282800"; d="scan'208";a="103238973" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 10 Nov 2009 10:28:32 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAAISW5c004359; Tue, 10 Nov 2009 10:28:32 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 18:28:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 18:28:00 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A065D0FB3@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4AF99817.9010307@i4.informatik.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detect Lost Retransmit mit SACK Thread-Index: AcpiJPeYklD9yAWST8apxiaICxNmRAABOOZA From: "Scheffenegger, Richard" To: "Arnd Hannemann" X-OriginalArrivalTime: 10 Nov 2009 18:28:32.0557 (UTC) FILETIME=[9B85C5D0:01CA6233] Cc: tcpm@ietf.org, Alexander Zimmermann Subject: Re: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:28:09 -0000 See inline Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 =20 > -----Original Message----- > From: Arnd Hannemann [mailto:hannemann@i4.informatik.rwth-aachen.de]=20 > Sent: Dienstag, 10. November 2009 17:43 > To: Scheffenegger, Richard > Cc: Alexander Zimmermann; tcpm@ietf.org > Subject: Re: Detect Lost Retransmit mit SACK >=20 > Hi Richard, >=20 >=20 > Scheffenegger, Richard schrieb: :: > >=20 > > A1) With TSOpt, they could be used to "remember" when=20 > > Retransmission started; > > When an ACKs with TSEcn > (TSOpt + RTT) is seen by=20 > > the sender, it can > > re-arm the DUPACK detector. >=20 > This is your non-SACK scenario? > Please note that a TCP receiver will NOT echo TSVal from=20 > out-of-order segments. So this won't work. Interesting; this doesn't seem to be what certain (most?) stacks are=20 doing - they seem to always reply in the ACK Tsecr the value of Tsopt/TS.recent=20 triggering the ACK... Or was your intention to say, that the receiver will not respond with Tsopt, but rather TS.recent? If so, than this makes no difference - the sender will detect the=20 first ACK from the receiver, which has the same TS (well, actually TS+1 as multiple segments are likely to carry the same TS) when the retransmission was started. This will be the sign for the sender, that at least one RTT has elapsed (that was the intention for having timestamps in the first place, right?). If the returned ACK does not cover the first retransmitted segment by that time, it's quite reasonable to assume that it got lost again. Again, keep in mind that I'm looking on LANs; a TS in 10 ms increments (100 Hz TCP clock) is likely to be put into a few hundred or thousand packets... If there is reason to believe the reordering can occur with delays >> RTT, then Yes, this simple detection logic would be fooled and falsely trigger a retransmission. However, IF the reordering is >> 2*RTT, then it's very likely that the=20 newly retransmitted segment arrives at the receiver first (over the faster=20 path), and again this would only serve to keep the application visible latency=20 as low as possible (between the points in time, where TCP can deliver some / any=20 new data up the stack...)=20 > > A2) With SACK, tracking SND.NXT and HOLEBYTES (number of=20 > > octets in all current holes) > > can be employed to track RTT (they need to be=20 > > initialized when the first > > retransmitted segment is sent). When an ACK contains=20 > > a SACK for >=3D SND.NXT, or the > > HOLEBYTES are smaller than when retransmission started, the=20 > > DUPACK detector can be re-armed. >=20 > You should specify what you mean with SND.NXT. > We are in recovery, so we may very well send out new segments. > I don't see why number of holes in sack scoreboard has=20 > anything todo with RTT. SND.NXT is the rightmost segment which the sender has never before=20 sent out to the network. Isn't that the meaning of Snd.nxt according=20 to RFC793? And I was not talking about the # of holes, but rather the amount of Data (in sum) between FACK (defined by the rightmost offset in the SACK Scoreboard, i.e. covering the highest ever received segment) and SND.UNA. Monitoring Holes will gain nothing (when there is reordering for example); But if the any one retransmission makes it though, the amount of unSACKed=20 data in the sum total of all holes in the scoreboard, will decrease -=20 indicating when at least one RTT has passed since start of FastRetransmit. >=20 > >=20 > > A3) If neither TSOpt nor SACK is used, revert to current behavior=20 > > (RTO timeout to > > detect a lost retransmit). > >=20 > > B) DUPACK detector would need to be enhanced over what is=20 > currently in=20 > > the RFCs (but > > I think most of that is already in Drafts, ie.=20 > > =20 > >=20 > http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 > > ). > >=20 > > B1) With SACK enabled, fully duplicate ACKs (ACK and SACK=20 > have been=20 > > seen before, and > > prev_HOLEBYTES =3D=3D HOLEBYTES) can be discarded; lost ACKs = would=20 > > count for two > > (prev_HOLEBYTES < HOLEBYTES - SMSS). >=20 > Now B1 is SACK enabled scenario? You try to confuse me, right? > All this makes little sense to me. I agree, it would have made sense to label points B1 and B2 the other way around to stay more consistent; that's one of the reasons why I like to=20 discuss this :) >=20 > >=20 > > B2) With TSOpt, if another RTT passes without advancing SND.UNA,=20 > > increase DupAcks +=3D DupThresh > >=20 > > When DupThresh # of ACKs are received, reset HighRxt =3D SND.UNA,=20 > > DupAcks =3D 0; *) >=20 > See above... > non-SACK is not going to work. See above - TSOpt is only used for the prime purpose to detect when a=20 RTT has passed. It doesn't matter if Tsecr contains TSopt or TS.recent...=20 =20 >=20 > > There are two comments I would like to make: > >=20 > > A) Latency: if the sender first sends out the entire range=20 > of holes,=20 > > before > > reacting to a detectable lost retransmitted packet, the latency=20 > > observed > > by the application on the receiver side will increase=20 > needlessly.=20 > > It might > > take a number of RTTs under certain circumstances,=20 > before all the=20 > > holes > > have been retransmitted once...=20 >=20 > Show me an example. where a lost retransmission is=20 > detectable, while the sender did not send out retransmissions=20 > for every other hole? > Sounds weird. Can I attach trace files on posts to this list, or shall I sent them=20 to you directly?=20 I assume that on the receiving side, the application is only delivered data, which has been ACKed (not SACKed). If the sender waits until=20 RTO before retrying to re-send a retransmission (sorry about these Multiple re-s :) ), the application will at least stall (not get any=20 new data) for RTO+2*RTT - and certain latency sensitive applications will time out before that. Again: I'm not talking about internet applications but rather LAN HPC applications with timeouts in the=20 order of a few seconds at most. Advancing (on the receiver) within that application timeout is Usually enough to not run into the application timeout. >=20 >=20 > >=20 > > B) Complexity: As soon as any congestion event is encountered, TCP=20 > > won't be in > > fastpath mode any longer; the added computational complexity to=20 > > (reliably, see my > > check on FACK with Linux 2.6.18 yesterday) trigger another=20 > > retransmission > > of an already retransmitted segment is neglegible, compared to=20 > > current best > > practise (waiting for RTO), when you need to move data around as=20 > > quickly (low > > latency AND high bandwidth) as possible. As mentioned, my=20 > > background is not > > so much the global internet (with statistically valid implict=20 > > assumptions), but > > rather High-Speed, short Range, (lossy) LANs, with only very few=20 > > active TCP > > sessions at any one time. The hosts I deal with might=20 > have as few=20 > > as 10-20 TCP > > sessions, of which only 1-4 are pushing data, but those=20 > might run=20 > > over dedicated > > 10GbE ports (overloading L2 switches in the process, and=20 > exhibiting=20 > > Burst Loss > > (correlated packet loss) ). >=20 > This probably highly rates from case to case. If you have a=20 > huge bandwidth-delay product even SACK scoreboard handling=20 > will have computational complexity which might outweigh its benefits. > As you have seem to have the equipment at hand, you could do=20 > some cpu load and throughput measurements with 10GbE and SACK=20 > versus non-SACK flows. Well, I was doing some test like this: http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html But the CPU impact (on top of what is required for 10G) was neglegible. But I have to admit, I didn't had the time yet to test a SACK scoreboard with every other byte marked mission (which could mean some 0,5 mio entries). But it seems that most implementations feature sorted scoreboards of limited (16/128) size. Traversing those is - again in my case of 10G LANs - still many orders of=20 magnitude faster then waiting for RTO.=20 I personally consider RTOs to be harmful (when there are other means to=20 recover with). :) (perhaps once I have worked through all the issues raised here, I submit a draft with "TCP RTO considered harmful" next April? :) >=20 >=20 > >=20 > >=20 > > Thus my view might deviate from a "typical" view in certain=20 > aspects. I=20 > > might even be in error and would like to hear, why some=20 > things cann't=20 > > work like depicted. However, I would place more emphasis on=20 > the timely=20 > > recovery of any lost (or > > re-lost) segment, > > over making sure that no single segment is re-transmitted=20 > needlessly;=20 > > better retransmit a little (!) too much too soon, instead=20 > of waiting=20 > > for RTO :) I want to point out the "little" though, as=20 > overwhelming a=20 > > already lossy network with too much retransmissions (ie.=20 > Setting RTO =3D=20 > > 0/1 tick, with a TCP clock runnig in msec), will only cause more=20 > > loss... > >=20 >=20 > I think it is a good idea to detect lost retransmissions and=20 > I think it is possible with SACK. I already proposed a=20 > potential solution ;-) "Just" store highest seq, for each=20 > retransmission. And check incoming SACKs on those. My main=20 > concern is, as already said, that this might get quiet=20 > expensive. But you are free to evaluate this more deeply ;-)=20 > Anyway, maybe we should focus on your other thread... >=20 > Best regards, > Arnd >=20 From ilpo.jarvinen@helsinki.fi Tue Nov 10 19:07:33 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF813A69B9 for ; Tue, 10 Nov 2009 19:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2AwI8Gxmgs4 for ; Tue, 10 Nov 2009 19:07:32 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id A46E13A6900 for ; Tue, 10 Nov 2009 19:07:32 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.11.93]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Nov 2009 05:07:58 +0200 id 00063DE7.4AFA2A8E.0000650B Date: Wed, 11 Nov 2009 05:07:58 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Mark Allman In-Reply-To: <20091109205048.B536759FA3C@lawyers.icir.org> Message-ID: References: <20091109205048.B536759FA3C@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: k.avrachenkov@sophia.inria.fr, tcpm@ietf.org, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:07:33 -0000 On Mon, 9 Nov 2009, Mark Allman wrote: > > We believe we have addressed all comments we received on the early > > retranmsit ID. I just went to submit a new version and have missed the > > cut-off. I have set a bit to submit when the system opens again on > > Nov/9. However, until then I put the version I was going to submit here > > ... > > > > http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt > > > > Comments are very welcome. > > Since TCPM is not meeting this week Lars got this draft approved for > posting. So, it is now at the usual place (as "-02" not "-02a). > > Our hit is that it seems finished. Please yell if there is more to do. My wish is that it would be slightly more explicit in how to handle a FIN (only) segment. Through intuition I'd say it is included to ownd and oseg but that not mentioned I think. I suppose this flow termination is relatively significant case when considering benefits of early rexmit. The confusion is further reinforced by the example in 3.3 (case 2): 1. 3-way handshake, connect() returns. 2. App sends two "data segments" as per IW=2 using write(), they go deep in the stack right away as there is room for that (with IW=1 there wouldn't be any reordering possibility so it has to IW=2 or larger!) 3. write() call returns 4. close() is called 5. FIN only segment needs to be sent ... This third segment does not match to the behavior described in the ID at all? ...It would probably be already quite much to address this if just this worst case example is converted to have a single data segment and a FIN only segment (with persistent reordering between them). -- i. From matt.mathis@gmail.com Tue Nov 10 20:58:41 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B7A28C276 for ; Tue, 10 Nov 2009 20:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmj6LCi4RntO for ; Tue, 10 Nov 2009 20:58:40 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 5A9B028C266 for ; Tue, 10 Nov 2009 20:58:40 -0800 (PST) Received: by bwz23 with SMTP id 23so707429bwz.29 for ; Tue, 10 Nov 2009 20:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3IRkzy7YMh1mzwN7O+fb3+xK0jod+9K+UGyFnCelQTo=; b=NFrh5LyCO708ZJmgueicGcyJ+OewtTEDSbztT7gFG58+hV9kgrFmbRjGaTHUo36OZF Eu7I2wKwDclxw4s+lTNaNGI3pDUGMBM3hwFWfKSWNjIedPtcE4J2xnnmeqn0I5oo1ufL WjymBuShGq0ejsip3utnVEEn8Ingg2HEfwQ58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=K7ctc3GnmVzh9X3Lpc5B/n/MBdHg+cLpfcpV35XwLKY//wpIh3aA39I4EGYbxNrCg9 dxC01+mwQi8xofGxg3Xq9FMz3RKi4RP9l9DMqOzUD6z160OwN8PLIxtYkGWP5bO7VsYs asCeC8l+KpSXr/3c+yTIM5y2oMhFDlDV8kc2c= MIME-Version: 1.0 Sender: matt.mathis@gmail.com Received: by 10.204.152.27 with SMTP id e27mr927891bkw.192.1257915543577; Tue, 10 Nov 2009 20:59:03 -0800 (PST) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0649172D@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0649172D@LDCMVEXC1-PRD.hq.netapp.com> Date: Tue, 10 Nov 2009 23:59:03 -0500 X-Google-Sender-Auth: a8ac9c335d24338d Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" , carsten.wolff@rwth-aachen.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeff Semke , tcpm Extensions WG , Jamshid Mahdavi Subject: Re: [tcpm] Curiosity about draft-mathis-tcp-ratehalving X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:58:42 -0000 We abandoned Rate-Halving because we encountered a problem that we were not able to overcome at the time. It performs very poorly when you have bursty applications. Unfortunately the very feature which causes this problem came to be mandated by 2581 and is now entrenched in 10 years of other congestion control standards. This is part of the reason that with large multi core systems, it is hard to get a single TCP stream to run at really high speeds when there is much load on the CPUs. Todays TCP implementations all suffer badly if the sender frequently stalls due to running out of data, even for fractional RTTs (e.g, waiting for the scheduler or a disk seek.) The problem comes from setting cwnd to half the flight_size, even if the flight size was depressed for reasons unrelated to congestion control. This and other algorithms (e.g. some of the burst suppression stuff) couple fine grained (less then 1 RTT) events to congestion control where they potentially have impact lasting for thousands of RTTs. As far as I am concerned this is wrong and has always been wrong. This coupling is an intrinsic property of rate halving. At the time the draft stalled we were looking for a way to gracefully prevent the new cwnd from going below old_cwnd/2, without upsetting people if flight_size was already below cwnd/2 (This condition implies no window adjustment during recovery). Now more than 10 years later I think I understand the right answer. TCP congestion control needs to be reparameterized, with different control variables. This would require ripping out and replacing most of the current congestion control code. All of the old problems still need to be solved, but under the new parameterization the algorithms would become much simpler and probably better behaved. This is a lot more effort than a simple update of rate-halving or some other document. The Relentless/TCP-unfriendly stuff touches on it, however they are really orthogonal problems. Feel free to re-open the rate-halving draft. There is no formal process: take the existing document and edit it. You might check to see if there were any changes posted to http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt that don't appear in the last IETF draft. If the other original authors (cc'd above) don't choose to participate, their effort should be mentioned in the acknowledgement section. I would like to be included as an author, however I can only invest extremely limited time and energy. If you do reopen the document, I would like it to include some version of the above discussion. Thanks, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. On Mon, Nov 9, 2009 at 7:09 PM, Scheffenegger, Richard wrot= e: > > Hello Carsten, > > This is a very good question indeed. > > Keeping the ACK clock running, and avoiding bursts of segments delivered > all at once in a single burst to a L2 LAN network is something > where my interests are too... (as todays hosts are increasingly capable > of oversaturating slightly dated network equipment with full wire speed > traffic). > > Is there a procedure to revive / adopt a dead draft? > > I have not spent much time on this issue, but noted the burst behavior > After fastretransmit. > > > As RateHalving extended the scope of Limited Transmit (with the similar > goal), shouldn't this be discussed for inclusion in a RFC 3042bis? > > Since certain other congestion algorithms have a beta of less than 0.5 > (ie. BIC, CUBIC use 0.8) when selecting a new ssthresh, perhaps the > effect > of RateHalfing, but with 2 out of 3 (0.66) policy or 3 out of 4 (0.75) > at the end of the RTT should be investigated? (To be less conservative > When reducing the sending rate). > > One extension to the draft might be the discussion on how to deal with > RFC 3465 (ABC) during rate halving; with SACK, ABC could still be > employed, > And a new segment triggered only, when 2*MSS has been covered by the new > SACKs... > > Regards, > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > * =A0 =A0 =A0 To: Matt Mathis >> > * =A0 =A0 =A0 Subject: [tcpm] Curiosity about draft-mathis-tcp-ratehalvin= g > * =A0 =A0 =A0 From: Carsten Wolff > > * =A0 =A0 =A0 Date: Wed, 4 Nov 2009 13:48:51 +0100 > =A0_____ > > Hello Matt, everyone, > > I'm curious about draft-mathis-tcp-ratehalving > (http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt) and why > it > never exceeded version 00 and expired years ago. It seems, several of > the > ideas (fack, ratehalving, the concept of rhcwnd) in this paper made it > into > the Linux TCP implementation in some form, which means they're part of a > big > chunk of today's web servers and other Internet hosts. Why has there > been no > interest in taking this draft further? > > Cheers, > Carsten > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ilpo.jarvinen@helsinki.fi Wed Nov 11 00:31:58 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB4F3A6B8A for ; Wed, 11 Nov 2009 00:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjHyZqImjjOy for ; Wed, 11 Nov 2009 00:31:57 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id B0CD23A6AAD for ; Wed, 11 Nov 2009 00:31:57 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.11.93]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Nov 2009 10:32:24 +0200 id 00063DE7.4AFA7698.00001374 Date: Wed, 11 Nov 2009 10:32:24 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: "Scheffenegger, Richard" In-Reply-To: <5FDC413D5FA246468C200652D63E627A065D0E76@LDCMVEXC1-PRD.hq.netapp.com> Message-ID: References: <5FDC413D5FA246468C200652D63E627A065D0E76@LDCMVEXC1-PRD.hq.netapp.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Detect Lost Retransmit with SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:31:58 -0000 I have couple of points to add into this thread but my inbox is a bit of a mess at the moment and I really don't know what point into this thread to intervene, so I'll just spell them out without quoting anything.... 1) You are partially right. Assuming in-order behavior it is possible for the sender to fully construct the sequence of receival that too place using SACK (+DSACK) infromation (expect for the ambiguous gaps caused by ACK losses). By using this one could run dupThresh-like check for any segment regardless of it being retransmission or not, which is what I think you are trying to accomplish here. However, with reordering it gets rather challenging when there is ambiguity present. 2) And even if reordering is assumed to not be there, keeping track of that ordering used at the sending sides and efficiently accessing all necessary state in non O(n^2) fashion is, well, a challenging task and it is much easier to take a shortcut. The easiest is already mentioned by somebody (use only new data SACK blocks), and even then there are per segment processing time challenges as was brought up. 3) Linux has implemented that shortcut approach for ages, however, unfortunately the (obsolete) versions of Linux you have been using in your test contain bugs which prevent lost retransmission detection from working efficiently. It was fixed in some 2.6.25 timeframe but that is already so far away that it is hard to remember exactly. 4) Even the latest kernels do not perform lost retransmission detection as efficiently as I'd want to (I have some local patches to solve that but no timeline for submitting them), ie., it cannot keep operating with 1Gbps speeds for long periods of time if operating with non-trivial RTTs (see my recent paper in PFLDnet for the details). 5) Lost retransmission detection in Linux works only with FACK mode, and there's automatic switching from FACK to RFC 3517 mode if reordering is detected so please be careful to not cause reordering symptoms with your test tricks (I'm not trying to imply here that you'd be doing that). -- i. From Alexander.Zimmermann@nets.rwth-aachen.de Wed Nov 11 00:34:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B8B28C10B for ; Wed, 11 Nov 2009 00:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+qyUgp0dmr7 for ; Wed, 11 Nov 2009 00:34:46 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 0FDDC28C2DB for ; Wed, 11 Nov 2009 00:33:48 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSX00H21RT2M260@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 09:34:15 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,722,1249250400"; d="scan'208";a="33322030" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 11 Nov 2009 09:34:11 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSX00LW0RSYTH70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 09:34:10 +0100 (CET) From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A065D0FB3@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 11 Nov 2009 09:34:11 +0100 Message-id: References: <5FDC413D5FA246468C200652D63E627A065D0FB3@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org WG Extensions" Subject: Re: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:34:48 -0000 Hi Richard, it is done. I'm completely lost in the double threaded tread. I really suggest we stop this ping-pong discussion, since IHMO nobody can follow us.... My suggestion is that you * start to write a little ID with at least a pseudo code algo * and a lot of *well indented* examples like Ilpo does in his ID => Basic Case, multiple (burst) loss, ACK loss, reordering, packet duplication,... With such a document, it will be much more easier to follow your thoughts. What do you think? Alex Am 10.11.2009 um 19:28 schrieb Scheffenegger, Richard: > > See inline > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > > >> -----Original Message----- >> From: Arnd Hannemann [mailto:hannemann@i4.informatik.rwth-aachen.de] >> Sent: Dienstag, 10. November 2009 17:43 >> To: Scheffenegger, Richard >> Cc: Alexander Zimmermann; tcpm@ietf.org >> Subject: Re: Detect Lost Retransmit mit SACK >> >> Hi Richard, >> >> >> Scheffenegger, Richard schrieb: > :: >>> >>> A1) With TSOpt, they could be used to "remember" when >>> Retransmission started; >>> When an ACKs with TSEcn > (TSOpt + RTT) is seen by >>> the sender, it can >>> re-arm the DUPACK detector. >> >> This is your non-SACK scenario? >> Please note that a TCP receiver will NOT echo TSVal from >> out-of-order segments. So this won't work. > > Interesting; this doesn't seem to be what certain (most?) stacks are > doing - they seem to always reply in the ACK Tsecr the value of > Tsopt/TS.recent > triggering the ACK... > > Or was your intention to say, that the receiver will not respond with > Tsopt, but rather TS.recent? > > If so, than this makes no difference - the sender will detect the > first ACK from the receiver, which has the same TS (well, actually TS+1 > as multiple segments are likely to carry the same TS) when the > retransmission > was started. This will be the sign for the sender, that at least one RTT > has elapsed (that was the intention for having timestamps in the first > place, right?). If the returned ACK does not cover the first > retransmitted > segment by that time, it's quite reasonable to assume that it got lost > again. > > Again, keep in mind that I'm looking on LANs; a TS in 10 ms increments > (100 Hz > TCP clock) is likely to be put into a few hundred or thousand packets... > > If there is reason to believe the reordering can occur with delays >> > RTT, then > Yes, this simple detection logic would be fooled and falsely trigger a > retransmission. > > However, IF the reordering is >> 2*RTT, then it's very likely that the > newly retransmitted segment arrives at the receiver first (over the > faster > path), and again this would only serve to keep the application visible > latency > as low as possible (between the points in time, where TCP can deliver > some / any > new data up the stack...) > > > >>> A2) With SACK, tracking SND.NXT and HOLEBYTES (number of >>> octets in all current holes) >>> can be employed to track RTT (they need to be >>> initialized when the first >>> retransmitted segment is sent). When an ACK contains >>> a SACK for >= SND.NXT, or the >>> HOLEBYTES are smaller than when retransmission started, the >>> DUPACK detector can be re-armed. >> >> You should specify what you mean with SND.NXT. >> We are in recovery, so we may very well send out new segments. >> I don't see why number of holes in sack scoreboard has >> anything todo with RTT. > > > SND.NXT is the rightmost segment which the sender has never before > sent out to the network. Isn't that the meaning of Snd.nxt according > to RFC793? > > And I was not talking about the # of holes, but rather the amount of > Data (in sum) between FACK (defined by the rightmost offset in the SACK > Scoreboard, i.e. covering the highest ever received segment) and > SND.UNA. > > Monitoring Holes will gain nothing (when there is reordering for > example); > > But if the any one retransmission makes it though, the amount of > unSACKed > data in the sum total of all holes in the scoreboard, will decrease - > indicating when at least one RTT has passed since start of > FastRetransmit. > > > >> >>> >>> A3) If neither TSOpt nor SACK is used, revert to current behavior >>> (RTO timeout to >>> detect a lost retransmit). >>> >>> B) DUPACK detector would need to be enhanced over what is >> currently in >>> the RFCs (but >>> I think most of that is already in Drafts, ie. >>> >>> >> http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01 >>> ). >>> >>> B1) With SACK enabled, fully duplicate ACKs (ACK and SACK >> have been >>> seen before, and >>> prev_HOLEBYTES == HOLEBYTES) can be discarded; lost ACKs would >>> count for two >>> (prev_HOLEBYTES < HOLEBYTES - SMSS). >> >> Now B1 is SACK enabled scenario? You try to confuse me, right? >> All this makes little sense to me. > > > I agree, it would have made sense to label points B1 and B2 the other > way > around to stay more consistent; that's one of the reasons why I like to > discuss this :) > >> >>> >>> B2) With TSOpt, if another RTT passes without advancing SND.UNA, >>> increase DupAcks += DupThresh >>> >>> When DupThresh # of ACKs are received, reset HighRxt = SND.UNA, >>> DupAcks = 0; *) >> >> See above... >> non-SACK is not going to work. > > > See above - TSOpt is only used for the prime purpose to detect when a > RTT has passed. It doesn't matter if Tsecr contains TSopt or > TS.recent... > >> >>> There are two comments I would like to make: >>> >>> A) Latency: if the sender first sends out the entire range >> of holes, >>> before >>> reacting to a detectable lost retransmitted packet, the latency >>> observed >>> by the application on the receiver side will increase >> needlessly. >>> It might >>> take a number of RTTs under certain circumstances, >> before all the >>> holes >>> have been retransmitted once... >> >> Show me an example. where a lost retransmission is >> detectable, while the sender did not send out retransmissions >> for every other hole? >> Sounds weird. > > Can I attach trace files on posts to this list, or shall I sent them > to you directly? > > I assume that on the receiving side, the application is only delivered > data, which has been ACKed (not SACKed). If the sender waits until > RTO before retrying to re-send a retransmission (sorry about these > Multiple re-s :) ), the application will at least stall (not get any > new data) for RTO+2*RTT - and certain latency sensitive applications > will time out before that. Again: I'm not talking about internet > applications but rather LAN HPC applications with timeouts in the > order of a few seconds at most. > > Advancing (on the receiver) within that application timeout is > Usually enough to not run into the application timeout. > > >> >> >>> >>> B) Complexity: As soon as any congestion event is encountered, TCP >>> won't be in >>> fastpath mode any longer; the added computational complexity to >>> (reliably, see my >>> check on FACK with Linux 2.6.18 yesterday) trigger another >>> retransmission >>> of an already retransmitted segment is neglegible, compared to >>> current best >>> practise (waiting for RTO), when you need to move data around as >>> quickly (low >>> latency AND high bandwidth) as possible. As mentioned, my >>> background is not >>> so much the global internet (with statistically valid implict >>> assumptions), but >>> rather High-Speed, short Range, (lossy) LANs, with only very few >>> active TCP >>> sessions at any one time. The hosts I deal with might >> have as few >>> as 10-20 TCP >>> sessions, of which only 1-4 are pushing data, but those >> might run >>> over dedicated >>> 10GbE ports (overloading L2 switches in the process, and >> exhibiting >>> Burst Loss >>> (correlated packet loss) ). >> >> This probably highly rates from case to case. If you have a >> huge bandwidth-delay product even SACK scoreboard handling >> will have computational complexity which might outweigh its benefits. >> As you have seem to have the equipment at hand, you could do >> some cpu load and throughput measurements with 10GbE and SACK >> versus non-SACK flows. > > Well, I was doing some test like this: > > http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html > > But the CPU impact (on top of what is required for 10G) was neglegible. > > But I have to admit, I didn't had the time yet to test a SACK scoreboard > with every other byte marked mission (which could mean some 0,5 mio > entries). > > But it seems that most implementations feature sorted scoreboards of > limited > (16/128) size. > > Traversing those is - again in my case of 10G LANs - still many orders > of > magnitude faster then waiting for RTO. > > I personally consider RTOs to be harmful (when there are other means to > recover with). :) (perhaps once I have worked through all the issues > raised > here, I submit a draft with "TCP RTO considered harmful" next April? :) > > >> >> >>> >>> >>> Thus my view might deviate from a "typical" view in certain >> aspects. I >>> might even be in error and would like to hear, why some >> things cann't >>> work like depicted. However, I would place more emphasis on >> the timely >>> recovery of any lost (or >>> re-lost) segment, >>> over making sure that no single segment is re-transmitted >> needlessly; >>> better retransmit a little (!) too much too soon, instead >> of waiting >>> for RTO :) I want to point out the "little" though, as >> overwhelming a >>> already lossy network with too much retransmissions (ie. >> Setting RTO = >>> 0/1 tick, with a TCP clock runnig in msec), will only cause more >>> loss... >>> >> >> I think it is a good idea to detect lost retransmissions and >> I think it is possible with SACK. I already proposed a >> potential solution ;-) "Just" store highest seq, for each >> retransmission. And check incoming SACKs on those. My main >> concern is, as already said, that this might get quiet >> expensive. But you are free to evaluate this more deeply ;-) >> Anyway, maybe we should focus on your other thread... >> >> Best regards, >> Arnd >> // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From hannemann@i4.informatik.rwth-aachen.de Wed Nov 11 00:45:50 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D173A6C48 for ; Wed, 11 Nov 2009 00:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdNtXJPDDYUZ for ; Wed, 11 Nov 2009 00:45:49 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 4107D3A6824 for ; Wed, 11 Nov 2009 00:45:48 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSX00AKASD3GN90@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 09:46:15 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,722,1249250400"; d="scan'208";a="33324178" Received: from relay-2.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.75]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 11 Nov 2009 09:46:15 +0100 Received: from [137.226.12.85] (informatik-4-137-226-12-85.nn.RWTH-Aachen.DE [137.226.12.85] (may be forged)) by relay.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id nAB8kEM1007674 for ; Wed, 11 Nov 2009 09:46:15 +0100 (CET) Message-id: <4AFA79BD.4090200@i4.informatik.rwth-aachen.de> Date: Wed, 11 Nov 2009 09:45:49 +0100 From: Arnd Hannemann User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: tcpm@ietf.org References: <5FDC413D5FA246468C200652D63E627A065D0FB3@LDCMVEXC1-PRD.hq.netapp.com> In-reply-to: <5FDC413D5FA246468C200652D63E627A065D0FB3@LDCMVEXC1-PRD.hq.netapp.com> Subject: Re: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:45:50 -0000 Hi Richard, Scheffenegger, Richard schrieb: >>> A1) With TSOpt, they could be used to "remember" when >>> Retransmission started; >>> When an ACKs with TSEcn > (TSOpt + RTT) is seen by >>> the sender, it can >>> re-arm the DUPACK detector. >>> >> This is your non-SACK scenario? >> Please note that a TCP receiver will NOT echo TSVal from >> out-of-order segments. So this won't work. >> > > Interesting; this doesn't seem to be what certain (most?) stacks are > doing - they seem to always reply in the ACK Tsecr the value of > Tsopt/TS.recent > triggering the ACK... Please clarify, is this non-SACK scenario? The only lost retransmission we could be talking about then, is the retransmission of SND.UNA. And the TCP receiver will NOT adjust TS.recent for any out-of order packets (RFC 1323). It will continue to echo the timestamp of the last segment which advanced the window (SND.UNA -1p). > Or was your intention to say, that the receiver will not respond with > Tsopt, but rather TS.recent? Yes, it will not respond with TSVal but with TS.recent. > If so, than this makes no difference - the sender will detect the > first ACK from the receiver, which has the same TS (well, actually TS+1 > as multiple segments are likely to carry the same TS) when the > retransmission There won't be an ACK if the retransmission is lost in non-SACK case, only dupACKs. (Only retransmission is retransmission of SND.UNA) TS.Recent will not get updated. > was started. This will be the sign for the sender, that at least one RTT > has elapsed (that was the intention for having timestamps in the first > place, right?). If the returned ACK does not cover the first > retransmitted > segment by that time, it's quite reasonable to assume that it got lost > again > > Again, keep in mind that I'm looking on LANs; a TS in 10 ms increments If you are searching for something which is not intended for general use, why not just set MIN_RTO to say 10 ms? >>> A2) With SACK, tracking SND.NXT and HOLEBYTES (number of >>> octets in all current holes) >>> can be employed to track RTT (they need to be >>> initialized when the first >>> retransmitted segment is sent). When an ACK contains >>> a SACK for >= SND.NXT, or the >>> HOLEBYTES are smaller than when retransmission started, the >>> DUPACK detector can be re-armed. >>> >> You should specify what you mean with SND.NXT. >> We are in recovery, so we may very well send out new segments. >> I don't see why number of holes in sack scoreboard has >> anything todo with RTT. >> > > > SND.NXT is the rightmost segment which the sender has never before > sent out to the network. Isn't that the meaning of Snd.nxt according > to RFC793? Hmm, I would interpret RFC793 differently. I would call it SND.MAX (see RFC4015) or HighData (RFC3517) the rightmost segment which the sender has never sent before. But now you have to clarify how it would be possible to receive a SACK block > SND.MAX. Even SACK block == SND.MAX will be rarely seen. But before taking this discussion even further, maybe take some time and write some preliminary draft of your algorithm. > And I was not talking about the # of holes, but rather the amount of > Data (in sum) between FACK (defined by the rightmost offset in the SACK > Scoreboard, i.e. covering the highest ever received segment) and > SND.UNA. > > Monitoring Holes will gain nothing (when there is reordering for > example); > > But if the any one retransmission makes it though, the amount of > unSACKed > data in the sum total of all holes in the scoreboard, will decrease - > indicating when at least one RTT has passed since start of > FastRetransmit. This is not true. Consider a 100 packet in flight, you get 3 dupacks, do a retransmission. This is in your words "start of FastRetransmit". After this the sum total of all holes between SND.UNA and FACK can only increase for one RTT. Due to Limited Transmit and Fast Recovery, it might be possible that even the sum total of all holes between SND.UNA and SND.MAX will increase. You know when the first Retransmit is lost when a SACK covers RecoveryPoint (RFC3517). But this is only true for first hole. To detect lost retransmissions of the other holes, you would need to store a separate HighData (RFC3617) for every retransmission. Maybe this is after all what you are trying to express? Perhaps it would be helpful if you could cook up some pseudo code, of your proposed algorithm. >> >>> holes >>> have been retransmitted once... >>> >> Show me an example. where a lost retransmission is >> detectable, while the sender did not send out retransmissions >> for every other hole? >> Sounds weird. >> > > Can I attach trace files on posts to this list, or shall I sent them > to you directly? Never mind, does not actually matter. >>> >> This probably highly rates from case to case. If you have a >> huge bandwidth-delay product even SACK scoreboard handling >> will have computational complexity which might outweigh its benefits. >> As you have seem to have the equipment at hand, you could do >> some cpu load and throughput measurements with 10GbE and SACK >> versus non-SACK flows. >> > > Well, I was doing some test like this: > > http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html > > But the CPU impact (on top of what is required for 10G) was neglegible. > But I have to admit, I didn't had the time yet to test a SACK scoreboard > with every other byte marked mission (which could mean some 0,5 mio > entries). > > But it seems that most implementations feature sorted scoreboards of > limited > (16/128) size. > > Traversing those is - again in my case of 10G LANs - still many orders > of > magnitude faster then waiting for RTO. > > I personally consider RTOs to be harmful (when there are other means to > recover with). :) (perhaps once I have worked through all the issues > raised > here, I submit a draft with "TCP RTO considered harmful" next April? :) Better submit a draft to mitigate the problems with it ;-) Best regards, Arnd From alexander.zimmermann@nets.rwth-aachen.de Wed Nov 11 05:12:48 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CD128C323 for ; Wed, 11 Nov 2009 05:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.12 X-Spam-Level: X-Spam-Status: No, score=-4.12 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9v0I4AzAsWW for ; Wed, 11 Nov 2009 05:12:46 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 424B828C31B for ; Wed, 11 Nov 2009 05:12:46 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSY004YM4Q0AEF0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 14:13:12 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,723,1249250400"; d="scan'208";a="18148778" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 11 Nov 2009 14:13:12 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSY0097S4Q09S30@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 14:13:12 +0100 (CET) From: Alexander Zimmermann In-reply-to: Date: Wed, 11 Nov 2009 14:13:13 +0100 Message-id: References: <5FDC413D5FA246468C200652D63E627A0649172D@LDCMVEXC1-PRD.hq.netapp.com> To: Matt Mathis X-Mailer: Apple Mail (2.1077) Cc: Jamshid Mahdavi , tcpm Extensions WG , Jeff Semke Subject: Re: [tcpm] Curiosity about draft-mathis-tcp-ratehalving X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:12:48 -0000 Hi Matt, thanks for the quick answer. Carsten and I stumbled upon rate halving during our investigation how Linux TCP handles segment reordering. Since we currently don't want to skip our primary goal, I want to figure out if we could/should reanimate the ID with respect to men power, etc. Am 11.11.2009 um 05:59 schrieb Matt Mathis: > We abandoned Rate-Halving because we encountered a problem that we > were not able to overcome at the time. It performs very poorly when > you have bursty applications. Unfortunately the very feature which > causes this problem came to be mandated by 2581 and is now entrenched > in 10 years of other congestion control standards. Ok, I see. However, but why is it not possible to do a step by step approach. Rate halving reduces TCP burstyness during recovery and IMHO it is a valuable feature, more straight forward then artificially inflating/deflating. Fixing the poor TCP performance in case of bursty applications can be seen as another step. > > This is part of the reason that with large multi core systems, it is > hard to get a single TCP stream to run at really high speeds when > there is much load on the CPUs. Todays TCP implementations all suffer > badly if the sender frequently stalls due to running out of data, even > for fractional RTTs (e.g, waiting for the scheduler or a disk seek.) Is this different on a single core? I mean if my TCP doesn't get enough CPU time on my single core, I cannot send with high speed, too. > > The problem comes from setting cwnd to half the flight_size, even if > the flight size was depressed for reasons unrelated to congestion > control. Ok, but what can we do? As RFC 2861 describes, we can only know about the current BDP if we are not application (or similarly) limited. Do you want do move away from AIMD? > This and other algorithms (e.g. some of the burst suppression > stuff) couple fine grained (less then 1 RTT) events to congestion > control where they potentially have impact lasting for thousands of > RTTs. As far as I am concerned this is wrong and has always been > wrong. > > This coupling is an intrinsic property of rate halving. At the time > the draft stalled we were looking for a way to gracefully prevent the > new cwnd from going below old_cwnd/2, without upsetting people if > flight_size was already below cwnd/2 (This condition implies no window > adjustment during recovery). > > Now more than 10 years later I think I understand the right answer. > TCP congestion control needs to be reparameterized, with different > control variables. Which variables/parameter do you have in mind? > This would require ripping out and replacing most > of the current congestion control code. All of the old problems still > need to be solved, but under the new parameterization the algorithms > would become much simpler and probably better behaved. This is a lot > more effort than a simple update of rate-halving or some other > document. The Relentless/TCP-unfriendly stuff touches on it, however > they are really orthogonal problems. > > Feel free to re-open the rate-halving draft. There is no formal > process: take the existing document and edit it. You might check to > see if there were any changes posted to > http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt that > don't appear in the last IETF draft. If the other original authors > (cc'd above) don't choose to participate, their effort should be > mentioned in the acknowledgement section. I would like to be included > as an author, however I can only invest extremely limited time and > energy. > > If you do reopen the document, I would like it to include some version > of the above discussion. > > Thanks, > --MM-- > ------------------------------------------- > Matt Mathis http://staff.psc.edu/mathis > Work:412.268.3319 Home/Cell:412.654.7529 > ------------------------------------------- > Evil is defined by mortals who think they know > "The Truth" and use force to apply it to others. > > > > On Mon, Nov 9, 2009 at 7:09 PM, Scheffenegger, Richard wrote: >> >> Hello Carsten, >> >> This is a very good question indeed. >> >> Keeping the ACK clock running, and avoiding bursts of segments delivered >> all at once in a single burst to a L2 LAN network is something >> where my interests are too... (as todays hosts are increasingly capable >> of oversaturating slightly dated network equipment with full wire speed >> traffic). >> >> Is there a procedure to revive / adopt a dead draft? >> >> I have not spent much time on this issue, but noted the burst behavior >> After fastretransmit. >> >> >> As RateHalving extended the scope of Limited Transmit (with the similar >> goal), shouldn't this be discussed for inclusion in a RFC 3042bis? >> >> Since certain other congestion algorithms have a beta of less than 0.5 >> (ie. BIC, CUBIC use 0.8) when selecting a new ssthresh, perhaps the >> effect >> of RateHalfing, but with 2 out of 3 (0.66) policy or 3 out of 4 (0.75) >> at the end of the RTT should be investigated? (To be less conservative >> When reducing the sending rate). >> >> One extension to the draft might be the discussion on how to deal with >> RFC 3465 (ABC) during rate halving; with SACK, ABC could still be >> employed, >> And a new segment triggered only, when 2*MSS has been covered by the new >> SACKs... >> >> Regards, >> >> Richard Scheffenegger >> Field Escalation Engineer >> NetApp Global Support >> NetApp >> +43 1 3676811 3146 Office (2143 3146 - internal) >> +43 676 654 3146 Mobile >> www.netapp.com >> Franz-Klein-Gasse 5 >> 1190 Wien >> >> * To: Matt Mathis >>> >> * Subject: [tcpm] Curiosity about draft-mathis-tcp-ratehalving >> * From: Carsten Wolff > > >> * Date: Wed, 4 Nov 2009 13:48:51 +0100 >> _____ >> >> Hello Matt, everyone, >> >> I'm curious about draft-mathis-tcp-ratehalving >> (http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt) and why >> it >> never exceeded version 00 and expired years ago. It seems, several of >> the >> ideas (fack, ratehalving, the concept of rhcwnd) in this paper made it >> into >> the Linux TCP implementation in some form, which means they're part of a >> big >> chunk of today's web servers and other Internet hosts. Why has there >> been no >> interest in taking this draft further? >> >> Cheers, >> Carsten >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From alexander.zimmermann@nets.rwth-aachen.de Wed Nov 11 06:05:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B1628C251 for ; Wed, 11 Nov 2009 06:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.233 X-Spam-Level: X-Spam-Status: No, score=-4.233 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKUQRB2dq21m for ; Wed, 11 Nov 2009 06:05:54 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 12E1528C184 for ; Wed, 11 Nov 2009 06:05:54 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KSY00J3P76L39A0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 15:06:21 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,723,1249250400"; d="scan'208";a="33384767" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 11 Nov 2009 15:06:21 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KSY0094L76L9S40@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 11 Nov 2009 15:06:21 +0100 (CET) From: Alexander Zimmermann In-reply-to: <20091027143025.C6B8B55F005@lawyers.icir.org> Date: Wed, 11 Nov 2009 15:06:22 +0100 Message-id: References: <20091027143025.C6B8B55F005@lawyers.icir.org> To: "mallman@icir.org" X-Mailer: Apple Mail (2.1077) Cc: "k.avrachenkov@sophia.inria.fr" , "tcpm@ietf.org" , "jblanton@cs.ohiou.edu" Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:05:55 -0000 Hi Mark, here my *** Comments: * Line 150-153. On Joe's request, you added some lines about ACK compression... Ah sorry, Delay ACKs ;-). The first new sentence is fine and IMHO sufficient. The second one confuse me (a litte bit). Why do you write "we assume that receivers send immediate ACKs when there is a gap in the received sequence space"? If a TCP would not send a DUPACK directly when OOO segment is received, Early Rexmit wouldn't work? Maybe one or two sentence more could me "un-puzzle". * Line 252-253. 'We call this reduced ACK threshold enabling "Early Retransimission"'. Maybe it's my limited english knowledge, you are the native speaker, but IMHO the sentence sounds strange. What about this: "We call this reduced duplicate ACK threshold "Early Retransmit". * Line 222-224. In my last review I mentioned that we could probably better specify the "entry point" of the algorithm. Example: Upon the arrival of an ACK, a sender employing byte-based Early Retransmit MUST use the following two conditions to determine when an Early Retransmit is sent: * Line 226. Concerning Joe's question where magic *4* comes from. What do you think about this? (2.a) The amount of outstanding data (ownd)---data sent but not yet acknowledged---is less or equal than 3*SMSS bytes, where is the lower bound of DupThresh from [RFC5681, RFC3517]. Mark, the last two point are really peanuts. If you don't like them, skip them. *** Nits: Missing Reference: 'RFC4653' is mentioned on line 419, but not defined There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. *** Misspellings: Line 91: s/implemention/implementation Line 253: s/Retransimission/Retransmission (I know that it was Joe's misspelling ;-)) Line 312: s/Retransimission/Retransmission Am 27.10.2009 um 15:30 schrieb Mark Allman: > > We believe we have addressed all comments we received on the early > retranmsit ID. I just went to submit a new version and have missed the > cut-off. I have set a bit to submit when the system opens again on > Nov/9. However, until then I put the version I was going to submit here > ... > > http://www.icir.org/mallman/papers/draft-ietf-tcpm-early-rexmt-02a.txt > > Comments are very welcome. > > allman > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From mallman@icir.org Wed Nov 11 08:21:42 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC8C3A6973 for ; Wed, 11 Nov 2009 08:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35bAXARHriSv for ; Wed, 11 Nov 2009 08:21:41 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id B7AA53A68FF for ; Wed, 11 Nov 2009 08:21:41 -0800 (PST) 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 nABGLvaH014521; Wed, 11 Nov 2009 08:21:57 -0800 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 892C23E6A592; Wed, 11 Nov 2009 11:21:52 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 76DA15A46F5; Wed, 11 Nov 2009 11:21:51 -0500 (EST) To: Alexander Zimmermann From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58525-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Nov 2009 11:21:51 -0500 Sender: mallman@icir.org Message-Id: <20091111162151.76DA15A46F5@lawyers.icir.org> Cc: "tcpm@ietf.org" , "k.avrachenkov@sophia.inria.fr" , "jblanton@cs.ohiou.edu" Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 16:21:42 -0000 ----------ma58525-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > * Line 150-153. On Joe's request, you added some lines about ACK compression... > Ah sorry, Delay ACKs ;-). The first new sentence is fine and IMHO > sufficient. The second one confuse me (a litte bit). Why do you write > "we assume that receivers send immediate ACKs when there is a gap in > the received sequence space"? If a TCP would not send a DUPACK > directly when OOO segment is received, Early Rexmit wouldn't work? > Maybe one or two sentence more could me "un-puzzle". I don't follow this. The point here is that delayed ACKs could perhaps reduce the number of ACKs the sender gets back. But, a counter-point (per RFC5681) is that when ACKing out-of-order arrivals the receiver SHOULD NOT be using delayed ACKs. I just read the text a few times and I think it is OK. But, I might be too close to it and so am open to suggestions. > * Line 252-253. 'We call this reduced ACK threshold enabling "Early > Retransimission"'. Maybe it's my limited english knowledge, you are > the native speaker, but IMHO the sentence sounds strange. What about > this: "We call this reduced duplicate ACK threshold "Early > Retransmit". This language was added for Joe. I don't think it is either necessary or harmful. And, I am not going to get into making excessively small tweaks to it. > * Line 222-224. In my last review I mentioned that we could probably better > specify the "entry point" of the algorithm. Example: > > Upon the arrival of an ACK, a sender employing byte-based Early > Retransmit MUST use the following two conditions to determine > when an Early Retransmit is sent: OK. > * Line 226. Concerning Joe's question where magic *4* comes from. What do you > think about this? > > (2.a) The amount of outstanding data (ownd)---data sent but not yet > acknowledged---is less or equal than 3*SMSS bytes, where is > the lower bound of DupThresh from [RFC5681, RFC3517]. I didn't address this directly because I think it is clear from the entire document why the number is what it is. And, as I understood it this was a minor comment from Joe. The above suggested sentence does not parse for me. > Missing Reference: 'RFC4653' is mentioned on line 419, but not defined Added. > *** Misspellings: > Line 91: s/implemention/implementation > Line 253: s/Retransimission/Retransmission (I know that it was Joe's misspelling ;-)) > Line 312: s/Retransimission/Retransmission Fixed. I know the chairs are getting ready to forward this. I can send off another version just before they do that encompasses this and any other feedback folks want to send. Thanks! allman ----------ma58525-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkr65J4ACgkQWyrrWs4yIs63IwCglsUXmyv4HghZ6GVLhTinS7GP NZYAnRDaRuQxLxxS/h88TYSfG/y6VYsm =pb8S -----END PGP SIGNATURE----- ----------ma58525-1-- From mallman@icir.org Wed Nov 11 09:47:05 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C533A6877 for ; Wed, 11 Nov 2009 09:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4KsG8v8sisX for ; Wed, 11 Nov 2009 09:47:05 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 0DEB03A677D for ; Wed, 11 Nov 2009 09:47:05 -0800 (PST) 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 nABHkVnU016670; Wed, 11 Nov 2009 09:46:32 -0800 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 633D13E6AAA8; Wed, 11 Nov 2009 12:46:27 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6854B5A493B; Wed, 11 Nov 2009 12:46:26 -0500 (EST) To: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma63602-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Nov 2009 12:46:26 -0500 Sender: mallman@icir.org Message-Id: <20091111174626.6854B5A493B@lawyers.icir.org> Cc: tcpm@ietf.org, k.avrachenkov@sophia.inria.fr, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 17:47:05 -0000 ----------ma63602-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > My wish is that it would be slightly more explicit in how to handle a > FIN (only) segment. So, the issue here is that a FIN with no data could be useful for ER? So, ... (1) You send two data packets plus a pure FIN. (2) Lose the second data packet. (3) Get a cumulative ACK for the first data packet. (4) Get a FIN-triggered duplicate ACK. At this point the sender will think there is one outstanding segment and set the dupthresh to zero and so not really useful in using the dupack as a trigger for a retransmit. I basically don't see anything to be done here short of making the sender explicitly track that a pure FIN is outstanding. My inclination here is that this is enough of a corner case that the document is fine how it is. (Note in the particular scenario you played out the TCP implementation may or may not send a payload-less FIN. Depending on the timing and etc. it could well be tacked on the second data packet.) That said, if the WG thinks it is important to address this corner case at the last minute then we will obviously do so. allman ----------ma63602-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkr6+HIACgkQWyrrWs4yIs54wACfesKYTHgeyWFyZIPKAjvPPGuv 3IIAoJQ1HQfTbg0TURB2dnsLUCAFtYbA =qV/6 -----END PGP SIGNATURE----- ----------ma63602-1-- From ilpo.jarvinen@helsinki.fi Wed Nov 11 17:19:16 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957463A6AC8 for ; Wed, 11 Nov 2009 17:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWnwIkCL4N4K for ; Wed, 11 Nov 2009 17:19:15 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id AFEB33A63C9 for ; Wed, 11 Nov 2009 17:19:15 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.11.93]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 12 Nov 2009 03:19:42 +0200 id 00063EBC.4AFB62AE.00002152 Date: Thu, 12 Nov 2009 03:19:42 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Mark Allman In-Reply-To: <20091111174626.6854B5A493B@lawyers.icir.org> Message-ID: References: <20091111174626.6854B5A493B@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, k.avrachenkov@sophia.inria.fr, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:19:16 -0000 On Wed, 11 Nov 2009, Mark Allman wrote: > > My wish is that it would be slightly more explicit in how to handle a > > FIN (only) segment. > > So, the issue here is that a FIN with no data could be useful for ER? Yes. > So, ... > > (1) You send two data packets plus a pure FIN. > > (2) Lose the second data packet. > > (3) Get a cumulative ACK for the first data packet. > > (4) Get a FIN-triggered duplicate ACK. > > At this point the sender will think there is one outstanding segment and > set the dupthresh to zero and so not really useful in using the dupack > as a trigger for a retransmit. Is it really that well defined that pure FINs are not "segments"? Probably this too is implementation dpeending whether outstanding segments (already) include FIN or not. > I basically don't see anything to be done here short of making the > sender explicitly track that a pure FIN is outstanding. My guess is that most of the implentations will know this already (indirectly if not even directly). Nevertheless, I don't see what is the harm if FIN is included to "outstanding" segments/sequences. > My inclination here is that this is enough of a corner case that the > document is fine how it is. ...and you still boldly claim in the intro that "A particular case when all connections become application limited is as the connection ends"? :-) > (Note in the particular scenario you played > out the TCP implementation may or may not send a payload-less FIN. > Depending on the timing and etc. it could well be tacked on the second > data packet.) That's certainly possible yes. But I would argue that if early retransmit would be made useful here, short transfers would greatly benefit from sending it separately because of the increased likelyhoods of avoiding RTO at the end which is very significant for their latency. > That said, if the WG thinks it is important to address > this corner case at the last minute then we will obviously do so. -- i. From mallman@icir.org Wed Nov 11 18:29:26 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB1F28C1AC for ; Wed, 11 Nov 2009 18:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiPg7dhkBE3s for ; Wed, 11 Nov 2009 18:29:25 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 5368028C1AB for ; Wed, 11 Nov 2009 18:29:25 -0800 (PST) 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 nAC2T0q4030611; Wed, 11 Nov 2009 18:29:00 -0800 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 6FB5E3E6CC85; Wed, 11 Nov 2009 21:28:55 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 551105A5144; Wed, 11 Nov 2009 21:28:53 -0500 (EST) To: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma29410-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Nov 2009 21:28:53 -0500 Sender: mallman@icir.org Message-Id: <20091112022853.551105A5144@lawyers.icir.org> Cc: k.avrachenkov@sophia.inria.fr, tcpm@ietf.org, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:29:26 -0000 ----------ma29410-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > So, ... > > > > (1) You send two data packets plus a pure FIN. > > > > (2) Lose the second data packet. > > > > (3) Get a cumulative ACK for the first data packet. > > > > (4) Get a FIN-triggered duplicate ACK. > > > > At this point the sender will think there is one outstanding segment and > > set the dupthresh to zero and so not really useful in using the dupack > > as a trigger for a retransmit. > > Is it really that well defined that pure FINs are not "segments"? I didn't mean to say or indicate that. > > I basically don't see anything to be done here short of making the > > sender explicitly track that a pure FIN is outstanding. > > My guess is that most of the implentations will know this already > (indirectly if not even directly). Nevertheless, I don't see what is > the harm if FIN is included to "outstanding" segments/sequences. I would be surprised if stacks retain an understanding of whether they transmitted a FIN with a data packet or without. There isn't harm, per se, except for complexity (and perhaps a small bit of extra state). > > My inclination here is that this is enough of a corner case that the > > document is fine how it is. > > ...and you still boldly claim in the intro that "A particular case > when all connections become application limited is as the connection > ends"? :-) Yeah... I don't see that at odds with calling the separate-FIN a corner case. > > (Note in the particular scenario you played out the TCP > > implementation may or may not send a payload-less FIN. Depending on > > the timing and etc. it could well be tacked on the second data > > packet.) > > That's certainly possible yes. > > But I would argue that if early retransmit would be made useful here, > short transfers would greatly benefit from sending it separately > because of the increased likelyhoods of avoiding RTO at the end which > is very significant for their latency. That's not a half bad thought---although it still to me seems like it'd help only a very small fraction of things. So, how about a note in section 2.2 that just says an implementation could also track a dataless FIN as an outstanding segment if explicitly tracking outstanding segments? Will that work? allman ----------ma29410-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkr7cuQACgkQWyrrWs4yIs5AuACgg7bshu2sGxXHXm8ri87aiFVf 470An1iLTnQwiybxT5CEdCMYlrBv+ljG =E35l -----END PGP SIGNATURE----- ----------ma29410-1-- From ilpo.jarvinen@helsinki.fi Thu Nov 12 21:27:49 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCAD3A67FA for ; Thu, 12 Nov 2009 21:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMfK2CKY4dey for ; Thu, 12 Nov 2009 21:27:48 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id A26853A67F3 for ; Thu, 12 Nov 2009 21:27:47 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.11.93]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 13 Nov 2009 07:28:14 +0200 id 00063DF6.4AFCEE6E.00006EE3 Date: Fri, 13 Nov 2009 07:28:14 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Mark Allman In-Reply-To: <20091112022853.551105A5144@lawyers.icir.org> Message-ID: References: <20091112022853.551105A5144@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: k.avrachenkov@sophia.inria.fr, tcpm@ietf.org, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 05:27:49 -0000 On Wed, 11 Nov 2009, Mark Allman wrote: > > > > So, ... > > > > > > (1) You send two data packets plus a pure FIN. > > > > > > (2) Lose the second data packet. > > > > > > (3) Get a cumulative ACK for the first data packet. > > > > > > (4) Get a FIN-triggered duplicate ACK. > > > > > > At this point the sender will think there is one outstanding segment and > > > set the dupthresh to zero and so not really useful in using the dupack > > > as a trigger for a retransmit. > > > > Is it really that well defined that pure FINs are not "segments"? > > I didn't mean to say or indicate that. > > > > I basically don't see anything to be done here short of making the > > > sender explicitly track that a pure FIN is outstanding. > > > > My guess is that most of the implentations will know this already > > (indirectly if not even directly). Nevertheless, I don't see what is > > the harm if FIN is included to "outstanding" segments/sequences. > > I would be surprised if stacks retain an understanding of whether they > transmitted a FIN with a data packet or without. There isn't harm, per > se, except for complexity (and perhaps a small bit of extra state). I don't perhaps fully follow what is the problem here. If it wasn't sent separately, there won't be that dup ACK then either because both FIN and final data are either lost or delivered in unison. But then it would have been counted as one outstanding segment anyway (if it was counted as two for some reason, I'd say the implementation is just broken). Secondly, if one counts window in segments, I cannot see how it can be done robustly without knowing segment boundaries (after all, negative in-flight isn't that nice thing) and there is very little need to create exception for FIN but treat its boundary the same way. ...Plus I suppose the implentation still wants to know that FIN was acked :-). Once segment boundaries are known, it is insignificant in context of early rexmit whether the last segment is pure-FIN or not.. > > > My inclination here is that this is enough of a corner case that the > > > document is fine how it is. > > > > ...and you still boldly claim in the intro that "A particular case > > when all connections become application limited is as the connection > > ends"? :-) > > Yeah... I don't see that at odds with calling the separate-FIN a corner > case. > > > > (Note in the particular scenario you played out the TCP > > > implementation may or may not send a payload-less FIN. Depending on > > > the timing and etc. it could well be tacked on the second data > > > packet.) > > > > That's certainly possible yes. > > > > But I would argue that if early retransmit would be made useful here, > > short transfers would greatly benefit from sending it separately > > because of the increased likelyhoods of avoiding RTO at the end which > > is very significant for their latency. > > That's not a half bad thought---although it still to me seems like it'd > help only a very small fraction of things. > > So, how about a note in section 2.2 that just says an implementation > could also track a dataless FIN as an outstanding segment if explicitly > tracking outstanding segments? Will that work? A note sounds reasonable to me. -- i. From mallman@icir.org Fri Nov 13 05:25:15 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F103A6A66 for ; Fri, 13 Nov 2009 05:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp4CTfwon1Wt for ; Fri, 13 Nov 2009 05:25:15 -0800 (PST) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 1DC423A6932 for ; Fri, 13 Nov 2009 05:25:15 -0800 (PST) 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 nADDPPPG002747; Fri, 13 Nov 2009 05:25:25 -0800 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 DDA793E76FBC; Fri, 13 Nov 2009 08:25:19 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8A2A35A8FBB; Fri, 13 Nov 2009 08:25:18 -0500 (EST) To: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma24122-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 13 Nov 2009 08:25:18 -0500 Sender: mallman@icir.org Message-Id: <20091113132518.8A2A35A8FBB@lawyers.icir.org> Cc: tcpm@ietf.org, k.avrachenkov@sophia.inria.fr, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 13:25:15 -0000 ----------ma24122-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > I would be surprised if stacks retain an understanding of whether they > > transmitted a FIN with a data packet or without. There isn't harm, per > > se, except for complexity (and perhaps a small bit of extra state). > > I don't perhaps fully follow what is the problem here. If it wasn't > sent separately, there won't be that dup ACK then either because both > FIN and final data are either lost or delivered in unison. But then it > would have been counted as one outstanding segment anyway (if it was > counted as two for some reason, I'd say the implementation is just > broken). > > Secondly, if one counts window in segments, I cannot see how it can be > done robustly without knowing segment boundaries (after all, negative > in-flight isn't that nice thing) and there is very little need to > create exception for FIN but treat its boundary the same way. ...Plus > I suppose the implentation still wants to know that FIN was acked > :-). Once segment boundaries are known, it is insignificant in context > of early rexmit whether the last segment is pure-FIN or not.. I don't really follow this at all. If you are tracking segments and include the implicit sequence number consumed by the FIN then this all just works, I guess. Is that what you're saying? allman ----------ma24122-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkr9Xj0ACgkQWyrrWs4yIs4HhACfcx89EEcKR7d/SH+1XPfrPkd4 ckQAoIwIJHzfPdbtwdOePkS0f8qURLEy =/97/ -----END PGP SIGNATURE----- ----------ma24122-1-- From rs@netapp.com Sat Nov 14 18:16:42 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B963A67D1 for ; Sat, 14 Nov 2009 18:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_05=-1.11, J_CHICKENPOX_26=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfPdfDYgZEya for ; Sat, 14 Nov 2009 18:16:40 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id CF81C3A6784 for ; Sat, 14 Nov 2009 18:16:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,744,1249282800"; d="scan'208";a="104084379" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 14 Nov 2009 18:17:09 -0800 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAF2H93x015782; Sat, 14 Nov 2009 18:17:09 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Nov 2009 03:17:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Nov 2009 02:15:19 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A066BDBEE@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4AFA79BD.4090200@i4.informatik.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Detect Lost Retransmit mit SACK Thread-Index: AcpirAr3zK/uxzYbRgiHMTMGRHK5agC5WJiw From: "Scheffenegger, Richard" To: "Arnd Hannemann" , X-OriginalArrivalTime: 15 Nov 2009 02:17:09.0215 (UTC) FILETIME=[BC024EF0:01CA6599] Subject: Re: [tcpm] Detect Lost Retransmit mit SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 02:16:42 -0000 Hi Arnd, Sorry for the late response. I did some further investigations=20 lately, and this is what I came up with. Of course, the majority of work and thoughs have been done by=20 others (most notably, I want to cite [[1]] "Lost Retransmission=20 Detection for TCP Part 2: TCP Using SACK Option" by=20 B. Kim et al (2004), but also by some ideas from [[2]] M. Mathis=20 (dated) RateHalving NetBSD based code found here=20 http://www.psc.edu/networking/projects/rate-halving/=20 (which did something similar but only for a single segment =20 for the SACK recovery generation, if I can tell...) First, the following prerequisites are required: 1) TCP Session must be SACK-enabled 2) TCP Sender has to have FACK implemented=20 3) TCP Sender has to have a scoreboard implementation to=20 track the state of the receiver, working with a sorted=20 list of SACK-Holes rather than positive SACK-Ranges. The fix might not be mathematically perfect in tracking each single=20 segment, but in it's simplest incarnation, it's about 8 lines of=20 code, adding minimal constant time (!) during ACK-processing.=20 The idea is basically, not to track every sent out segment=20 individually, but rather all holes in the scoreboard at once. The implicit assumption here is, that retransmissions get sent out in order (and are received with little to no reordering, or not=20 at all). When the sender transmits the last segment to "close a hole" in the=20 sender's representation of the scoreboard, represented by a data=20 structure holding start, end and rxmit vector, ie. When rxmit =3D=3D = end,=20 rxmit will be assinged the current value of snd.max. (In the simple=20 form, a separate variable iskept, but for the purpose of this=20 algorithm, the condition of rxmit <=3D end vs rxmit > end can be used=20 to differentiate between the two uses (current retransmission vector=20 in a hole, vs. segment number by which the hole should be reported=20 closed by the receiver) of rxmit. So, after the retransmission of the last segment of a hole, it's=20 rxmit will show the expected snd.fack value when that hole is ought=20 to have been properly ACKed by the receiver. In SACK processing, some precautions have to be made during hole- splitting (to keep the higher than sackhole.end rxmit vector).=20 Normal SACK processing will remove any fully closed holes before=20 snd.fack becomes greater than sendhole.rxmit, except when one of=20 the segments within that hole is never seen by the receiver. While=20 processing a normal SACK, check the condition of=20 snd.fack > sackhole[0].rxmit;=20 In the worst case (1 segment hole), when some reordering occurred,=20 this will yield one superfluous segment; with larger holes, the=20 intrinsic reordering grace period granted is n-m segments (with n=20 the size of the hole, and m the segment within the hole). If that condition is met, reset sackhole[0].rxmit to=20 sackhole[0].start, and also update the shortcut lookup pointer=20 (sackhint.nexthole to sackhole[0]). Extended periods of heavy loss are not dealt with. According to=20 [[1]], these should be counted as additional congestion events,=20 reducing ssthresh and cwnd accordingly; but this method needs a=20 constant stream of at least some new segments to leave the=20 Network). Thus, RTO + slow start is required for recovery of such severe Events. Also, when there is no more data from the socket to transmit,=20 to never exceed snd.max recorded for that hole, it will not=20 work. (Again, RTO to the rescue). But, it will update the rxmit vector for each fully retransmitted=20 hole - as long as it keeps going. This yields a maximum number or=20 RTO/RTT retries, before "usual" recovery sets in, and should=20 cover the common case. You could say it's more of a quick hack, but I think the=20 simplicity, intrinsic properties and near no overhead (processing=20 time or variable overhead) are well balanced, but if my assumptions are incorrect or short sighted, please say so. The simple version without any tweaks in existing checks of=20 sackhole[]->rxmit (requiring one more tcp_seq var in sackhole[]): Tcp_sack_doack: (after sanity checks about the new SACK blocks, BEFORE new snd.fack=20 has been calculated (one additional ACK grace period): =20 if (((temp =3D TAILQ_FIRST(&tp->snd_holes)) !=3D NULL) && //### (SEQ_GT(tp->snd_fack, temp->limit))) { //### temp->rxmit =3D temp->start; //### temp->limit =3D tp->snd_max; //### tp->sackhint.nexthole =3D temp; //### } //### Tcp_sack_doack: When splitting a hole in two: temp =3D tcp_sackhole_insert(tp, sblkp->end, cur->end, cur); if (temp !=3D NULL) { if (SEQ_GT(cur->rxmit, temp->rxmit)) { temp->rxmit =3D cur->rxmit; =09 tp->sackhint.sack_bytes_rexmit +=3D (temp->rxmit - temp->start); } temp->limit =3D cur->limit; //### cur->end =3D sblkp->start; // RS: SACK+ mod? cur->rxmit =3D SEQ_MIN(cur->rxmit, cur->end); } Tcp_output: (when in Retransmit && SACK mode): If (sack_rxmit =3D=3D 1) { th->th_seq =3D htonl(p->rxmit); p->rxmit +=3D len; if (SEQ_GEQ(p->rxmit, p->end)) //### p->limit =3D tp->snd_max; //### tp->sackhint.sack_bytes_rexmit +=3D len; } Tcp_var.h: struct sackhole { tcp_seq start; /* start seq no. of hole */ tcp_seq end; /* end seq no. */ tcp_seq rxmit; /* next seq. no in hole to be=20 retransmitted */ tcp_seq limit; /* ### for lost retransmission=20 detection - should be rolled=20 into rxmit */ TAILQ_ENTRY(sackhole) scblink; /* scoreboard linkage */ }; Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 =20 > -----Original Message----- > From: Arnd Hannemann [mailto:hannemann@i4.informatik.rwth-aachen.de]=20 > Sent: Mittwoch, 11. November 2009 09:46 > To: tcpm@ietf.org > Subject: Re: [tcpm] Detect Lost Retransmit mit SACK >=20 > Hi Richard, >=20 > Scheffenegger, Richard schrieb: > >>> A1) With TSOpt, they could be used to "remember" when=20 > >>> Retransmission started; > >>> When an ACKs with TSEcn > (TSOpt + RTT) is seen by=20 > >>> the sender, it can > >>> re-arm the DUPACK detector. > >>> =20 > >> This is your non-SACK scenario? > >> Please note that a TCP receiver will NOT echo TSVal from=20 > out-of-order=20 > >> segments. So this won't work. > >> =20 > > > > Interesting; this doesn't seem to be what certain (most?)=20 > stacks are=20 > > doing - they seem to always reply in the ACK Tsecr the value of=20 > > Tsopt/TS.recent triggering the ACK... >=20 > Please clarify, is this non-SACK scenario? > The only lost retransmission we could be talking about then,=20 > is the retransmission of SND.UNA. > And the TCP receiver will NOT adjust TS.recent for any out-of=20 > order packets (RFC 1323). > It will continue to echo the timestamp of the last segment=20 > which advanced the window (SND.UNA -1p). >=20 >=20 > > Or was your intention to say, that the receiver will not=20 > respond with=20 > > Tsopt, but rather TS.recent? >=20 > Yes, it will not respond with TSVal but with TS.recent. >=20 > > If so, than this makes no difference - the sender will detect the=20 > > first ACK from the receiver, which has the same TS (well, actually=20 > > TS+1 as multiple segments are likely to carry the same TS) when the=20 > > retransmission >=20 > There won't be an ACK if the retransmission is lost in=20 > non-SACK case, only dupACKs. > (Only retransmission is retransmission of SND.UNA) TS.Recent=20 > will not get updated. >=20 >=20 > > was started. This will be the sign for the sender, that at=20 > least one=20 > > RTT has elapsed (that was the intention for having=20 > timestamps in the=20 > > first place, right?). If the returned ACK does not cover the first=20 > > retransmitted segment by that time, it's quite reasonable to assume=20 > > that it got lost again > > =20 >=20 > > Again, keep in mind that I'm looking on LANs; a TS in 10 ms=20 > increments >=20 > If you are searching for something which is not intended for=20 > general use, why not just set MIN_RTO to say 10 ms? >=20 > >>> A2) With SACK, tracking SND.NXT and HOLEBYTES (number of=20 > >>> octets in all current holes) > >>> can be employed to track RTT (they need to be=20 > >>> initialized when the first > >>> retransmitted segment is sent). When an ACK contains=20 > >>> a SACK for >=3D SND.NXT, or the > >>> HOLEBYTES are smaller than when retransmission started, the=20 > >>> DUPACK detector can be re-armed. > >>> =20 > >> You should specify what you mean with SND.NXT. > >> We are in recovery, so we may very well send out new segments. > >> I don't see why number of holes in sack scoreboard has=20 > anything todo=20 > >> with RTT. > >> =20 > > > > > > SND.NXT is the rightmost segment which the sender has never before=20 > > sent out to the network. Isn't that the meaning of Snd.nxt=20 > according=20 > > to RFC793? >=20 > Hmm, I would interpret RFC793 differently. > I would call it SND.MAX (see RFC4015) or HighData (RFC3517)=20 > the rightmost segment which the sender has never sent before.=20 > But now you have to clarify how it would be possible to=20 > receive a SACK block > SND.MAX. Even SACK block =3D=3D SND.MAX=20 > will be rarely seen. > But before taking this discussion even further, maybe take=20 > some time and write some preliminary draft of your algorithm. >=20 > > And I was not talking about the # of holes, but rather the=20 > amount of=20 > > Data (in sum) between FACK (defined by the rightmost offset in the=20 > > SACK Scoreboard, i.e. covering the highest ever received=20 > segment) and=20 > > SND.UNA. > > > > Monitoring Holes will gain nothing (when there is reordering for=20 > > example); > > > > But if the any one retransmission makes it though, the amount of=20 > > unSACKed data in the sum total of all holes in the scoreboard, will=20 > > decrease - indicating when at least one RTT has passed=20 > since start of=20 > > FastRetransmit. >=20 > This is not true. > Consider a 100 packet in flight, you get 3 dupacks, do a=20 > retransmission. > This is in your words "start of FastRetransmit". After this=20 > the sum total of all holes between SND.UNA and FACK can only=20 > increase for one RTT. > Due to Limited Transmit and Fast Recovery, it might be=20 > possible that even the sum total of all holes between SND.UNA=20 > and SND.MAX will increase. > You know when the first Retransmit is lost when a SACK covers=20 > RecoveryPoint (RFC3517). But this is only true for first hole. > To detect lost retransmissions of the other holes, you would=20 > need to store a separate HighData (RFC3617) for every retransmission. > Maybe this is after all what you are trying to express? > Perhaps it would be helpful if you could cook up some pseudo=20 > code, of your proposed algorithm. >=20 > >> =20 > >>> holes > >>> have been retransmitted once...=20 > >>> =20 > >> Show me an example. where a lost retransmission is=20 > detectable, while=20 > >> the sender did not send out retransmissions for every other hole? > >> Sounds weird. > >> =20 > > > > Can I attach trace files on posts to this list, or shall I=20 > sent them=20 > > to you directly? >=20 > Never mind, does not actually matter. >=20 > >>> =20 > >> This probably highly rates from case to case. If you have a huge=20 > >> bandwidth-delay product even SACK scoreboard handling will have=20 > >> computational complexity which might outweigh its benefits. > >> As you have seem to have the equipment at hand, you could=20 > do some cpu=20 > >> load and throughput measurements with 10GbE and SACK=20 > versus non-SACK=20 > >> flows. > >> =20 > > > > Well, I was doing some test like this: > > > >=20 > http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html > > > > But the CPU impact (on top of what is required for 10G) was=20 > neglegible. > > But I have to admit, I didn't had the time yet to test a SACK=20 > > scoreboard with every other byte marked mission (which=20 > could mean some=20 > > 0,5 mio entries). > > > > But it seems that most implementations feature sorted=20 > scoreboards of=20 > > limited > > (16/128) size. > > > > Traversing those is - again in my case of 10G LANs - still=20 > many orders=20 > > of magnitude faster then waiting for RTO. > > > > I personally consider RTOs to be harmful (when there are=20 > other means=20 > > to recover with). :) (perhaps once I have worked through all the=20 > > issues raised here, I submit a draft with "TCP RTO=20 > considered harmful"=20 > > next April? :) >=20 > Better submit a draft to mitigate the problems with it ;-) >=20 > Best regards, > Arnd >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From ilpo.jarvinen@helsinki.fi Tue Nov 17 03:51:28 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C010228C10B for ; Tue, 17 Nov 2009 03:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNdCgK0XgFJD for ; Tue, 17 Nov 2009 03:51:28 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id F043828C0EC for ; Tue, 17 Nov 2009 03:51:27 -0800 (PST) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 17 Nov 2009 13:51:23 +0200 id 00063E1C.4B028E3B.0000499C Date: Tue, 17 Nov 2009 13:51:23 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: Mark Allman In-Reply-To: <20091113132518.8A2A35A8FBB@lawyers.icir.org> Message-ID: References: <20091113132518.8A2A35A8FBB@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, k.avrachenkov@sophia.inria.fr, jblanton@cs.ohiou.edu Subject: Re: [tcpm] early retransmit done? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 11:51:28 -0000 On Fri, 13 Nov 2009, Mark Allman wrote: > > > > I would be surprised if stacks retain an understanding of whether they > > > transmitted a FIN with a data packet or without. There isn't harm, per > > > se, except for complexity (and perhaps a small bit of extra state). > > > > I don't perhaps fully follow what is the problem here. If it wasn't > > sent separately, there won't be that dup ACK then either because both > > FIN and final data are either lost or delivered in unison. But then it > > would have been counted as one outstanding segment anyway (if it was > > counted as two for some reason, I'd say the implementation is just > > broken). > > > > Secondly, if one counts window in segments, I cannot see how it can be > > done robustly without knowing segment boundaries (after all, negative > > in-flight isn't that nice thing) and there is very little need to > > create exception for FIN but treat its boundary the same way. ...Plus > > I suppose the implentation still wants to know that FIN was acked > > :-). Once segment boundaries are known, it is insignificant in context > > of early rexmit whether the last segment is pure-FIN or not.. > > I don't really follow this at all. > > If you are tracking segments and include the implicit sequence number > consumed by the FIN then this all just works, I guess. Is that what > you're saying? Yes. ...And there's more, I also tried to say that one has to track that FIN sequence number anyway in order to be able to discern that the FIN was acked. -- i. From wesley.m.eddy@nasa.gov Tue Nov 17 06:23:12 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AAF3A6AA5 for ; Tue, 17 Nov 2009 06:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsDQDDdqYeop for ; Tue, 17 Nov 2009 06:23:11 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id ECAE33A6972 for ; Tue, 17 Nov 2009 06:23:10 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 7F1F5328215 for ; Tue, 17 Nov 2009 08:23:09 -0600 (CST) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nAHEN9Wm016829 for ; Tue, 17 Nov 2009 08:23:09 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 17 Nov 2009 08:23:09 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 17 Nov 2009 08:23:06 -0600 Thread-Topic: working group status 11/17/09 Thread-Index: AcpnkXWbDjCee2T3TouQOFD+OSLnvQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-17_10:2009-11-16, 2009-11-17, 2009-11-17 signatures=0 Subject: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 14:23:12 -0000 Hello; since TCPM didn't meet in Hiroshima, but we do have several documents in the process of being finished up, and a couple others in the process of starting, here's a quick snapshot of the TCPM working group status and the actions needed on each document; please let us know if we left anything out: Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt Milestone Target: Proposed Standard in April 2009 Action: In WGLC until 11/24/09 TCP Authentication Option Crypto http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt Milestone Target: Proposed Standard with AO spec Action: In WGLC until 11/24/09 ICMP Attacks http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt Milestone Target: Informational in July 2009 Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update based on W= GLC Early-Retransmit http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt Milestone Target: Experimental in July 2009 Action: WGLC finished & authors updated (action with chairs to forward to I= ESG) 1323bis http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt Milestone Target: Proposed Standard in July 2009 Action: Revise & WGLC (action with D. Borman) MSS Option http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt Milestone Target: Proposed Standard in July 2009 Action: WGLC started 8/19, ended 9/8 (extended), being updated based on sev= eral of the comments (action with D. Borman) Urgent Pointer http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt Milestone Target: Proposed Standard in January 2010 Action: Continue WG reviews; authors have indicated it is ready for WGLC; planned to start WGLC after AO WGLC completes TCP Security http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt Milestone Target: BCP in August 2010 Action: 00-draft / outline has been under active discussion; but not attain= ed very clear consensus WG might begin working on recommendations while still looking for a possible compromise on outline (action with Fernando Gont) Long Connectivity Disruptions http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt (need to submit WG version) Milestone Target: Experimental in October 2010 Action: need WG to read/discuss authors to submit revision (action with Zimmerman) SACK Entry http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt Milestone Target: Proposed Standard in October 2010 Action: need WG to read/discuss TBD how this relates to 3517 Other Proposals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Persist http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt Action: WG Review Timestamps http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt Action: ??? Parameter Tuning (no I-D yet) Action: continue good discussion on mailing list presentation given in Stockholm TCP Option for Transparent Middlebox Discovery http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt Action: Needs WG review / discussion discussion on mailing list has been productive NewReno Modification http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.t= xt Action: need WG to read/discuss presentation given, but WG list not yet polled for adoption Recent discussions opened on Rate-Halving http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt Action: mailing list discussion about the history of this, and whether it needs to be revived -- Wes Eddy MTI Systems From gregory.ietf@gmail.com Tue Nov 17 13:54:15 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9CD3A6B0D for ; Tue, 17 Nov 2009 13:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HP2zEPuqJS4 for ; Tue, 17 Nov 2009 13:54:14 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 223D63A68C2 for ; Tue, 17 Nov 2009 13:54:13 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so210223fga.13 for ; Tue, 17 Nov 2009 13:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dxytl2kPjmnMRAfx6nAKTRwNXjuVBYJtpbtwxcA7W1s=; b=Xk2T1+qEAIq8zeex9EqJrUpVxNPlr5YllSc7QYWXzK9SsIccw/ozqMOrhlI51AwT9M FcHnuBf2pW/kfoMqPTaGZJKoA1ULggzN1Oy8o6uMVY5ImosvObhp6gd9J8aMepIUPyNm gFGqTo/jINKndkJxg6jbVQqdlBEkivtuyr3KQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mEhcUCdsEiroSv/ZiPSK9W61oxb7+33e7zH3WSCHhn5rF9CAxEDoU9D9hIp0A0/eG0 rgyGevf80693OEEyzZ520TMDCMp7ck+o1+H1mSC9wNsgGXsoF2UNX8R4KmYqyX9qbSJS gZ1BkTZZ/9b1gIHk6Pv4GVYOHH0Ole1jRhFRE= MIME-Version: 1.0 Received: by 10.86.230.30 with SMTP id c30mr506384fgh.68.1258494849583; Tue, 17 Nov 2009 13:54:09 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Nov 2009 13:54:09 -0800 Message-ID: From: Gregory Lebovitz To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , Joe Touch Content-Type: multipart/alternative; boundary=001485e29a4c760a250478982aa1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 21:54:16 -0000 --001485e29a4c760a250478982aa1 Content-Type: text/plain; charset=ISO-8859-1 should we also list here the current draft on NAT-Traversal for TCP-AO? It's not a WG item, but it is being done as a possible (likely?) textual addition to a WG item. comment? Gregory. On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Hello; since TCPM didn't meet in Hiroshima, but we do have > several documents in the process of being finished up, and > a couple others in the process of starting, here's a quick > snapshot of the TCPM working group status and the actions > needed on each document; please let us know if we left > anything out: > > > Active WG Items > =============== > > TCP Authentication Option > http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt > Milestone Target: Proposed Standard in April 2009 > Action: In WGLC until 11/24/09 > > TCP Authentication Option Crypto > http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > Milestone Target: Proposed Standard with AO spec > Action: In WGLC until 11/24/09 > > ICMP Attacks > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt > Milestone Target: Informational in July 2009 > Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update based on > WGLC > > Early-Retransmit > http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt > Milestone Target: Experimental in July 2009 > Action: WGLC finished & authors updated (action with chairs to forward to > IESG) > > 1323bis > http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt > Milestone Target: Proposed Standard in July 2009 > Action: Revise & WGLC (action with D. Borman) > > MSS Option > http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt > Milestone Target: Proposed Standard in July 2009 > Action: WGLC started 8/19, ended 9/8 (extended), being updated based on > several > of the comments (action with D. Borman) > > Urgent Pointer > http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt > Milestone Target: Proposed Standard in January 2010 > Action: Continue WG reviews; authors have indicated it is ready for WGLC; > planned to start WGLC after AO WGLC completes > > TCP Security > http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt > Milestone Target: BCP in August 2010 > Action: 00-draft / outline has been under active discussion; but not > attained > very clear consensus > WG might begin working on recommendations while still looking for a > possible compromise on outline (action with Fernando Gont) > > Long Connectivity Disruptions > http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt > (need to submit WG version) > Milestone Target: Experimental in October 2010 > Action: need WG to read/discuss > authors to submit revision (action with Zimmerman) > > SACK Entry > http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt > Milestone Target: Proposed Standard in October 2010 > Action: need WG to read/discuss > TBD how this relates to 3517 > > > Other Proposals > =============== > > Persist > http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt > Action: WG Review > > Timestamps > http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt > Action: ??? > > Parameter Tuning > (no I-D yet) > Action: continue good discussion on mailing list > presentation given in Stockholm > > TCP Option for Transparent Middlebox Discovery > http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt > Action: Needs WG review / discussion > discussion on mailing list has been productive > > NewReno Modification > > http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.txt > Action: need WG to read/discuss > presentation given, but WG list not yet polled for adoption > > Recent discussions opened on Rate-Halving > http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt > Action: mailing list discussion about the history of this, and whether > it needs to be revived > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --001485e29a4c760a250478982aa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable should we also list here the current draft on NAT-Traversal for TCP-AO? It&= #39;s not a WG item, but it is being done as a possible (likely?) textual a= ddition to a WG item. comment?

Gregory.

On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE = CORP] <wesle= y.m.eddy@nasa.gov> wrote:
Hello; since TCPM didn't meet in Hiroshima, but we do have
several documents in the process of being finished up, and
a couple others in the process of starting, here's a quick
snapshot of the TCPM working group status and the actions
needed on each document; please let us know if we left
anything out:


Active WG Items
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

TCP Authentication Option
http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt
Milestone Target: Proposed Standard in April 2009
Action: In WGLC until 11/24/09

TCP Authentication Option Crypto
http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt<= /a>
Milestone Target: Proposed Standard with AO spec
Action: In WGLC until 11/24/09

ICMP Attacks
http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt
Milestone Target: Informational in July 2009
Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update based on W= GLC

Early-Retransmit
http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt<= br> Milestone Target: Experimental in July 2009
Action: WGLC finished & authors updated (action with chairs to forward = to IESG)

1323bis
http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt
Milestone Target: Proposed Standard in July 2009
Action: Revise & WGLC (action with D. Borman)

MSS Option
http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt
Milestone Target: Proposed Standard in July 2009
Action: WGLC started 8/19, ended 9/8 (extended), being updated based on sev= eral
=A0 =A0 =A0 =A0of the comments (action with D. Borman)

Urgent Pointer
http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt<= br> Milestone Target: Proposed Standard in January 2010
Action: Continue WG reviews; authors have indicated it is ready for WGLC; =A0 =A0 =A0 =A0planned to start WGLC after AO WGLC completes

TCP Security
http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt
Milestone Target: BCP in August 2010
Action: 00-draft / outline has been under active discussion; but not attain= ed
=A0 =A0 =A0 =A0 =A0very clear consensus
=A0 =A0 =A0 =A0WG might begin working on recommendations while still looki= ng for a
=A0 =A0 =A0 =A0 =A0possible compromise on outline (action with Fernando Go= nt)

Long Connectivity Disruptions
http://www.ietf.org/internet-drafts/draft-zimmermann= -tcp-lcd-02.txt
(need to submit WG version)
Milestone Target: Experimental in October 2010
Action: need WG to read/discuss
=A0 =A0 =A0 =A0authors to submit revision (action with Zimmerman)

SACK Entry
http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-e= ntry-00.txt
Milestone Target: Proposed Standard in October 2010
Action: need WG to read/discuss
=A0 =A0 =A0 =A0TBD how this relates to 3517


Other Proposals
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Persist
http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt<= br> Action: WG Review

Timestamps
http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-0= 1.txt
Action: ???

Parameter Tuning
(no I-D yet)
Action: continue good discussion on mailing list
=A0 =A0 =A0 =A0presentation given in Stockholm

TCP Option for Transparent Middlebox Discovery
http://www.ietf.org/id/draft-knutsen-tcpm-middlebox= -discovery-03.txt
Action: Needs WG review / discussion
=A0 =A0 =A0 =A0discussion on mailing list has been productive

NewReno Modification
http://www.ietf.org/internet-drafts/draft-= nishida-newreno-modification-01.txt
Action: need WG to read/discuss
=A0 =A0 =A0 =A0presentation given, but WG list not yet polled for adoption=

Recent discussions opened on Rate-Halving
http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.tx= t
Action: mailing list discussion about the history of this, and whether
=A0 =A0 =A0 =A0it needs to be revived

--
Wes Eddy
MTI Systems

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



--
----
IETF rel= ated email from
Gregory M. Lebovitz
Juniper Networks
--001485e29a4c760a250478982aa1-- From touch@ISI.EDU Tue Nov 17 14:17:26 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EC63A68FF for ; Tue, 17 Nov 2009 14:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHvf4aoQrpMQ for ; Tue, 17 Nov 2009 14:17:25 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C21AC3A67D4 for ; Tue, 17 Nov 2009 14:17:25 -0800 (PST) Received: from [75.217.224.142] (142.sub-75-217-224.myvzw.com [75.217.224.142]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nAHMG82k022809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 14:16:10 -0800 (PST) Message-ID: <4B0320A5.8040300@isi.edu> Date: Tue, 17 Nov 2009 14:16:05 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gregory Lebovitz References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nAHMG82k022809 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:17:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Gregory, Gregory Lebovitz wrote: > should we also list here the current draft on NAT-Traversal for TCP-AO? > It's not a WG item, but it is being done as a possible (likely?) textual > addition to a WG item. comment? It might be useful. I know there are a few people who said they might post their thoughts on this shortly... (i.e., this is a reminder to them ;-) Joe > On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC > AEROSPACE CORP] > > wrote: > > Hello; since TCPM didn't meet in Hiroshima, but we do have > several documents in the process of being finished up, and > a couple others in the process of starting, here's a quick > snapshot of the TCPM working group status and the actions > needed on each document; please let us know if we left > anything out: > > > Active WG Items > =============== > > TCP Authentication Option > http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt > Milestone Target: Proposed Standard in April 2009 > Action: In WGLC until 11/24/09 > > TCP Authentication Option Crypto > http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > Milestone Target: Proposed Standard with AO spec > Action: In WGLC until 11/24/09 > > ICMP Attacks > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt > Milestone Target: Informational in July 2009 > Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update > based on WGLC > > Early-Retransmit > http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt > Milestone Target: Experimental in July 2009 > Action: WGLC finished & authors updated (action with chairs to > forward to IESG) > > 1323bis > http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt > Milestone Target: Proposed Standard in July 2009 > Action: Revise & WGLC (action with D. Borman) > > MSS Option > http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt > Milestone Target: Proposed Standard in July 2009 > Action: WGLC started 8/19, ended 9/8 (extended), being updated based > on several > of the comments (action with D. Borman) > > Urgent Pointer > http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt > Milestone Target: Proposed Standard in January 2010 > Action: Continue WG reviews; authors have indicated it is ready for > WGLC; > planned to start WGLC after AO WGLC completes > > TCP Security > http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt > Milestone Target: BCP in August 2010 > Action: 00-draft / outline has been under active discussion; but not > attained > very clear consensus > WG might begin working on recommendations while still looking > for a > possible compromise on outline (action with Fernando Gont) > > Long Connectivity Disruptions > http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt > (need to submit WG version) > Milestone Target: Experimental in October 2010 > Action: need WG to read/discuss > authors to submit revision (action with Zimmerman) > > SACK Entry > http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt > Milestone Target: Proposed Standard in October 2010 > Action: need WG to read/discuss > TBD how this relates to 3517 > > > Other Proposals > =============== > > Persist > http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt > Action: WG Review > > Timestamps > http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt > Action: ??? > > Parameter Tuning > (no I-D yet) > Action: continue good discussion on mailing list > presentation given in Stockholm > > TCP Option for Transparent Middlebox Discovery > http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt > Action: Needs WG review / discussion > discussion on mailing list has been productive > > NewReno Modification > http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.txt > Action: need WG to read/discuss > presentation given, but WG list not yet polled for adoption > > Recent discussions opened on Rate-Halving > http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt > Action: mailing list discussion about the history of this, and whether > it needs to be revived > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksDIKUACgkQE5f5cImnZrsbAQCg1fVGyGXqgLo3Of1BxRpC4dfB +/UAnirM1ZJU1iNZ2GwrsptenzoNswV7 =NYcT -----END PGP SIGNATURE----- From dwing@cisco.com Tue Nov 17 15:36:45 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7243A6B15 for ; Tue, 17 Nov 2009 15:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urL+vxokseir for ; Tue, 17 Nov 2009 15:36:44 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BD8DB3A67DA for ; Tue, 17 Nov 2009 15:36:44 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAOPCAkurRN+J/2dsb2JhbACKNLQPmECEOwSBb4po X-IronPort-AV: E=Sophos;i="4.44,761,1249257600"; d="scan'208";a="50733746" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2009 23:36:43 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAHNah3w012585; Tue, 17 Nov 2009 23:36:43 GMT From: "Dan Wing" To: "'Joe Touch'" , "'tcpm Extensions WG'" References: <4ADC7C85.4050408@isi.edu> Date: Tue, 17 Nov 2009 15:36:42 -0800 Message-ID: <057c01ca67de$d1ada820$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4ADC7C85.4050408@isi.edu> Thread-Index: AcpQy4+GkdUNBfpMTV6r50lfGZEQ/wXEwoFw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [tcpm] [Fwd: New Version Notification for draft-touch-tcp-ao-nat-00] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:36:45 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Monday, October 19, 2009 7:50 AM > To: tcpm Extensions WG > Subject: [tcpm] [Fwd: New Version Notification for > draft-touch-tcp-ao-nat-00] > > Hi, all, > > The following provides info on the draft that describes the NAT > extensions to TCP-AO. They have been submitted as individual for now, > with the intent of incorporating the result into the TCP-AO > doc *if* we > have time before publication and *if* there is consensus to do so. > > Otherwise, it can published separately as either PS or > experimental, if preferred. Thanks for publishing this document, Joe. I would prefer to see it incorporated into the base TCP-AO document, as there are legitimate uses for TCP-AO for TCP clients behind a NAT44 or NAT64, such as to protect long-lived TLS-over-TCP sessions (SIP, XMPP, HTTP, and perhaps will be necessary for the forthcoming SmartGrids work). -d From dwing@cisco.com Tue Nov 17 17:15:12 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0173A6A53 for ; Tue, 17 Nov 2009 17:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw6f1RZuGgBZ for ; Tue, 17 Nov 2009 17:15:11 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 59F903A6765 for ; Tue, 17 Nov 2009 17:15:11 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,761,1249257600"; d="scan'208";a="50772312" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 18 Nov 2009 01:15:10 +0000 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAI1F9gT024829; Wed, 18 Nov 2009 01:15:10 GMT From: "Dan Wing" To: "'Dan Wing'" , "'Joe Touch'" , "'tcpm Extensions WG'" References: <4ADC7C85.4050408@isi.edu> Date: Tue, 17 Nov 2009 17:15:05 -0800 Message-ID: <05f801ca67ec$90199960$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpQy4+GkdUNBfpMTV6r50lfGZEQ/wXEwoFwAANwwnA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [tcpm] [Fwd: New Version Notification for draft-touch-tcp-ao-nat-00] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 01:15:12 -0000 And to followup -- TCP-AO-NAT is a good idea. As I have explained in previous emails to TCPM, I would prefer it work with a TCP server behind a NAT, as well as the TCP client behind a NAT, but it's a reasonable trade-off in complexity as most of the use cases where AO is important have publicly-accessible TCP servers. I'm sure some other folks have something to say about TCP-AO working for a TCP-AO client behind a NAT44 or behind a NAT64? -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, November 17, 2009 3:37 PM > To: 'Joe Touch'; 'tcpm Extensions WG' > Subject: RE: [tcpm] [Fwd: New Version Notification for > draft-touch-tcp-ao-nat-00] > > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Joe Touch > > Sent: Monday, October 19, 2009 7:50 AM > > To: tcpm Extensions WG > > Subject: [tcpm] [Fwd: New Version Notification for > > draft-touch-tcp-ao-nat-00] > > > > Hi, all, > > > > The following provides info on the draft that describes the NAT > > extensions to TCP-AO. They have been submitted as > individual for now, > > with the intent of incorporating the result into the TCP-AO > > doc *if* we > > have time before publication and *if* there is consensus to do so. > > > > Otherwise, it can published separately as either PS or > > experimental, if preferred. > > Thanks for publishing this document, Joe. I would prefer to see it > incorporated into the base TCP-AO document, as there are legitimate > uses for TCP-AO for TCP clients behind a NAT44 or NAT64, such as to > protect long-lived TLS-over-TCP sessions (SIP, XMPP, HTTP, and > perhaps will be necessary for the forthcoming SmartGrids work). > > -d > > From rs@netapp.com Wed Nov 18 03:18:00 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19403A6A25 for ; Wed, 18 Nov 2009 03:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqGdxSLFWD6i for ; Wed, 18 Nov 2009 03:17:59 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id F1D713A6929 for ; Wed, 18 Nov 2009 03:17:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,764,1249282800"; d="scan'208";a="115096233" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 18 Nov 2009 03:17:54 -0800 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAIBHstW013032; Wed, 18 Nov 2009 03:17:54 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 12:17:54 +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: Wed, 18 Nov 2009 11:17:53 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A04B7BDEF@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] working group status 11/17/09 Thread-Index: AcpnkXWbDjCee2T3TouQOFD+OSLnvQArPa7Q From: "Scheffenegger, Richard" To: "Eddy, Wesley M. \(GRC-MS00\)[ASRC AEROSPACE CORP]" , X-OriginalArrivalTime: 18 Nov 2009 11:17:54.0337 (UTC) FILETIME=[C60C4910:01CA6840] Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:18:00 -0000 Hello Group, Regarding Rate-Halving: It seems to me, that RFC4653 has a "lite"=20 version (Cautious Extended Limited Transmit) of that, and limiting=20 the scope to SACK-enabled streams only. Also, RR-TCP uses Extended Limited Transmit (but the aggressive=20 variant) to keep the ACK clock going after potential congestion events.=20 But RR-TCP seems to be very much more complex than RFC4653, although=20 I need to investigate the gains/costs a bit further. I wonder if the mentioned problems wouldn't impact those suggested=20 algorithms just like RH; OTOH, data handling subsystems are getting Also faster, so that at least starvation during a bulk transfer (in a dedicated system) should no longer be a hinderance. And worst case=20 operation wouldn't be so much different from NewReno anyway, or not? Regards, Richard Scheffenegger Field Support Engineer NetApp Global Support NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com Franz-Klein-Gasse 5 1190 Wien -----Original Message----- From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] [mailto:wesley.m.eddy@nasa.gov]=20 Sent: Dienstag, 17. November 2009 15:23 To: tcpm@ietf.org Subject: [tcpm] working group status 11/17/09 Hello; since TCPM didn't meet in Hiroshima, but we do have several documents in the process of being finished up, and a couple others in the process of starting, here's a quick snapshot of the TCPM working group status and the actions needed on each document; please let us know if we left anything out: Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt Milestone Target: Proposed Standard in April 2009 Action: In WGLC until 11/24/09 TCP Authentication Option Crypto http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt Milestone Target: Proposed Standard with AO spec Action: In WGLC until 11/24/09 ICMP Attacks http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt Milestone Target: Informational in July 2009 Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update based on WGLC Early-Retransmit http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt Milestone Target: Experimental in July 2009 Action: WGLC finished & authors updated (action with chairs to forward to IESG) 1323bis http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt Milestone Target: Proposed Standard in July 2009 Action: Revise & WGLC (action with D. Borman) MSS Option http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt Milestone Target: Proposed Standard in July 2009 Action: WGLC started 8/19, ended 9/8 (extended), being updated based on several of the comments (action with D. Borman) Urgent Pointer http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt Milestone Target: Proposed Standard in January 2010 Action: Continue WG reviews; authors have indicated it is ready for WGLC; planned to start WGLC after AO WGLC completes TCP Security http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt Milestone Target: BCP in August 2010 Action: 00-draft / outline has been under active discussion; but not attained very clear consensus WG might begin working on recommendations while still looking for a possible compromise on outline (action with Fernando Gont) Long Connectivity Disruptions http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt (need to submit WG version) Milestone Target: Experimental in October 2010 Action: need WG to read/discuss authors to submit revision (action with Zimmerman) SACK Entry http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt Milestone Target: Proposed Standard in October 2010 Action: need WG to read/discuss TBD how this relates to 3517 Other Proposals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Persist http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt Action: WG Review Timestamps http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt Action: ??? Parameter Tuning (no I-D yet) Action: continue good discussion on mailing list presentation given in Stockholm TCP Option for Transparent Middlebox Discovery http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt Action: Needs WG review / discussion discussion on mailing list has been productive NewReno Modification http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-0 1.txt Action: need WG to read/discuss presentation given, but WG list not yet polled for adoption Recent discussions opened on Rate-Halving http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt Action: mailing list discussion about the history of this, and whether it needs to be revived -- Wes Eddy MTI Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From root@core3.amsl.com Wed Nov 18 08:00:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B7DE628C103; Wed, 18 Nov 2009 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091118160001.B7DE628C103@core3.amsl.com> Date: Wed, 18 Nov 2009 08:00:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-lcd-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) Author(s) : A. Zimmermann, A. Hannemann Filename : draft-ietf-tcpm-tcp-lcd-00.txt Pages : 25 Date : 2009-11-17 Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout cause suboptimal TCP performance. The reason for the performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This leads in turn to a deferred detection of the re-establishment of the connection since TCP waits until the next retransmission timeout occurs before attempting the retransmission. This document proposes a algorithm for making TCP more robust to long connectivity disruptions (TCP-LCD). The memo describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a revert strategy of the retransmission timer is specified that enables a more prompt detection of whether the connectivity to a previously disconnected peer node has been restored or not. TCP-LCD is a TCP sender-only modification that effectively improves TCP performance in presence of connectivity disruptions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-lcd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-lcd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-18074956.I-D@ietf.org> --NextPart-- From alexander.zimmermann@nets.rwth-aachen.de Wed Nov 18 08:22:02 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074913A68E9 for ; Wed, 18 Nov 2009 08:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTtWZT5USmQI for ; Wed, 18 Nov 2009 08:22:00 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 7E8DB28C100 for ; Wed, 18 Nov 2009 08:22:00 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KTB00EJ7C4LSEF0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 18 Nov 2009 17:21:57 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.44,766,1249250400"; d="scan'208";a="34339553" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 18 Nov 2009 17:21:57 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KTB000PPC4L9D80@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 18 Nov 2009 17:21:57 +0100 (CET) From: Alexander Zimmermann In-reply-to: <20091118160001.B7DE628C103@core3.amsl.com> Date: Wed, 18 Nov 2009 17:21:57 +0100 Message-id: <441066B9-07B6-4893-8D03-AA889971AE94@nets.rwth-aachen.de> References: <20091118160001.B7DE628C103@core3.amsl.com> To: "tcpm@ietf.org WG Extensions" X-Mailer: Apple Mail (2.1077) Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-lcd-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:22:02 -0000 Hi Folks, the first working group version of the connectivity disruption draft is finished. In my opinion the document is feature complete. In particular, we reorganized and heavily extended the discussion section (ambiguity problems, wrapped sequence numbers, packet duplication) and introduced an interoperability issue section (ECN, Tunnels, ICMPv6, ...). Alex --- Changes from draft-zimmermann-tcp-lcd-02 o Incorporated feedback submitted by Ilpo Jarvinen. o Incorporated feedback submitted by Pasi Sarolahti. o Incorporated feedback submitted by Joe Touch. o Extended and reorganized the discussion (Section 5): * Every discussion item got its own title, so that we have a better overview. * Extended Retransmission Ambiguity section. Added also some references to the historical retransmission ambiguity problem. * Heavily extended discussion about wrapped sequence numbers (see Joe's comments). * Described the influence of packet duplication on the algorithm (Thanks to Ilpo). * The section "Protecting Against Misbehaving Routers" is not a subsection anymore. Moreover, the section was renamed to "Dissolving Ambiguity Issues" and has now real content. o An interoperability issues section (Section 7) was added. In particular comments to ECN, ICMPv6, and to the two thresholds R1 and R2 of [RFC1122] (Section 4.2.3.5) were added. o Miscellaneous editorial changes. In particular, the algorithm has a name now: TCP-LCD. Am 18.11.2009 um 17:00 schrieb : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > > Title : Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) > Author(s) : A. Zimmermann, A. Hannemann > Filename : draft-ietf-tcpm-tcp-lcd-00.txt > Pages : 25 > Date : 2009-11-17 > > Disruptions in end-to-end path connectivity, which last longer than > one retransmission timeout cause suboptimal TCP performance. The > reason for the performance degradation is that TCP interprets segment > loss induced by long connectivity disruptions as a sign of > congestion, resulting in repeated retransmission timer backoffs. > This leads in turn to a deferred detection of the re-establishment of > the connection since TCP waits until the next retransmission timeout > occurs before attempting the retransmission. > > This document proposes a algorithm for making TCP more robust to long > connectivity disruptions (TCP-LCD). The memo describes how standard > ICMP messages can be exploited during timeout-based loss recovery to > disambiguate true congestion loss from non-congestion loss caused by > connectivity disruptions. Moreover, a revert strategy of the > retransmission timer is specified that enables a more prompt > detection of whether the connectivity to a previously disconnected > peer node has been restored or not. TCP-LCD is a TCP sender-only > modification that effectively improves TCP performance in presence of > connectivity disruptions. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 21, 2010. > > Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-lcd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // From root@core3.amsl.com Wed Nov 18 11:15:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 563FD3A6860; Wed, 18 Nov 2009 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091118191501.563FD3A6860@core3.amsl.com> Date: Wed, 18 Nov 2009 11:15:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-early-rexmt-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Early Retransmit for TCP and SCTP Author(s) : M. Allman, K. Avrachenkov, U. Ayesta, E. Blanton, P. Hurtig Filename : draft-ietf-tcpm-early-rexmt-03.txt Pages : 12 Date : 2009-11-18 This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-early-rexmt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-18110713.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Mon Nov 23 10:17:37 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2623A6819 for ; Mon, 23 Nov 2009 10:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4-czlFvNTpA for ; Mon, 23 Nov 2009 10:17:36 -0800 (PST) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 29B2E3A67D6 for ; Mon, 23 Nov 2009 10:17:36 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id CF6BB260283; Mon, 23 Nov 2009 12:17:31 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nANIHVGc012715; Mon, 23 Nov 2009 12:17:31 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Mon, 23 Nov 2009 12:17:31 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Gregory Lebovitz , Joe Touch Date: Mon, 23 Nov 2009 12:17:30 -0600 Thread-Topic: [tcpm] working group status 11/17/09 Thread-Index: Acpn0H9Xj4OCWjxiTsaf1nBLy1cYrQEl8Prw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-23_10:2009-11-16, 2009-11-23, 2009-11-23 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:17:37 -0000 draft-touch-tcp-ao-nat should definitely be on the list; thanks for the reminder :). So far, there have been a couple of people that said they'd support this as part of AO, but not very many. I haven't seen anything indicating there are people against it yet either ... it would be good to hear what more people think about this as part of the AO WGLC that's in-progress. If there's reasonable support, it sounds like Joe is willing to roll it into the AO draft after WGLC. -- Wes Eddy MTI Systems >-----Original Message----- >From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] >Sent: Tuesday, November 17, 2009 4:54 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Joe Touch >Cc: tcpm@ietf.org >Subject: Re: [tcpm] working group status 11/17/09 > >should we also list here the current draft on NAT-Traversal for TCP-AO? >It's not a WG item, but it is being done as a possible (likely?) textual >addition to a WG item. comment? > >Gregory. > > >On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC >AEROSPACE CORP] wrote: > > > Hello; since TCPM didn't meet in Hiroshima, but we do have > several documents in the process of being finished up, and > a couple others in the process of starting, here's a quick > snapshot of the TCPM working group status and the actions > needed on each document; please let us know if we left > anything out: > > > Active WG Items > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > TCP Authentication Option > http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt > Milestone Target: Proposed Standard in April 2009 > Action: In WGLC until 11/24/09 > > TCP Authentication Option Crypto > http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > Milestone Target: Proposed Standard with AO spec > Action: In WGLC until 11/24/09 > > ICMP Attacks > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt > Milestone Target: Informational in July 2009 > Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update >based on WGLC > > Early-Retransmit > http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt > Milestone Target: Experimental in July 2009 > Action: WGLC finished & authors updated (action with chairs to >forward to IESG) > > 1323bis > http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt > Milestone Target: Proposed Standard in July 2009 > Action: Revise & WGLC (action with D. Borman) > > MSS Option > http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt > Milestone Target: Proposed Standard in July 2009 > Action: WGLC started 8/19, ended 9/8 (extended), being updated >based on several > of the comments (action with D. Borman) > > Urgent Pointer > http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt > Milestone Target: Proposed Standard in January 2010 > Action: Continue WG reviews; authors have indicated it is ready >for WGLC; > planned to start WGLC after AO WGLC completes > > TCP Security > http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt > Milestone Target: BCP in August 2010 > Action: 00-draft / outline has been under active discussion; but >not attained > very clear consensus > WG might begin working on recommendations while still >looking for a > possible compromise on outline (action with Fernando >Gont) > > Long Connectivity Disruptions > http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd- >02.txt > (need to submit WG version) > Milestone Target: Experimental in October 2010 > Action: need WG to read/discuss > authors to submit revision (action with Zimmerman) > > SACK Entry > http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt > Milestone Target: Proposed Standard in October 2010 > Action: need WG to read/discuss > TBD how this relates to 3517 > > > Other Proposals > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Persist > http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt > Action: WG Review > > Timestamps > http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt > Action: ??? > > Parameter Tuning > (no I-D yet) > Action: continue good discussion on mailing list > presentation given in Stockholm > > TCP Option for Transparent Middlebox Discovery > http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery- >03.txt > Action: Needs WG review / discussion > discussion on mailing list has been productive > > NewReno Modification > http://www.ietf.org/internet-drafts/draft-nishida-newreno- >modification-01.txt > Action: need WG to read/discuss > presentation given, but WG list not yet polled for adoption > > Recent discussions opened on Rate-Halving > http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt > Action: mailing list discussion about the history of this, and >whether > it needs to be revived > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > >-- >---- >IETF related email from >Gregory M. Lebovitz >Juniper Networks From lars.eggert@nokia.com Mon Nov 23 10:50:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933F73A68E9 for ; Mon, 23 Nov 2009 10:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elDiArZ7OPwC for ; Mon, 23 Nov 2009 10:50:54 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 069773A6819 for ; Mon, 23 Nov 2009 10:50:53 -0800 (PST) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nANIoc1k031509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2009 20:50:40 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-3--625320006; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Mon, 23 Nov 2009 20:50:37 +0200 Message-Id: <9782923D-02AB-4657-9850-765B6184740A@nokia.com> References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Mon, 23 Nov 2009 20:50:40 +0200 (EET) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:50:55 -0000 --Apple-Mail-3--625320006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, without wearing any hats: if it can be added very quickly, i.e., = O(days), I'd be mildly in favor. Otherwise, let's just ship what we have = now. Lars On 2009-11-23, at 20:17, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: > draft-touch-tcp-ao-nat should definitely be on the list; > thanks for the reminder :). >=20 > So far, there have been a couple of people that said they'd > support this as part of AO, but not very many. I haven't > seen anything indicating there are people against it yet > either ... it would be good to hear what more people think > about this as part of the AO WGLC that's in-progress. If > there's reasonable support, it sounds like Joe is willing > to roll it into the AO draft after WGLC. >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 >> -----Original Message----- >> From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] >> Sent: Tuesday, November 17, 2009 4:54 PM >> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Joe Touch >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] working group status 11/17/09 >>=20 >> should we also list here the current draft on NAT-Traversal for = TCP-AO? >> It's not a WG item, but it is being done as a possible (likely?) = textual >> addition to a WG item. comment? >>=20 >> Gregory. >>=20 >>=20 >> On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC >> AEROSPACE CORP] wrote: >>=20 >>=20 >> Hello; since TCPM didn't meet in Hiroshima, but we do have >> several documents in the process of being finished up, and >> a couple others in the process of starting, here's a quick >> snapshot of the TCPM working group status and the actions >> needed on each document; please let us know if we left >> anything out: >>=20 >>=20 >> Active WG Items >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> TCP Authentication Option >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt >> Milestone Target: Proposed Standard in April 2009 >> Action: In WGLC until 11/24/09 >>=20 >> TCP Authentication Option Crypto >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt >> Milestone Target: Proposed Standard with AO spec >> Action: In WGLC until 11/24/09 >>=20 >> ICMP Attacks >> http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt >> Milestone Target: Informational in July 2009 >> Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update >> based on WGLC >>=20 >> Early-Retransmit >> http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt >> Milestone Target: Experimental in July 2009 >> Action: WGLC finished & authors updated (action with chairs to >> forward to IESG) >>=20 >> 1323bis >> http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt >> Milestone Target: Proposed Standard in July 2009 >> Action: Revise & WGLC (action with D. Borman) >>=20 >> MSS Option >> http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt >> Milestone Target: Proposed Standard in July 2009 >> Action: WGLC started 8/19, ended 9/8 (extended), being updated >> based on several >> of the comments (action with D. Borman) >>=20 >> Urgent Pointer >> http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt >> Milestone Target: Proposed Standard in January 2010 >> Action: Continue WG reviews; authors have indicated it is ready >> for WGLC; >> planned to start WGLC after AO WGLC completes >>=20 >> TCP Security >> http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt >> Milestone Target: BCP in August 2010 >> Action: 00-draft / outline has been under active discussion; but >> not attained >> very clear consensus >> WG might begin working on recommendations while still >> looking for a >> possible compromise on outline (action with Fernando >> Gont) >>=20 >> Long Connectivity Disruptions >> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd- >> 02.txt >> (need to submit WG version) >> Milestone Target: Experimental in October 2010 >> Action: need WG to read/discuss >> authors to submit revision (action with Zimmerman) >>=20 >> SACK Entry >> = http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt >> Milestone Target: Proposed Standard in October 2010 >> Action: need WG to read/discuss >> TBD how this relates to 3517 >>=20 >>=20 >> Other Proposals >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Persist >> http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt >> Action: WG Review >>=20 >> Timestamps >> http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt >> Action: ??? >>=20 >> Parameter Tuning >> (no I-D yet) >> Action: continue good discussion on mailing list >> presentation given in Stockholm >>=20 >> TCP Option for Transparent Middlebox Discovery >> http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery- >> 03.txt >> Action: Needs WG review / discussion >> discussion on mailing list has been productive >>=20 >> NewReno Modification >> http://www.ietf.org/internet-drafts/draft-nishida-newreno- >> modification-01.txt >> Action: need WG to read/discuss >> presentation given, but WG list not yet polled for = adoption >>=20 >> Recent discussions opened on Rate-Halving >> http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt >> Action: mailing list discussion about the history of this, and >> whether >> it needs to be revived >>=20 >> -- >> Wes Eddy >> MTI Systems >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> ---- >> IETF related email from >> Gregory M. Lebovitz >> Juniper Networks >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-3--625320006 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEyMzE4NTAzOFowIwYJKoZIhvcNAQkEMRYEFEszy/DkxdeKDKf7IuurjmJ5UVhmMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBQTg1AwwDubHJ0faTWQu9ABUVRkWduqwrITo9XHjOmDL3ii19dxFXeauIQ1bqiJwGcnejb biDgyKB8IMAXa2lD9dIiEXOijbPP6dS1M9muSohqIynmj8PmYuvAUAsDkRrC6MQgfstX0CI0eTVk k/YpBT1E2OfW3SiqwMNXPfDC0G3FtJVzRH4mzxbtv+GlJXcrqzXd/l4s3KdoMI7iwgk9LyrTA30D eKEef7m7I9QOP1iR77j3v41VB/paFgwKsR3FqIza/HSdfdszBFUI/sJjUVN4rX3rgsfV4qumGp5g AgfrpZE2342WrzZTzU5YRkf9zZgKim0ueY4vvFWafCsdAAAAAAAA --Apple-Mail-3--625320006-- From touch@ISI.EDU Mon Nov 23 10:59:16 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D7E3A6980 for ; Mon, 23 Nov 2009 10:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owA1aIm5UqD0 for ; Mon, 23 Nov 2009 10:59:15 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BB1253A6806 for ; Mon, 23 Nov 2009 10:59:15 -0800 (PST) Received: from [75.214.125.149] (149.sub-75-214-125.myvzw.com [75.214.125.149]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id nANIuXtH011470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Nov 2009 10:56:34 -0800 (PST) Message-ID: <4B0ADAE1.6030509@isi.edu> Date: Mon, 23 Nov 2009 10:56:33 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <9782923D-02AB-4657-9850-765B6184740A@nokia.com> In-Reply-To: <9782923D-02AB-4657-9850-765B6184740A@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: nANIuXtH011470 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:59:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > Hi, > > without wearing any hats: if it can be added very quickly, i.e., > O(days), I'd be mildly in favor. Otherwise, let's just ship what we have > now. Once/if I get a go-ahead, that's all it'd take. There isn't much to it. Joe > On 2009-11-23, at 20:17, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > >> draft-touch-tcp-ao-nat should definitely be on the list; >> thanks for the reminder :). >> >> So far, there have been a couple of people that said they'd >> support this as part of AO, but not very many. I haven't >> seen anything indicating there are people against it yet >> either ... it would be good to hear what more people think >> about this as part of the AO WGLC that's in-progress. If >> there's reasonable support, it sounds like Joe is willing >> to roll it into the AO draft after WGLC. >> >> -- >> Wes Eddy >> MTI Systems >> >> >>> -----Original Message----- >>> From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] >>> Sent: Tuesday, November 17, 2009 4:54 PM >>> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; Joe Touch >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] working group status 11/17/09 >>> >>> should we also list here the current draft on NAT-Traversal for TCP-AO? >>> It's not a WG item, but it is being done as a possible (likely?) textual >>> addition to a WG item. comment? >>> >>> Gregory. >>> >>> >>> On Tue, Nov 17, 2009 at 6:23 AM, Eddy, Wesley M. (GRC-MS00)[ASRC >>> AEROSPACE CORP] wrote: >>> >>> >>> Hello; since TCPM didn't meet in Hiroshima, but we do have >>> several documents in the process of being finished up, and >>> a couple others in the process of starting, here's a quick >>> snapshot of the TCPM working group status and the actions >>> needed on each document; please let us know if we left >>> anything out: >>> >>> >>> Active WG Items >>> =============== >>> >>> TCP Authentication Option >>> http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt >>> Milestone Target: Proposed Standard in April 2009 >>> Action: In WGLC until 11/24/09 >>> >>> TCP Authentication Option Crypto >>> http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt >>> Milestone Target: Proposed Standard with AO spec >>> Action: In WGLC until 11/24/09 >>> >>> ICMP Attacks >>> http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt >>> Milestone Target: Informational in July 2009 >>> Action: WGLC started 9/1, ended 9/15 ... Fernando Gont to update >>> based on WGLC >>> >>> Early-Retransmit >>> http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-02.txt >>> Milestone Target: Experimental in July 2009 >>> Action: WGLC finished & authors updated (action with chairs to >>> forward to IESG) >>> >>> 1323bis >>> http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt >>> Milestone Target: Proposed Standard in July 2009 >>> Action: Revise & WGLC (action with D. Borman) >>> >>> MSS Option >>> http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt >>> Milestone Target: Proposed Standard in July 2009 >>> Action: WGLC started 8/19, ended 9/8 (extended), being updated >>> based on several >>> of the comments (action with D. Borman) >>> >>> Urgent Pointer >>> http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-01.txt >>> Milestone Target: Proposed Standard in January 2010 >>> Action: Continue WG reviews; authors have indicated it is ready >>> for WGLC; >>> planned to start WGLC after AO WGLC completes >>> >>> TCP Security >>> http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-00.txt >>> Milestone Target: BCP in August 2010 >>> Action: 00-draft / outline has been under active discussion; but >>> not attained >>> very clear consensus >>> WG might begin working on recommendations while still >>> looking for a >>> possible compromise on outline (action with Fernando >>> Gont) >>> >>> Long Connectivity Disruptions >>> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd- >>> 02.txt >>> (need to submit WG version) >>> Milestone Target: Experimental in October 2010 >>> Action: need WG to read/discuss >>> authors to submit revision (action with Zimmerman) >>> >>> SACK Entry >>> http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-00.txt >>> Milestone Target: Proposed Standard in October 2010 >>> Action: need WG to read/discuss >>> TBD how this relates to 3517 >>> >>> >>> Other Proposals >>> =============== >>> >>> Persist >>> http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt >>> Action: WG Review >>> >>> Timestamps >>> http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt >>> Action: ??? >>> >>> Parameter Tuning >>> (no I-D yet) >>> Action: continue good discussion on mailing list >>> presentation given in Stockholm >>> >>> TCP Option for Transparent Middlebox Discovery >>> http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery- >>> 03.txt >>> Action: Needs WG review / discussion >>> discussion on mailing list has been productive >>> >>> NewReno Modification >>> http://www.ietf.org/internet-drafts/draft-nishida-newreno- >>> modification-01.txt >>> Action: need WG to read/discuss >>> presentation given, but WG list not yet polled for adoption >>> >>> Recent discussions opened on Rate-Halving >>> http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt >>> Action: mailing list discussion about the history of this, and >>> whether >>> it needs to be revived >>> >>> -- >>> Wes Eddy >>> MTI Systems >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> >>> >>> -- >>> ---- >>> IETF related email from >>> Gregory M. Lebovitz >>> Juniper Networks >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksK2uAACgkQE5f5cImnZruo0wCeK+6XXplBONa/3oSV/LtRonZH yFQAoIStiEWiW1mYtLwqDEFHOXUpgw9N =DH1+ -----END PGP SIGNATURE----- From hkchu@google.com Mon Nov 23 19:49:07 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2BF3A67BE for ; Mon, 23 Nov 2009 19:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqNaWxBEidhZ for ; Mon, 23 Nov 2009 19:49:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C14603A67DA for ; Mon, 23 Nov 2009 19:49:06 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id nAO3n1gb005875 for ; Mon, 23 Nov 2009 19:49:02 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259034542; bh=5KmfDZXsl8yfGs0ubk1P2X/ulIg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=vrcB4gJRHruLp/Tb9hLdhLQGEFBlfmQ49Pc/EePc0Pbxnyn6DIAYtw7j2b5chs+dQ wPAeJOmIl9XUKx44d6wAA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=WiqHQ3/eP9SGimEKSJCoRQKoiog6mARbEO5KJ+eVfuQ1ME0MX5nzRG+OJzX9CrTub Dx57AfuO5e4rQfGXImmuA== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by spaceape11.eur.corp.google.com with ESMTP id nAO3muWp016428 for ; Mon, 23 Nov 2009 19:48:59 -0800 Received: by pwi6 with SMTP id 6so3988761pwi.9 for ; Mon, 23 Nov 2009 19:48:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.121.30 with SMTP id t30mr428565wfc.283.1259034536119; Mon, 23 Nov 2009 19:48:56 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Nov 2009 19:48:56 -0800 Message-ID: From: Jerry Chu To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 03:49:07 -0000 > > Parameter Tuning > (no I-D yet) > Action: continue good discussion on mailing list > =A0 =A0 =A0 =A0presentation given in Stockholm An update on this topic: (my original presentation can be found at http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf) After some long off-list discussion between Mark Allman and I on many gory details, we have agreed on the basic reduction of the initRTO from 3secs to 1sec, only during 3WHS, only ONCE and exponentially backed off from there. I hereby request this proposal to be adopted as a WG item. Please let me know what's needed for this request to be considered. Mark doesn't seem to think a separate document is needed. Instead a rev (whatever that means) to RFC2988 may suffice. Separately I'd like to propose a moderate increase of the initcwnd from what is specified in RFC3390 to ~15KB, or 10 segments for IP/Ethernet. I understand how to speed up TCP's slow start has been an area of active research, with many proposals on the table (jump/quick/swift/ fast starts,..., etc). But none of the proposals seems ready to go forward to become an IETF standard anytime soon. (Some require router support hence are pretty much out of the question for the public Internet in the foreseeable future). In order to better take advantage of today's much faster Internet sooner, a moderate increase of initcwnd seems a good interim solution. I will send out more details later. In the mean time if anyone has an opinion on this please feel free to share. Jerry > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wwwrun@core3.amsl.com Tue Nov 24 08:15:57 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BE9A63A6A6E; Tue, 24 Nov 2009 08:15:57 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091124161557.BE9A63A6A6E@core3.amsl.com> Date: Tue, 24 Nov 2009 08:15:57 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-early-rexmt (Early Retransmit for TCP and SCTP) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:15:58 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Early Retransmit for TCP and SCTP ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17706&rfc_flag=0 From touch@ISI.EDU Tue Nov 24 09:44:14 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D9E3A688E for ; Tue, 24 Nov 2009 09:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKlqL+zQEGTz for ; Tue, 24 Nov 2009 09:44:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3A6F43A6889 for ; Tue, 24 Nov 2009 09:44:14 -0800 (PST) Received: from [75.212.132.192] (192.sub-75-212-132.myvzw.com [75.212.132.192]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAOHhd7H025886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 09:43:42 -0800 (PST) Message-ID: <4B0C1B4B.5030806@isi.edu> Date: Tue, 24 Nov 2009 09:43:39 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:44:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Jerry, Jerry Chu wrote: ... > Separately I'd like to propose a moderate increase of the initcwnd > from what is specified in RFC3390 to ~15KB, or 10 segments for > IP/Ethernet. The jump from 1 segment to 4KB took quite a bit of analysis, even though the basis of the change had been widely deployed as an implementation bug. I suspect it would take similar analysis to ensure that this would be safe today, including the effect on home gateways, PDAs, etc. You are also possibly talking about 30 segments, until path MTU discovery kicks in. So you're going from 4K or 4 segments (whichever is smaller) to 15K or ?? segments (10? 30?). Granted this may already be the common case for persistent connections going active after draining the data, but it's not clear that such behavior dominates Internet traffic to a point that the current operational evidence can be used to validate that this is safe. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksMG0oACgkQE5f5cImnZrv7VwCfWgK4n0yOxFoIwbsBfmKx9pZU 9IgAn3wH6mX26Jn6EPjaUz1J838wT8aw =HnjU -----END PGP SIGNATURE----- From wesley.m.eddy@nasa.gov Tue Nov 24 09:55:42 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4173A687D for ; Tue, 24 Nov 2009 09:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOkgBkdE2e8D for ; Tue, 24 Nov 2009 09:55:41 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 040893A6889 for ; Tue, 24 Nov 2009 09:55:40 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 3471C32842E; Tue, 24 Nov 2009 11:55:36 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id nAOHtavG015922; Tue, 24 Nov 2009 11:55:36 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 24 Nov 2009 11:55:36 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Jerry Chu Date: Tue, 24 Nov 2009 11:55:33 -0600 Thread-Topic: [tcpm] working group status 11/17/09 Thread-Index: AcpsuQ/hKhXLGTboSg+Mx5ePCN2NyAAdMUSg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-24_07:2009-11-16, 2009-11-24, 2009-11-24 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:55:42 -0000 Hi Jerry. The way we update RFCs is to write more RFCs :). In the case of the modifications you're talking about, I'm not sure if we really want to actually update the standards- track documents or simply write an Experimental document on parameter tuning. Given the subject matter, even an Experimental RFC may take some time and debate to arrive at. In either case, I think the starting point is to write an Internet-Draft that describes and discusses the set of changes in sufficient detail, and then we can poll this working group on whether or not to adopt one or more work items for either Experimental or updates to the standards- track. Information on writing and submitting Internet-Drafts is on the IETF webpage here: http://www.ietf.org/id-info/ -- Wes Eddy MTI Systems >-----Original Message----- >From: Jerry Chu [mailto:hkchu@google.com] >Sent: Monday, November 23, 2009 10:49 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Cc: tcpm@ietf.org >Subject: Re: [tcpm] working group status 11/17/09 > > >> >> Parameter Tuning >> (no I-D yet) >> Action: continue good discussion on mailing list >> =A0 =A0 =A0 =A0presentation given in Stockholm > >An update on this topic: (my original presentation can be found at >http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf) > >After some long off-list discussion between Mark Allman and I on >many gory details, we have agreed on the basic reduction of the >initRTO from 3secs to 1sec, only during 3WHS, only ONCE and >exponentially backed off from there. I hereby request this proposal >to be adopted as a WG item. Please let me know what's needed for >this request to be considered. Mark doesn't seem to think a >separate document is needed. Instead a rev (whatever that means) >to RFC2988 may suffice. > >Separately I'd like to propose a moderate increase of the initcwnd >from what is specified in RFC3390 to ~15KB, or 10 segments for >IP/Ethernet. > >I understand how to speed up TCP's slow start has been an area of >active research, with many proposals on the table (jump/quick/swift/ >fast starts,..., etc). But none of the proposals seems ready to go >forward to become an IETF standard anytime soon. (Some require >router support hence are pretty much out of the question for the >public Internet in the foreseeable future). > >In order to better take advantage of today's much faster Internet >sooner, a moderate increase of initcwnd seems a good interim >solution. I will send out more details later. In the mean time if >anyone has an opinion on this please feel free to share. > >Jerry > >> Wes Eddy >> MTI Systems >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From hkchu@google.com Tue Nov 24 18:24:54 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C26928C177 for ; Tue, 24 Nov 2009 18:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v8KvOG031Bc for ; Tue, 24 Nov 2009 18:24:53 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 250B528C16A for ; Tue, 24 Nov 2009 18:24:53 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id nAP2Omk2018437 for ; Tue, 24 Nov 2009 18:24:48 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259115888; bh=3yEmhHc094dnAW703Z0in5eUPoY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rkQUs78KQTLaeOC9Xynr5XyGZIE4j/mfzy2Ddq4YewbHdTso3cNaw4jqG0BMKM7H7 Oyidr3dF6bg3c2jOA+brg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=V2pXxfGJqPHMMLpYdMLZC+u5yZXti7JVh4xvt6BAhL6URIgawCea4d+ZSYETeQ0oB VemCwY+BLi5uBnllPI6kw== Received: from pwj21 (pwj21.prod.google.com [10.241.219.85]) by zps37.corp.google.com with ESMTP id nAP2OYQw025309 for ; Tue, 24 Nov 2009 18:24:45 -0800 Received: by pwj21 with SMTP id 21so5642119pwj.8 for ; Tue, 24 Nov 2009 18:24:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.209.20 with SMTP id h20mr840629wfg.36.1259115884866; Tue, 24 Nov 2009 18:24:44 -0800 (PST) In-Reply-To: <4B0C1B4B.5030806@isi.edu> References: <4B0C1B4B.5030806@isi.edu> Date: Tue, 24 Nov 2009 18:24:44 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 02:24:54 -0000 Hi Joe, On Tue, Nov 24, 2009 at 9:43 AM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Jerry, > > Jerry Chu wrote: > ... >> Separately I'd like to propose a moderate increase of the initcwnd >> from what is specified in RFC3390 to ~15KB, or 10 segments for >> IP/Ethernet. > > The jump from 1 segment to 4KB took quite a bit of analysis, even though > the basis of the change had been widely deployed as an implementation bug. > > I suspect it would take similar analysis to ensure that this would be > safe today, including the effect on home gateways, PDAs, etc. Understood. (Actually I was involved in the effort to up initcwnd from 1 to 2 in the late 90' when Solaris' SPECWEB numbers blew up on our face due to the extended delay between Windows clients' delayed acks and Solaris servers' initcwnd of 1.) My hope this time is that, rather than relying extensively on simulations, we can leverage Google's vast network reach and determination to "make the web faster" (see http://code.google.com/speed/) to collect data from real experiments to better understand and devise ways to mitigate the negative impact, if any, from increasing initcwnd. > > You are also possibly talking about 30 segments, until path MTU > discovery kicks in. So you're going from 4K or 4 segments (whichever is > smaller) to 15K or ?? segments (10? 30?). We can work out the exact formula and put a cap on # of segments (e.g., 10). We would prefer to go higher than 10 but at this moment we still don't fully understand the negative impact (although small) to warrant the risk. OTOH we felt 6 or lower is too small to worth the effort. 10 may be a good balance between benefit vs risk. > > Granted this may already be the common case for persistent connections > going active after draining the data, but it's not clear that such > behavior dominates Internet traffic to a point that the current > operational evidence can be used to validate that this is safe. I think a greater problem is web browser's increasing use of more concurrent connections (I heard IE8 just up the # of concurrent connections per domain from 2 to 6), partly to circumvent the small initcwnd each TCP connection gets. To me this alleviates to some extent my own concern of a larger initcwnd. But it also speaks to the failure of this community to address the issue (or at least the perception that initcwnd is too small) sooner to prevent this bad practice from the browser vendors. Jerry > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksMG0oACgkQE5f5cImnZrv7VwCfWgK4n0yOxFoIwbsBfmKx9pZU > 9IgAn3wH6mX26Jn6EPjaUz1J838wT8aw > =HnjU > -----END PGP SIGNATURE----- > From touch@ISI.EDU Tue Nov 24 21:21:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7CD28C1CB for ; Tue, 24 Nov 2009 21:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhCeQWD8TDO4 for ; Tue, 24 Nov 2009 21:21:10 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6C13628C1AE for ; Tue, 24 Nov 2009 21:21:10 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAP5KgFT010093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 21:20:47 -0800 (PST) Message-ID: <4B0CBEAA.5090506@isi.edu> Date: Tue, 24 Nov 2009 21:20:42 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <4B0C1B4B.5030806@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 05:21:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Jerry, Jerry Chu wrote: ... >> > The jump from 1 segment to 4KB took quite a bit of analysis, even though >> > the basis of the change had been widely deployed as an implementation bug. >> > >> > I suspect it would take similar analysis to ensure that this would be >> > safe today, including the effect on home gateways, PDAs, etc. ... > My hope this time is that, rather than relying extensively on simulations, we > can leverage Google's vast network reach and determination to "make the web > faster" (see http://code.google.com/speed/) to collect data from real > experiments to better understand and devise ways to mitigate the negative > impact, if any, from increasing initcwnd. Experiments are useful. They are also repeatable. To the extent that real measurements can be used, that's better than simulations. However, real measurements will probably also show that simultaneous open never happens, and that more than a few TCP states are never entered. That's not sufficient to assert safety of a deployed modification. ... >> > Granted this may already be the common case for persistent connections >> > going active after draining the data, but it's not clear that such >> > behavior dominates Internet traffic to a point that the current >> > operational evidence can be used to validate that this is safe. > > I think a greater problem is web browser's increasing use of more concurrent > connections (I heard IE8 just up the # of concurrent connections per domain > from 2 to 6), partly to circumvent the small initcwnd each TCP connection > gets. To me this alleviates to some extent my own concern of a larger > initcwnd. But it also speaks to the failure of this community to address the > issue (or at least the perception that initcwnd is too small) sooner to > prevent this bad practice from the browser vendors. Well, it could also be that "bad coding expands to find all leaks". I.e., just because there's another way of doing something, doesn't make either way appropriate. We've known about burst-after-idle for a number of years now, and haven't gotten around to fixing that hole. If we did, the incentive to using multiple connections to get around small initcwnd would diminish as well. There's plenty of useful work to do... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksMvqkACgkQE5f5cImnZrtd2wCgwvnKLSY4kdluDV76TU+dWtAV Cy8An0YW9HJ39mEMigp2jmRA+sAZn9Ks =LkZy -----END PGP SIGNATURE----- From hkchu@google.com Tue Nov 24 22:05:55 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F813A6860 for ; Tue, 24 Nov 2009 22:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4mbxVnlpjfZ for ; Tue, 24 Nov 2009 22:05:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id A53833A69D0 for ; Tue, 24 Nov 2009 22:05:53 -0800 (PST) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id nAP65m0r013609 for ; Tue, 24 Nov 2009 22:05:48 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259129148; bh=SY69gfuhZ1BDI+df9aPmkaiLNKI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=DLxcxdGF8zdcS+vYuctdJJDbVokbetJRG1+YLCFE+XUZEXco+vL2gSsPirGW3u0+x M2UuAzYZrrc/z+lzpurpw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Ogk8CB/TlwPudmT09KVknSDhzWNiVb8At7jHqQm5DY1nA3V+zfSGYFo/q622YS1dq CIwseSaCb7s5ezjwD02xA== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by zps77.corp.google.com with ESMTP id nAP65jB4017451 for ; Tue, 24 Nov 2009 22:05:46 -0800 Received: by pxi12 with SMTP id 12so5385526pxi.3 for ; Tue, 24 Nov 2009 22:05:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.25.41 with SMTP id c41mr743395wfj.2.1259129145654; Tue, 24 Nov 2009 22:05:45 -0800 (PST) In-Reply-To: <4B0CBEAA.5090506@isi.edu> References: <4B0C1B4B.5030806@isi.edu> <4B0CBEAA.5090506@isi.edu> Date: Tue, 24 Nov 2009 22:05:45 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=001636e1f7ae73fc9f04792bd9a9 X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 06:05:55 -0000 --001636e1f7ae73fc9f04792bd9a9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 24, 2009 at 9:20 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Jerry, > > Jerry Chu wrote: > ... > >> > The jump from 1 segment to 4KB took quite a bit of analysis, even > though > >> > the basis of the change had been widely deployed as an implementation > bug. > >> > > >> > I suspect it would take similar analysis to ensure that this would be > >> > safe today, including the effect on home gateways, PDAs, etc. > ... > > My hope this time is that, rather than relying extensively on > simulations, we > > can leverage Google's vast network reach and determination to "make the > web > > faster" (see http://code.google.com/speed/) to collect data from real > > experiments to better understand and devise ways to mitigate the negative > > impact, if any, from increasing initcwnd. > > Experiments are useful. They are also repeatable. To the extent that > real measurements can be used, that's better than simulations. > > However, real measurements will probably also show that simultaneous > open never happens, and that more than a few TCP states are never > entered. That's not sufficient to assert safety of a deployed modification. > Correct in general but hopefully protocol correctness won't be an issue here, or if still is can most likely be understood or thought up deterministically. What's hard in the real, passive measurements that we've conducted is that the visibility into what really happened in the network is extremely limited. E.g., we could not accurately characterize those cases where an increased initcwnd is hurting, not by RTT, BDP, or measured b/w, which we typically use to identify "slow links". My guess is the last hop/access router buffer sizes may be the determining factor. But passive measurements just don't give us any visibility into that. > ... > >> > Granted this may already be the common case for persistent connections > >> > going active after draining the data, but it's not clear that such > >> > behavior dominates Internet traffic to a point that the current > >> > operational evidence can be used to validate that this is safe. > > > > I think a greater problem is web browser's increasing use of more > concurrent > > connections (I heard IE8 just up the # of concurrent connections per > domain > > from 2 to 6), partly to circumvent the small initcwnd each TCP connection > > gets. To me this alleviates to some extent my own concern of a larger > > initcwnd. But it also speaks to the failure of this community to address > the > > issue (or at least the perception that initcwnd is too small) sooner to > > prevent this bad practice from the browser vendors. > > Well, it could also be that "bad coding expands to find all leaks". > I.e., just because there's another way of doing something, doesn't make > either way appropriate. We've known about burst-after-idle for a number > of years now, and haven't gotten around to fixing that hole. If we did, > Hmm, I thought all stacks (or at least the two I've worked on) have slow-start -after-idle enabled by default... > the incentive to using multiple connections to get around small initcwnd > would diminish as well. > > There's plenty of useful work to do... > Sure there is. Jerry > > Joe > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > > iEYEARECAAYFAksMvqkACgkQE5f5cImnZrtd2wCgwvnKLSY4kdluDV76TU+dWtAV > Cy8An0YW9HJ39mEMigp2jmRA+sAZn9Ks > =LkZy > -----END PGP SIGNATURE----- > --001636e1f7ae73fc9f04792bd9a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2009 at 9:20 PM, Joe Touch <touch@isi.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Jerry,

Jerry Chu wrote:
...
>> > The jump from 1 segment to 4KB took q= uite a bit of analysis, even though
>> > the basis of the change had been widely deployed as an implem= entation bug.
>> >
>> > I suspect it would take similar analysis to ensure that this = would be
>> > safe today, including the effect on home gateways, PDAs, etc.=
...
> My hope this time is that, rather than relying exten= sively on simulations, we
> can leverage Google's vast network reach and determination to &quo= t;make the web
> faster" (see http://code.google.com/speed/) =A0to collect data from real
> experiments to better understand and devise ways to mitigate the negat= ive
> impact, if any, from increasing initcwnd.

Experiments are useful. They are also repeatable. To the extent that<= br> real measurements can be used, that's better than simulations.

However, real measurements will probably also show that simultaneous
open never happens, and that more than a few TCP states are never
entered. That's not sufficient to assert safety of a deployed modificat= ion.

Correct in general but hopefully protocol cor= rectness won't be an issue here,
or if still is can most likely be u= nderstood or thought up deterministically.

What's hard in the real, passive measurements that we've conduc= ted is that
the visibility into what really happened in the network is e= xtremely limited. E.g.,
we could not accurately characterize those cases= where an increased initcwnd
is hurting, not by RTT, BDP, or measured b/w, which we typically use to
= identify "slow links". My guess is the last hop/access router buf= fer sizes may
be the determining factor. But passive measurements just d= on't give us any
visibility into that.


...
>> > Granted this may already be the common case= for persistent connections
>> > going active after draining the data, but it's not clear = that such
>> > behavior dominates Internet traffic to a point that the curre= nt
>> > operational evidence can be used to validate that this is saf= e.
>
> I think a greater problem is web browser's increasing use of more = concurrent
> connections (I heard IE8 just up the # of concurrent connections per d= omain
> from 2 to 6), partly to circumvent the small initcwnd each TCP connect= ion
> gets. To me this alleviates to some extent my own concern of a larger<= br> > initcwnd. But it also speaks to the failure of this community to addre= ss the
> issue (or at least the perception that initcwnd is too small) sooner t= o
> prevent this bad practice from the browser vendors.

Well, it could also be that "bad coding expands to find all leak= s".
I.e., just because there's another way of doing something, doesn't = make
either way appropriate. We've known about burst-after-idle for a number=
of years now, and haven't gotten around to fixing that hole. If we did,=

Hmm, I thought all stacks (or at least the two I&= #39;ve worked on) have slow-start
-after-idle enabled by default...
=A0
the incentive to using multiple connections to get around small initcwnd would diminish as well.

There's plenty of useful work to do...

Sure th= ere is.

Jerry
=A0

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksMvqkACgkQE5f5cImnZrtd2wCgwvnKLSY4kdluDV76TU+dWtAV
Cy8An0YW9HJ39mEMigp2jmRA+sAZn9Ks
=3DLkZy
-----END PGP SIGNATURE-----

--001636e1f7ae73fc9f04792bd9a9-- From rs@netapp.com Wed Nov 25 06:36:56 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F11C3A6931 for ; Wed, 25 Nov 2009 06:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlXFhopTdzop for ; Wed, 25 Nov 2009 06:36:55 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id AD2FA3A68D3 for ; Wed, 25 Nov 2009 06:36:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,286,1257148800"; d="scan'208";a="105978196" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 25 Nov 2009 06:36:38 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (ldcrsexc2-prd.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nAPEabl1001619; Wed, 25 Nov 2009 06:36:38 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 14:36:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 14:36:32 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0688169A@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] working group status 11/17/09 Thread-Index: AcptdnlfOYcg7cpHRrOWuytRFP4pYgAY+tEg From: "Scheffenegger, Richard" To: "Jerry Chu" , "Joe Touch" X-OriginalArrivalTime: 25 Nov 2009 14:36:37.0712 (UTC) FILETIME=[B1D32D00:01CA6DDC] Cc: tcpm@ietf.org Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:36:56 -0000 Hi Jerry, Have you though about the implications of increasing initcwnd to a=20 level, which exceeds the buffering capacity of your L2 devices?=20 I have observed hosts, which can repeatedly cause heavy packet loss=20 due to droptail in a L2 switch, even with a burst size of as little=20 as 4-6 frames... These hosts are simply capable of wirespeed sending,=20 while the L2 switch is not (or, a common downstream link is slightly=20 saturated). L2 boxes don't seem to feature that much buffering (ie. 40 frames),=20 thus will enhance the negative effects of any packet burst. (When the=20 L2 buffers are full, and a new session bursts 15+ frames all at once=20 into the L2 box.).=20 IMHO, some basic pacing should be made mandatory when cwnd is mostly=20 empty, to break bursts and deal with slower-than-wirespeed L2 devices=20 in the path... (Tweaking the IFG, or doing some multiplexing with other streams=20 right at the sender side, might work - but this requires a lower layer entity to perform that, not TCP all by itself... You might even argue, that this is an implementation specific tweak, rather than a TCP=20 algrithm all along. Just my 0.02 EUR. Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 =20 > -----Original Message----- > From: Jerry Chu [mailto:hkchu@google.com]=20 > Sent: Mittwoch, 25. November 2009 03:25 > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] working group status 11/17/09 >=20 > Hi Joe, >=20 > On Tue, Nov 24, 2009 at 9:43 AM, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, Jerry, > > > > Jerry Chu wrote: > > ... > >> Separately I'd like to propose a moderate increase of the initcwnd=20 > >> from what is specified in RFC3390 to ~15KB, or 10 segments for=20 > >> IP/Ethernet. > > > > The jump from 1 segment to 4KB took quite a bit of analysis, even=20 > > though the basis of the change had been widely deployed as=20 > an implementation bug. > > > > I suspect it would take similar analysis to ensure that=20 > this would be=20 > > safe today, including the effect on home gateways, PDAs, etc. >=20 > Understood. (Actually I was involved in the effort to up=20 > initcwnd from 1 to 2 in the late 90' when Solaris' SPECWEB=20 > numbers blew up on our face due to the extended delay between=20 > Windows clients' delayed acks and Solaris servers' initcwnd of 1.) >=20 > My hope this time is that, rather than relying extensively on=20 > simulations, we can leverage Google's vast network reach and=20 > determination to "make the web faster" (see=20 > http://code.google.com/speed/) to collect data from real=20 > experiments to better understand and devise ways to mitigate=20 > the negative impact, if any, from increasing initcwnd. >=20 > > > > You are also possibly talking about 30 segments, until path MTU=20 > > discovery kicks in. So you're going from 4K or 4 segments=20 > (whichever=20 > > is > > smaller) to 15K or ?? segments (10? 30?). >=20 > We can work out the exact formula and put a cap on # of=20 > segments (e.g., 10). > We would prefer to go higher than 10 but at this moment we=20 > still don't fully understand the negative impact (although=20 > small) to warrant the risk. > OTOH we felt 6 or lower is too small to worth the effort. 10=20 > may be a good balance between benefit vs risk. >=20 > > > > Granted this may already be the common case for persistent=20 > connections=20 > > going active after draining the data, but it's not clear that such=20 > > behavior dominates Internet traffic to a point that the current=20 > > operational evidence can be used to validate that this is safe. >=20 > I think a greater problem is web browser's increasing use of=20 > more concurrent connections (I heard IE8 just up the # of=20 > concurrent connections per domain from 2 to 6), partly to=20 > circumvent the small initcwnd each TCP connection gets. To me=20 > this alleviates to some extent my own concern of a larger=20 > initcwnd. But it also speaks to the failure of this community=20 > to address the issue (or at least the perception that=20 > initcwnd is too small) sooner to prevent this bad practice=20 > from the browser vendors. >=20 > Jerry >=20 > > > > Joe > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (MingW32) > > > > iEYEARECAAYFAksMG0oACgkQE5f5cImnZrv7VwCfWgK4n0yOxFoIwbsBfmKx9pZU > > 9IgAn3wH6mX26Jn6EPjaUz1J838wT8aw > > =3DHnjU > > -----END PGP SIGNATURE----- > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@ISI.EDU Wed Nov 25 10:53:51 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0C03A6AF2 for ; Wed, 25 Nov 2009 10:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xnn94PyZzEm for ; Wed, 25 Nov 2009 10:53:50 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6D60B3A67A2 for ; Wed, 25 Nov 2009 10:53:50 -0800 (PST) Received: from [192.168.1.43] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id nAPIrMx0022622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2009 10:53:24 -0800 (PST) Message-ID: <4B0D7D22.6080707@isi.edu> Date: Wed, 25 Nov 2009 10:53:22 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jerry Chu References: <4B0C1B4B.5030806@isi.edu> <4B0CBEAA.5090506@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:53:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerry Chu wrote: ... > Hmm, I thought all stacks (or at least the two I've worked on) have > slow-start-after-idle enabled by default... See: John Heidemann, Katia Obraczka, and Joe Touch, "Modeling the Performance of HTTP Over Several Transport Protocols" IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630. After idle, the client sends a short GET out fast even with slow-start. The server receives the GET, thinks that "time since last received" defines idle, rather than "time since last sent" as it should be. This is addressed in the paper. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAksNfSIACgkQE5f5cImnZruemQCfe3D4JMqcwDuWnJY2MtTfXQ6x JTIAnR5lSCgn3QgmRshi4UdtErMiIRFI =UflF -----END PGP SIGNATURE----- From hkchu@google.com Wed Nov 25 11:56:11 2009 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA543A694C for ; Wed, 25 Nov 2009 11:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.075 X-Spam-Level: X-Spam-Status: No, score=-105.075 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, LONGWORDS=1.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XXH7ZdB7lPL for ; Wed, 25 Nov 2009 11:56:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 0DBCF3A6AF0 for ; Wed, 25 Nov 2009 11:56:10 -0800 (PST) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id nAPJu2pk001261 for ; Wed, 25 Nov 2009 11:56:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259178964; bh=pzbiDlYwD6VkoPq3/yviw2ymqnk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=PE/6h67DN2zRHaZKnpxobHDvBcjkNbFDaOzgkpQLnHdlId+D2uHSY995wVg8s763x zZFloeRa/g4/1a93j7XSQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=TPyhrZkVfxUoDgwUYXeotuvkKZjwceIJD9F8YzWUCONH9Ik+6P1IEsHqht8xGqGl4 2TDkwuXUOeXtLQPXuEfdQ== Received: from pxi37 (pxi37.prod.google.com [10.243.27.37]) by spaceape7.eur.corp.google.com with ESMTP id nAPJtqI3032607 for ; Wed, 25 Nov 2009 11:55:59 -0800 Received: by pxi37 with SMTP id 37so30192pxi.20 for ; Wed, 25 Nov 2009 11:55:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.8.8 with SMTP id 8mr938959wfh.64.1259178957393; Wed, 25 Nov 2009 11:55:57 -0800 (PST) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0688169A@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0688169A@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 25 Nov 2009 11:55:57 -0800 Message-ID: From: Jerry Chu To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] working group status 11/17/09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:56:11 -0000 Hi Richard, On Wed, Nov 25, 2009 at 6:36 AM, Scheffenegger, Richard wro= te: > > Hi Jerry, > > Have you though about the implications of increasing initcwnd to a > level, which exceeds the buffering capacity of your L2 devices? > I have observed hosts, which can repeatedly cause heavy packet loss > due to droptail in a L2 switch, even with a burst size of as little > as 4-6 frames... These hosts are simply capable of wirespeed sending, > while the L2 switch is not (or, a common downstream link is slightly > saturated). Yes, we suspect the limited edge routers/access-links/wireless-gateways buffer space, rather than congestion collapse to be the main risk a larger initcwnd may introduce because the former causes pkts to be dropped hence negatively impacting performance whereas congestion avoidance remains intact making the latter unlikely to happen, Unfortunately we have not been able to confirm this due to the limitation of our passive measurements as I mentioned earlier. What will be interesting to know is the distribution of the above mentioned buffer sizes in today's Internet. This will help in answering questions lik= e what's the percentage of users that might be affected negatively. If the percentage is not negligible, how much impact (e.g., just one lost event at the beginning of a TCP connection?), is there any way to mitigate the impact,..., etc. Ultimately we may have to face the choice - does it make sense to slow down the vast majority of the Internet users just to avoid any negative imp= act to a small percentage of users? > > L2 boxes don't seem to feature that much buffering (ie. 40 frames), > thus will enhance the negative effects of any packet burst. (When the > L2 buffers are full, and a new session bursts 15+ frames all at once > into the L2 box.). > > IMHO, some basic pacing should be made mandatory when cwnd is mostly > empty, to break bursts and deal with slower-than-wirespeed L2 devices > in the path... Yes pacing is one solution to avoid the burst and is required by all the jump/quick/swift/fast start proposals. Personally I'd prefer to avoid makin= g it a requirement for initcwnd of 10 in order to keep the change simple. The hope is we don't need to go that far unless initcwnd is changed to a much larger size (e.g., > 16). Jerry > > (Tweaking the IFG, or doing some multiplexing with other streams > right at the sender side, might work - but this requires a lower layer > entity to perform that, not TCP all by itself... You might even argue, > that this is an implementation specific tweak, rather than a TCP > algrithm all along. > > Just my 0.02 EUR. > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > NetApp > +43 1 3676811 3146 Office (2143 3146 - internal) > +43 676 654 3146 Mobile > www.netapp.com > Franz-Klein-Gasse 5 > 1190 Wien > > > >> -----Original Message----- >> From: Jerry Chu [mailto:hkchu@google.com] >> Sent: Mittwoch, 25. November 2009 03:25 >> To: Joe Touch >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] working group status 11/17/09 >> >> Hi Joe, >> >> On Tue, Nov 24, 2009 at 9:43 AM, Joe Touch wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Hi, Jerry, >> > >> > Jerry Chu wrote: >> > ... >> >> Separately I'd like to propose a moderate increase of the initcwnd >> >> from what is specified in RFC3390 to ~15KB, or 10 segments for >> >> IP/Ethernet. >> > >> > The jump from 1 segment to 4KB took quite a bit of analysis, even >> > though the basis of the change had been widely deployed as >> an implementation bug. >> > >> > I suspect it would take similar analysis to ensure that >> this would be >> > safe today, including the effect on home gateways, PDAs, etc. >> >> Understood. (Actually I was involved in the effort to up >> initcwnd from 1 to 2 in the late 90' when Solaris' SPECWEB >> numbers blew up on our face due to the extended delay between >> Windows clients' delayed acks and Solaris servers' initcwnd of 1.) >> >> My hope this time is that, rather than relying extensively on >> simulations, we can leverage Google's vast network reach and >> determination to "make the web faster" (see >> http://code.google.com/speed/) =A0to collect data from real >> experiments to better understand and devise ways to mitigate >> the negative impact, if any, from increasing initcwnd. >> >> > >> > You are also possibly talking about 30 segments, until path MTU >> > discovery kicks in. So you're going from 4K or 4 segments >> (whichever >> > is >> > smaller) to 15K or ?? segments (10? 30?). >> >> We can work out the exact formula and put a cap on # of >> segments (e.g., 10). >> We would prefer to go higher than 10 but at this moment we >> still don't fully understand the negative impact (although >> small) to warrant the risk. >> OTOH we felt 6 or lower is too small to worth the effort. 10 >> may be a good balance between benefit vs risk. >> >> > >> > Granted this may already be the common case for persistent >> connections >> > going active after draining the data, but it's not clear that such >> > behavior dominates Internet traffic to a point that the current >> > operational evidence can be used to validate that this is safe. >> >> I think a greater problem is web browser's increasing use of >> more concurrent connections (I heard IE8 just up the # of >> concurrent connections per domain from 2 to 6), partly to >> circumvent the small initcwnd each TCP connection gets. To me >> this alleviates to some extent my own concern of a larger >> initcwnd. But it also speaks to the failure of this community >> to address the issue (or at least the perception that >> initcwnd is too small) sooner to prevent this bad practice >> from the browser vendors. >> >> Jerry >> >> > >> > Joe >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.9 (MingW32) >> > >> > iEYEARECAAYFAksMG0oACgkQE5f5cImnZrv7VwCfWgK4n0yOxFoIwbsBfmKx9pZU >> > 9IgAn3wH6mX26Jn6EPjaUz1J838wT8aw >> > =3DHnjU >> > -----END PGP SIGNATURE----- >> > >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > From root@core3.amsl.com Thu Nov 26 12:30:01 2009 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8EA2F3A6914; Thu, 26 Nov 2009 12:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091126203001.8EA2F3A6914@core3.amsl.com> Date: Thu, 26 Nov 2009 12:30:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-02.txt Pages : 13 Date : 2009-11-26 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-urgent-data-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-26121842.I-D@ietf.org> --NextPart--