From tcpm-bounces@ietf.org Sat Aug 05 09:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9M1A-0000GD-Ie; Sat, 05 Aug 2006 09:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9M18-0000G8-Nl for tcpm@ietf.org; Sat, 05 Aug 2006 09:16:38 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9M16-0006LY-SI for tcpm@ietf.org; Sat, 05 Aug 2006 09:16:38 -0400 Received: from fgont.gont.com.ar ([200.70.144.3]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k75DGB3t028287; Sat, 5 Aug 2006 10:16:19 -0300 Message-Id: <7.0.1.0.0.20060805053717.0587e900@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 05 Aug 2006 08:33:15 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Mark Allman Subject: [tcpm] Some feedback on draft-ietf-tcpm-rfc2581bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark, A couple of comments on draft-ietf-tcpm-ietf-rfc2581bis-01. Page 8. The draft says: " 6. When the next ACK arrives that acknowledges new data, a TCP MUST set cwnd to ssthresh (the value set in step 1). This is termed "deflating" the window. This ACK should be the acknowledgment elicited by the retransmission from step 1, one RTT after the retransmission (though it may arrive sooner in the presence of significant out- of-order delivery of data segments at the receiver). " Can the ACK really arrive sooner than one RTT? Unless the RTT for the connection decreases, I cannot see why this would happen. The draft goes on with: " Additionally, this ACK should acknowledge all the intermediate segments sent between the lost segment and the receipt of the third duplicate ACK, if none of these were lost." What if it doesn't? Should we stay in loss-recovery until this happens, or should we end loss recovery, anyway? (The former, right?) Just my 2 cents, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Aug 05 11:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9NpN-0004EU-4x; Sat, 05 Aug 2006 11:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9NpL-0004E9-9h for tcpm@ietf.org; Sat, 05 Aug 2006 11:12:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9MjZ-0003Fc-3q for tcpm@ietf.org; Sat, 05 Aug 2006 10:02:33 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9MaF-0001g9-Qo for tcpm@ietf.org; Sat, 05 Aug 2006 09:52:57 -0400 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k75DqUJa072538; Sat, 5 Aug 2006 06:52:30 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 261D177A9D4; Sat, 5 Aug 2006 09:52:29 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E2A8C447AFA; Sat, 5 Aug 2006 09:51:12 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <7.0.1.0.0.20060805053717.0587e900@gont.com.ar> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Zombie MIME-Version: 1.0 Date: Sat, 05 Aug 2006 09:51:12 -0400 Message-Id: <20060805135112.E2A8C447AFA@lawyers.icir.org> X-Spam-Score: -2.4 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org Subject: [tcpm] Re: Some feedback on draft-ietf-tcpm-rfc2581bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1130632454==" Errors-To: tcpm-bounces@ietf.org --===============1130632454== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Page 8. The draft says: > " 6. When the next ACK arrives that acknowledges new data, a TCP > MUST set cwnd to ssthresh (the value set in step 1). This is > termed "deflating" the window. > > This ACK should be the acknowledgment elicited by the > retransmission from step 1, one RTT after the retransmission > (though it may arrive sooner in the presence of significant out- > of-order delivery of data segments at the > receiver). " > > Can the ACK really arrive sooner than one RTT? Unless the RTT for > the connection decreases, I cannot see why this would happen. As noted, out-of-order delivery can make this happen ... i.e., the ACK *should* be trigged by the retransmission. But, if there was just reordering and no loss then it might not be. So, the ACK covering the retransmit could be triggered by the original transmission (and, so could arrive earlier than one RTT after the rexmt was sent). > The draft goes on with: > > " Additionally, this ACK should acknowledge all the > intermediate segments sent between the lost segment and the > receipt of the third duplicate ACK, if none of these were lost." > > What if it doesn't? Should we stay in loss-recovery until this > happens, or should we end loss recovery, anyway? (The former, right?) Loss recovery ends with the receipt of the first new ACK as the document says. Right after the above quoted text is this: Note: This algorithm is known to generally not recover efficiently from multiple losses in a single flight of packets [FF96]. Section 4.3 below addresses such cases. RFC 2581 does not try to specify NewReno or SACK-based loss recovery schemes - even though it recommends implementing such schemes (which are specified elsewhere). allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFE1KJQWyrrWs4yIs4RAjBhAJ4j1lViZNo1TuP4AcFl7KFVKsm99wCgh642 S73BcNGxVhF4m11f7LCpqxM= =OF9A -----END PGP SIGNATURE----- --=_bOundary-- --===============1130632454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1130632454==-- From tcpm-bounces@ietf.org Mon Aug 07 17:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACdv-0001yR-2u; Mon, 07 Aug 2006 17:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GACdu-0001xw-HR for tcpm@ietf.org; Mon, 07 Aug 2006 17:28:10 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GACdt-0002Py-5J for tcpm@ietf.org; Mon, 07 Aug 2006 17:28:10 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k77LRBN17815 for ; Mon, 7 Aug 2006 14:27:11 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k77LRBdx014210 for tcpm@ietf.org; Mon, 7 Aug 2006 14:27:11 -0700 (PDT) (envelope-from faber) Date: Mon, 7 Aug 2006 14:27:11 -0700 From: Ted Faber To: tcpm@ietf.org Message-ID: <20060807212603.GB13923@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [tcpm] TCP minutes for approval (review before 11 Aug - this Friday) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060150970==" Errors-To: tcpm-bounces@ietf.org --===============1060150970== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vEao7xgI/oilGqZ+" Content-Disposition: inline --vEao7xgI/oilGqZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The draft TCPM minutes from ietf 66 are up at=20 http://www3.ietf.org/proceedings/06jul/minutes/tcpm.txt Please have a look and make sure that things you said are properly reported. The deadline fo rthis is Friday 11 Aug 2006. These are largely from Pasi Sarolahti's phenomenal notes. Anything that's messed up is probably from my editing pass. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --vEao7xgI/oilGqZ+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE17AvaUz3f+Zf+XsRAo/iAKCoDudyC3yxTjX9lsadus5wqsgRogCgjN12 MemPCiJ4I6A2tBl16xUtrbs= =xvBQ -----END PGP SIGNATURE----- --vEao7xgI/oilGqZ+-- --===============1060150970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1060150970==-- From tcpm-bounces@ietf.org Tue Aug 08 08:54:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAR6Q-0004jd-N0; Tue, 08 Aug 2006 08:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAR6P-0004jV-TP for tcpm@ietf.org; Tue, 08 Aug 2006 08:54:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAPam-0006B8-Gf for tcpm@ietf.org; Tue, 08 Aug 2006 07:17:48 -0400 Received: from venus.xmundo.net ([201.216.232.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAPXf-0003MX-Nk for tcpm@ietf.org; Tue, 08 Aug 2006 07:14:37 -0400 Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k78BE2cP018973; Tue, 8 Aug 2006 08:14:09 -0300 Message-Id: <7.0.1.0.0.20060808074646.06753fd8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 08 Aug 2006 07:56:58 -0300 To: mallman@icir.org From: Fernando Gont Subject: Re: [tcpm] Re: Some feedback on draft-ietf-tcpm-rfc2581bis-01.txt In-Reply-To: <20060805135112.E2A8C447AFA@lawyers.icir.org> References: <7.0.1.0.0.20060805053717.0587e900@gont.com.ar> <20060805135112.E2A8C447AFA@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.3 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 10:51 05/08/2006, Mark Allman wrote: > > Page 8. The draft says: > > " 6. When the next ACK arrives that acknowledges new data, a TCP > > MUST set cwnd to ssthresh (the value set in step 1). This is > > termed "deflating" the window. > > > > This ACK should be the acknowledgment elicited by the > > retransmission from step 1, one RTT after the retransmission > > (though it may arrive sooner in the presence of significant out- > > of-order delivery of data segments at the > > receiver). " > > > > Can the ACK really arrive sooner than one RTT? Unless the RTT for > > the connection decreases, I cannot see why this would happen. > >As noted, out-of-order delivery can make this happen ... i.e., the ACK >*should* be trigged by the retransmission. But, if there was just >reordering and no loss then it might not be. So, the ACK covering the >retransmit could be triggered by the original transmission (and, so >could arrive earlier than one RTT after the rexmt was sent). This makes perfect sense, of course. However, it wasn't clear to me from the draft. I'd probably change the corresponding paragraph to: "This ACK should be the acknowledgement elicited by the retransmission from step 1, one RTT after the retransmission (though it may arrive sooner in case Fast Retransmit has been triggered by network packet reordering, rather than by a loss event)" Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 08 11:29:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATWE-00025d-Gm; Tue, 08 Aug 2006 11:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATWC-00023s-F1 for tcpm@ietf.org; Tue, 08 Aug 2006 11:29:20 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATW9-00006O-2e for tcpm@ietf.org; Tue, 08 Aug 2006 11:29:20 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k78FSpN29058 for ; Tue, 8 Aug 2006 08:28:51 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k78FSo5d041134 for tcpm@ietf.org; Tue, 8 Aug 2006 08:28:50 -0700 (PDT) (envelope-from faber) Date: Tue, 8 Aug 2006 08:28:50 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] TCP minutes for approval (review before 11 Aug - this Friday) Message-ID: <20060808152850.GC40666@hut.isi.edu> References: <20060807212603.GB13923@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060807212603.GB13923@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648978186==" Errors-To: tcpm-bounces@ietf.org --===============0648978186== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctP54qlpMx3WjD+/" Content-Disposition: inline --ctP54qlpMx3WjD+/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 07, 2006 at 02:27:11PM -0700, Ted Faber wrote: > The draft TCPM minutes from ietf 66 are up at=20 > http://www3.ietf.org/proceedings/06jul/minutes/tcpm.txt >=20 > Please have a look and make sure that things you said are properly > reported. The deadline fo rthis is Friday 11 Aug 2006. >=20 > These are largely from Pasi Sarolahti's phenomenal notes. Anything that's > messed up is probably from my editing pass. I've added text to the status and anti-spoof discussion sections describing teh plan to take that through a second 2-week WGLC on the editing discussions that were raised in teh first WGLC. If that doesn't jibe with your recollections, please speak up. New minutes are at the URL above. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --ctP54qlpMx3WjD+/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE2K2yaUz3f+Zf+XsRAsn3AJ4wMcwN1OUaZrVtbm94hqsgwxIWsACg7MHR gnGjLrZm44bHg+ad27yjRGY= =0Yg0 -----END PGP SIGNATURE----- --ctP54qlpMx3WjD+/-- --===============0648978186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0648978186==-- From tcpm-bounces@ietf.org Tue Aug 08 15:50:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXaY-0002Y8-9u; Tue, 08 Aug 2006 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXaU-0002XD-BJ; Tue, 08 Aug 2006 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXaU-0001v9-29; Tue, 08 Aug 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0A0583288B; Tue, 8 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAXaT-0005dU-SV; Tue, 08 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-01.txt Pages : 14 Date : 2006-8-8 This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, this document describes a modification to TCP's reaction to soft errors that has been implemented in a variety of TCP/IP stacks to help overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-soft-errors-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-8124253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-8124253.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Aug 08 15:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXam-00038S-UJ; Tue, 08 Aug 2006 15:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAXaV-0002Xi-8w; Tue, 08 Aug 2006 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAXaU-0001v8-0t; Tue, 08 Aug 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0091F3288A; Tue, 8 Aug 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAXaT-0005dR-Ro; Tue, 08 Aug 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Aug 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP's Reaction to Soft Errors Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-soft-errors-01.txt Pages : 14 Date : 2006-8-8 This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, this document describes a modification to TCP's reaction to soft errors that has been implemented in a variety of TCP/IP stacks to help overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-soft-errors-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-8124243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-8124243.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Aug 08 21:14:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAce3-0003ck-Vk; Tue, 08 Aug 2006 21:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAce1-0003cB-1w; Tue, 08 Aug 2006 21:14:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAaFa-0007v9-CI; Tue, 08 Aug 2006 18:40:38 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GAa5o-0006RA-Hp; Tue, 08 Aug 2006 18:30:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 66B052AC6E; Tue, 8 Aug 2006 22:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GAa5K-0006P7-5D; Tue, 08 Aug 2006 18:30:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 08 Aug 2006 18:30:02 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: tcpm@ietf.org, Ted Faber , Mark Allman Subject: [tcpm] WG Action: RECHARTER: TCP Maintenance and Minor Extensions (tcpm) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The charter of the TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ TCP Maintenance and Minor Extensions (tcpm) ============================================ Current Status: Active Working Group Chair(s): Ted Faber Mark Allman Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/index.html Description of Working Group: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A document specifying a way to share the local "User TimeOut" value with the peer such that TCP connections can withstand long periods of disconnection. * The WG is coming to grips with how to deal with spoofed segments that can tear down connections, cause data corruption or performance problems. To this end the WG is generating an overview document as well as a scheme that mitigates some of the issues brought on by spoofed TCP segments using a challenge-response scheme to reduce the probabilities of a connection being impacted. Finally, the WG will produce a document outlining the potential impact of using ICMP messages to attack TCP streams. * The WG is writing an informational document about the ways in which TCPs can handle ICMP "soft errors". * The WG is updating the specification for Explicit Congestion Notification to allow for the use of ECN during part of TCP's three-way handshake to aid performance for short transfers. * The WG is writing an informational document that discusses commonly used, but not documented ways to combat SYN flooding attacks. * The WG is updating RFC 2581 to fix some minor specification problems and move it along the standards track. Goals and Milestones: Done Submit FRTO draft to IESG for publication as an Experimental RFC Done Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC Done Submit NCR Reordering Mitigation draft to the IESG for publication as an Experimental RFC Sep 06 Submit overview of spoofing attacks against TCP to IESG for publication as an Informational RFC. Oct 06 Submit revision of RFC 2581 to the IESG for publication as a Draft Standard. Oct 06 Submit In-Window Attack draft to IESG for publication as a Proposed Standard RFC. Nov 06 Submit User TimeOut option document to the IESG for publication as a Proposed Standard RFC. Nov 06 Submit ECN-SYN document to the IESG for publication as a Proposed Standard RFC. Jan 07 Submit soft errors document to the IESG for publication as an Informational RFC. Jan 07 Submit ICMP attack document to the IESG for publication as an Informational RFC. Jan 07 Submit SYN flooding document to the IESG for publication as an Informational RFC. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Aug 10 12:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBDjf-0004Wd-B0; Thu, 10 Aug 2006 12:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBDje-0004WT-AY for tcpm@ietf.org; Thu, 10 Aug 2006 12:50:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBDjb-0002uK-Ut for tcpm@ietf.org; Thu, 10 Aug 2006 12:50:18 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k7AGo2e20936 for ; Thu, 10 Aug 2006 09:50:02 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.7/8.13.7/Submit) id k7AGo2qk004150 for tcpm@ietf.org; Thu, 10 Aug 2006 09:50:02 -0700 (PDT) (envelope-from faber) Date: Thu, 10 Aug 2006 09:50:01 -0700 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] TCP minutes for approval (review before 11 Aug - this Friday) Message-ID: <20060810165001.GC2670@hut.isi.edu> References: <20060807212603.GB13923@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060807212603.GB13923@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1077875896==" Errors-To: tcpm-bounces@ietf.org --===============1077875896== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UFHRwCdBEJvubb2X" Content-Disposition: inline --UFHRwCdBEJvubb2X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 07, 2006 at 02:27:11PM -0700, Ted Faber wrote: > The draft TCPM minutes from ietf 66 are up at=20 > http://www3.ietf.org/proceedings/06jul/minutes/tcpm.txt >=20 > Please have a look and make sure that things you said are properly > reported. The deadline for this is Friday 11 Aug 2006. >=20 > These are largely from Pasi Sarolahti's phenomenal notes. Anything that's > messed up is probably from my editing pass. As a reminder: these are final tomorrow 11 Aug. If you need to check them, do so. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --UFHRwCdBEJvubb2X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE22O5aUz3f+Zf+XsRAv+VAKCyPhb2PZxYJGIeUKOx7Q8zLnlraACfaSxc NnzLM4S3FIAb+RDBLc2AbsA= =qc4L -----END PGP SIGNATURE----- --UFHRwCdBEJvubb2X-- --===============1077875896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1077875896==-- From tcpm-bounces@ietf.org Fri Aug 25 20:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGldS-0004CG-D2; Fri, 25 Aug 2006 20:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGldR-0004BG-17 for tcpm@ietf.org; Fri, 25 Aug 2006 20:02:49 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlaw-0002vT-TL for tcpm@ietf.org; Fri, 25 Aug 2006 20:00:17 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 25 Aug 2006 17:00:14 -0700 X-IronPort-AV: i="4.08,170,1154934000"; d="vcf'?scan'208,217"; a="338266106:sNHT66461154" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7Q00EUP021536; Fri, 25 Aug 2006 17:00:14 -0700 Received: from [171.69.142.71] (dhcp-171-69-142-71.cisco.com [171.69.142.71]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7Q00D1E028742; Fri, 25 Aug 2006 17:00:13 -0700 (PDT) Message-ID: <44EF8F0D.7030803@cisco.com> Date: Fri, 25 Aug 2006 17:00:13 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mahdavi, Jamshid" Subject: Re: [tcpm] TCP zero window timeout? References: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> Content-Type: multipart/mixed; boundary="------------090600050709000903020704" DKIM-Signature: a=rsa-sha1; q=dns; l=6443; t=1156550414; x=1157414414; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:Mahesh=20Jethanandani=20 |Subject:Re=3A=20[tcpm]=20TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DRQcAyez2TCOgZUlmMmi1jXlyvq0=3D; b=ayF5iCbucG0E8Br38uN5RqeyTVm7D33Gehuaj1ScWCrOBkb44rH4FGlcyOytsxlyByJPG7Jv wehh9jGjCs8ahFKlFPthSWQ71Xnc0Bl3ebdaiu2dhszxtIrn8dYFXTxv; Authentication-Results: sj-dkim-2.cisco.com; header.From=mahesh@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------090600050709000903020704 Content-Type: multipart/alternative; boundary="------------000700090406000107070002" --------------000700090406000107070002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jamshid, Looking at draft-ietf-tcpm-tcp-uto it appears that the draft is specifically looking at the question of disconnection in the network. It also applies to retransmission timer. The situation I was referring to is a little different and applies to persist timer. In our situation the client stops reading data. These clients are machines out in the Internet and as such the server has no control over their behavior. So while there is unacknowledged data, it is not that the client is not acking any data. It is responding to the probe but that it continuously advertises a window of zero. There is currently to my knowledge no timeout for this state for the server. This can manifest itself as a DOS situation if there are several such connections where the server is forced to hold data. We are suggesting a solution that allows the server to get out of this situation by applying a upper bound on the duration of the persist state. Note, it is not the default behavior for TCP. The default behavior is still the same. The user/administrator has to explicitly turn it on for the server to close the connection and free the resources in case it is believed that it is under attack. Fernando Gont wrote: > At 13:24 21/07/2006, Mahdavi, Jamshid wrote: > >> What is the status of draft-eggert-tcpm-tcp-abort-timeout-option-01? It >> may be of some use in situations like this. I've recently seen another >> scenario where this would be useful, so I'd be interested in seeing that >> draft reposted... > > > It was merged with draft-gont-tcpm-tcp-auto-option into > draft-ietf-tcpm-tcp-uto. > > The latest revision is draft-ietf-tcpm-tcp-uto-03.txt, available at > the usual places (e.g., > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt). > > Feedback is more than welcome. ;-) > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------000700090406000107070002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamshid,

Looking at draft-ietf-tcpm-tcp-uto it appears that the draft is specifically looking at the question of disconnection in the network. It also applies to retransmission timer.

The situation I was referring to is a little different and applies to persist timer. In our situation the client stops reading data. These clients are machines out in the Internet and as such the server has no control over their behavior. So while there is unacknowledged data, it is not that the client is not acking any data. It is responding to the probe but that it continuously advertises a window of zero.  There is currently to my knowledge no timeout for this state for the server. This can manifest itself as a DOS situation if there are several such connections where the server is forced to hold data.

We are suggesting a solution that allows the server to get out of this situation by applying a upper bound on the duration of the persist state. Note, it is not the default behavior for TCP. The default behavior is still the same. The user/administrator has to explicitly turn it on for the server to close the connection and free the resources in case it is believed that it is under attack.

Fernando Gont wrote:
At 13:24 21/07/2006, Mahdavi, Jamshid wrote:

What is the status of draft-eggert-tcpm-tcp-abort-timeout-option-01?  It
may be of some use in situations like this.  I've recently seen another
scenario where this would be useful, so I'd be interested in seeing that
draft reposted...

It was merged with draft-gont-tcpm-tcp-auto-option into draft-ietf-tcpm-tcp-uto.

The latest revision is draft-ietf-tcpm-tcp-uto-03.txt, available at the usual places (e.g., http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt).

Feedback is more than welcome. ;-)

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm
--------------000700090406000107070002-- --------------090600050709000903020704 Content-Type: text/x-vcard; charset=utf-8; name="mahesh.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mahesh.vcf" begin:vcard fn:Mahesh Jethanandani n:Jethanandani;Mahesh org:Cisco Systems Inc.;ADBU adr:;;170 West Tasman Drive;San Jose;CA;95134;United States of America email;internet:mahesh@cisco.com tel;work:408 527-8230 tel;fax:408 527-0147 tel;pager:408 308-6353 tel;cell:408 761-9683 url:http://www.cisco.com version:2.1 end:vcard --------------090600050709000903020704 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------090600050709000903020704-- From tcpm-bounces@ietf.org Fri Aug 25 22:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGoEx-0000ii-7f; Fri, 25 Aug 2006 22:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGoEw-0000ia-6k for tcpm@ietf.org; Fri, 25 Aug 2006 22:49:42 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGoEu-0000hl-Q4 for tcpm@ietf.org; Fri, 25 Aug 2006 22:49:42 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.6/8.13.6) with ESMTP id k7Q2m8eQ022395; Fri, 25 Aug 2006 19:48:08 -0700 (PDT) Message-ID: <44EFB668.70904@isi.edu> Date: Fri, 25 Aug 2006 19:48:08 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] TCP zero window timeout? References: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> <44EF8F0D.7030803@cisco.com> In-Reply-To: <44EF8F0D.7030803@cisco.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0005461213==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0005461213== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62CA4A0CB5E114C583C9A86B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62CA4A0CB5E114C583C9A86B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wouldn't this just result in the DOS attacker ACKing one byte at a time to prolong the connection needlessly? I.e., what's the point of putting this behavior inside TCP, vs. having the server give up on a connection after what it considers a reasonable time? Joe Mahesh Jethanandani wrote: > Jamshid, >=20 > Looking at draft-ietf-tcpm-tcp-uto it appears that the draft is > specifically looking at the question of disconnection in the network. I= t > also applies to retransmission timer. >=20 > The situation I was referring to is a little different and applies to > persist timer. In our situation the client stops reading data. These > clients are machines out in the Internet and as such the server has no > control over their behavior. So while there is unacknowledged data, it > is not that the client is not acking any data. It is responding to the > probe but that it continuously advertises a window of zero. There is > currently to my knowledge no timeout for this state for the server. Thi= s > can manifest itself as a DOS situation if there are several such > connections where the server is forced to hold data. >=20 > We are suggesting a solution that allows the server to get out of this > situation by applying a upper bound on the duration of the persist > state. Note, it is not the default behavior for TCP. The default > behavior is still the same. The user/administrator has to explicitly > turn it on for the server to close the connection and free the resource= s > in case it is believed that it is under attack. >=20 > Fernando Gont wrote: >> At 13:24 21/07/2006, Mahdavi, Jamshid wrote: >> >>> What is the status of draft-eggert-tcpm-tcp-abort-timeout-option-01? = It >>> may be of some use in situations like this. I've recently seen anoth= er >>> scenario where this would be useful, so I'd be interested in seeing t= hat >>> draft reposted... >> >> It was merged with draft-gont-tcpm-tcp-auto-option into >> draft-ietf-tcpm-tcp-uto. >> >> The latest revision is draft-ietf-tcpm-tcp-uto-03.txt, available at >> the usual places (e.g., >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-03.txt). >> >> Feedback is more than welcome. ;-) >> >> Kindest regards, >> >> --=20 >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enig62CA4A0CB5E114C583C9A86B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE77ZoE5f5cImnZrsRAjoQAJ9QgBLjcsUDE8ICzPmSpWXVD5VoRgCg9gNb Xxlmb4UuwV3Yg/YOsLNQ0Jg= =8xSd -----END PGP SIGNATURE----- --------------enig62CA4A0CB5E114C583C9A86B-- --===============0005461213== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0005461213==-- From tcpm-bounces@ietf.org Sat Aug 26 07:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGwIB-0001ve-D8; Sat, 26 Aug 2006 07:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGwIA-0001vZ-Bh for tcpm@ietf.org; Sat, 26 Aug 2006 07:25:34 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGwI8-00087F-Gu for tcpm@ietf.org; Sat, 26 Aug 2006 07:25:34 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2D4CBF0C66D; Sat, 26 Aug 2006 08:25:42 -0300 (ART) Received: from fgont.gont.com.ar ([200.70.146.80]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k7QBOssi012924; Sat, 26 Aug 2006 08:25:12 -0300 Message-Id: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 26 Aug 2006 07:13:56 -0300 To: Mahesh Jethanandani , "Mahdavi, Jamshid" From: Fernando Gont Subject: Re: [tcpm] TCP zero window timeout? In-Reply-To: <44EF8F0D.7030803@cisco.com> References: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> <44EF8F0D.7030803@cisco.com> Mime-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0038452873==" Errors-To: tcpm-bounces@ietf.org --===============0038452873== Content-Type: multipart/alternative; boundary="=====================_897430747==.ALT" --=====================_897430747==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 21:00 25/08/2006, Mahesh Jethanandani wrote: >The situation I was referring to is a little different and applies >to persist timer. In our situation the client stops reading data. >These clients are machines out in the Internet and as such the >server has no control over their behavior. So while there is >unacknowledged data, it is not that the client is not acking any >data. It is responding to the probe but that it continuously >advertises a window of zero. There is currently to my knowledge no >timeout for this state for the server. This can manifest itself as a >DOS situation if there are several such connections where the server >is forced to hold data. I'd argue that this should be handled by an application-level timer. The problem with the scenario you point out is that there will always be one more way to do the same thing. If we're talking about connections wasting resources, there are many protocols (POP3, SMTP) in which after the initial greeting by the server, the client is supposed to go ahead. In all those cases, the client could just sit there. And only an application-layer timeout would help you. I'm not sure how many servers implement this type of application-layer timer. But there are some (Apache) that I have checked, and do. Nevertheless, I'm interested in the behaviour you described. Is it supposed to be malicious activity? Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 --=====================_897430747==.ALT Content-Type: text/html; charset="us-ascii" At 21:00 25/08/2006, Mahesh Jethanandani wrote:

The situation I was referring to is a little different and applies to persist timer. In our situation the client stops reading data. These clients are machines out in the Internet and as such the server has no control over their behavior. So while there is unacknowledged data, it is not that the client is not acking any data. It is responding to the probe but that it continuously advertises a window of zero.  There is currently to my knowledge no timeout for this state for the server. This can manifest itself as a DOS situation if there are several such connections where the server is forced to hold data.

I'd argue that this should be handled by an application-level timer.

The problem with the scenario you point out is that there will always be one more way to do the same thing.

If we're talking about connections wasting resources, there are many protocols (POP3, SMTP) in which after the initial greeting by the server, the client is supposed to go ahead. In all those cases, the client could just sit there. And only an application-layer timeout would help you.

I'm not sure how many servers implement this type of application-layer timer. But there are some (Apache) that I have checked, and do.

Nevertheless, I'm interested in the behaviour you described. Is it supposed to be malicious activity?

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--=====================_897430747==.ALT-- --===============0038452873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0038452873==-- From tcpm-bounces@ietf.org Sat Aug 26 19:06:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH7Dr-0004PU-Cl; Sat, 26 Aug 2006 19:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH7Dq-0004PP-3a for tcpm@ietf.org; Sat, 26 Aug 2006 19:05:50 -0400 Received: from web31713.mail.mud.yahoo.com ([68.142.201.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GH7Do-0007wO-MZ for tcpm@ietf.org; Sat, 26 Aug 2006 19:05:50 -0400 Received: (qmail 41462 invoked by uid 60001); 26 Aug 2006 23:05:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dOH4XiFPYfn6cu+TtEGiQTVSjnYjmeG6pr/I+xfI9u0sjFsMFrE9we0fh68EAPayGlIGmQXk0JiP3hDFl7buauR2j1WKnyFrxAHonYfmgtInthsHctWBIuBrtA5phTCKqW+RCGefShfnTCDZiR7r/XCYgwuOYY4OjE+v1XN3p4g= ; Message-ID: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> Received: from [24.6.24.35] by web31713.mail.mud.yahoo.com via HTTP; Sat, 26 Aug 2006 16:05:45 PDT Date: Sat, 26 Aug 2006 16:05:45 -0700 (PDT) From: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? To: Fernando Gont , Mahesh Jethanandani , "Mahdavi, Jamshid" In-Reply-To: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando I collaborated with mahesh on this, so let me try making the case for it a little better. The problem was found on a TCP proxy, which does not have any applicaton awareness. In fact application awareness is not a goal in that environment. Hence the TCP level solution. Having said that, i'd say this timeout is in the same spirit as the upper bound on the retransmit mechanism of TCP. TCP could indefinitely retransmit and have the application timeout too, correct? The problem is that TCP has a persist state which can potentially exist infinitely long and which lends itself to abuse by a malicious peer. Just based purely on this consideration, don't you think TCP should have a mechanism that reduces the impact of this problem by either limiting the number of probes (a la retransmit timeout) or the duration. And the application can turn it on per connection via a socket option and set a value which makes sense for that application, so there is per application per connection control anyway. Murali --- Fernando Gont wrote: > At 21:00 25/08/2006, Mahesh Jethanandani wrote: > > >The situation I was referring to is a little > different and applies > >to persist timer. In our situation the client stops > reading data. > >These clients are machines out in the Internet and > as such the > >server has no control over their behavior. So while > there is > >unacknowledged data, it is not that the client is > not acking any > >data. It is responding to the probe but that it > continuously > >advertises a window of zero. There is currently to > my knowledge no > >timeout for this state for the server. This can > manifest itself as a > >DOS situation if there are several such connections > where the server > >is forced to hold data. > > I'd argue that this should be handled by an > application-level timer. > > The problem with the scenario you point out is that > there will always > be one more way to do the same thing. > > If we're talking about connections wasting > resources, there are many > protocols (POP3, SMTP) in which after the initial > greeting by the > server, the client is supposed to go ahead. In all > those cases, the > client could just sit there. And only an > application-layer timeout > would help you. > > I'm not sure how many servers implement this type of > > application-layer timer. But there are some (Apache) > that I have > checked, and do. > > Nevertheless, I'm interested in the behaviour you > described. Is it > supposed to be malicious activity? > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE > A9EF D076 FFF1 > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Aug 26 20:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH8SO-0006n2-D4; Sat, 26 Aug 2006 20:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH8SM-0006mw-RT for tcpm@ietf.org; Sat, 26 Aug 2006 20:24:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GH8SM-0001RA-PI for tcpm@ietf.org; Sat, 26 Aug 2006 20:24:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GH8MK-0005jh-8s for tcpm@ietf.org; Sat, 26 Aug 2006 20:18:44 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Aug 2006 17:18:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7R0IbqU031217; Sat, 26 Aug 2006 17:18:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7R0Ia1E028274; Sat, 26 Aug 2006 17:18:36 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 17:18:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] TCP zero window timeout? Date: Sat, 26 Aug 2006 17:18:35 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58020CCDBF@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP zero window timeout? Thread-Index: AcbJZDieyU6dVRUuSH+uF8Wmu7DdwgACDxHA From: "Anantha Ramaiah \(ananth\)" To: "MURALI BASHYAM" , "Fernando Gont" , "Mahesh Jethanandani \(mahesh\)" , "Mahdavi, Jamshid" X-OriginalArrivalTime: 27 Aug 2006 00:18:36.0565 (UTC) FILETIME=[56C00C50:01C6C96E] DKIM-Signature: a=rsa-sha1; q=dns; l=4574; t=1156637917; x=1157501917; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:RE=3A=20[tcpm]=20TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DlGoMr65IuHNTOXy7TDhc9EFdLjY=3D; b=dlfQ440zIKgXDtomyKONl33wuIFGBmGrupDbgfa81qkKRGCzX00231FSSyUbXolbvvUFa5iJ Mul8BomZbTDwUA0kRWEwjS/fEa3Ci3m+BQ7rC+tCDrh4HgKcFom7SqlI; Authentication-Results: sj-dkim-1.cisco.com; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Just to second what Murali said : Having a timeout on the persist state in case of proxy devices is advantagous because : - prevents resource exhaustion from mis-behaving, malicious clients. - Buggy applications/TCP stacks, which doesn't read data and may also shrink the window to 0.=20 Of course the robustness priniciple does say "be liberal in what you accept and conservative in what you send" and this applies to window shrinking ie never shrink the window, but if the peer has shrunk the window to 0 suddenly and sits tight in that state for a long time, then is is a problem. Typically applications have control on this persist timeout value, but in case of situations which Mahesh points a TCP level timeout seems to make sense. The question becomes whether do you want a TCP level protection for this scenario or not? -Anantha > -----Original Message----- > From: MURALI BASHYAM [mailto:murali_bashyam@yahoo.com]=20 > Sent: Saturday, August 26, 2006 4:06 PM > To: Fernando Gont; Mahesh Jethanandani (mahesh); Mahdavi, Jamshid > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] TCP zero window timeout? >=20 >=20 > Fernando >=20 > I collaborated with mahesh on this, so let me try making the=20 > case for it a little better. >=20 > The problem was found on a TCP proxy, which does not have any=20 > applicaton awareness. In fact application awareness is not a=20 > goal in that environment. Hence the TCP level solution. >=20 > Having said that, i'd say this timeout is in the same spirit=20 > as the upper bound on the retransmit mechanism of TCP. TCP=20 > could indefinitely retransmit and have the application=20 > timeout too, correct? The problem is that TCP has a persist=20 > state which can potentially exist infinitely long and which=20 > lends itself to abuse by a malicious peer. Just based purely=20 > on this consideration, don't you think TCP should have a=20 > mechanism that reduces the impact of this problem by either=20 > limiting the number of probes (a la retransmit > timeout) or the duration. And the application can turn it on=20 > per connection via a socket option and set a value which=20 > makes sense for that application, so there is per application=20 > per connection control anyway. >=20 > Murali >=20 > --- Fernando Gont wrote: >=20 > > At 21:00 25/08/2006, Mahesh Jethanandani wrote: > >=20 > > >The situation I was referring to is a little > > different and applies > > >to persist timer. In our situation the client stops > > reading data.=20 > > >These clients are machines out in the Internet and > > as such the > > >server has no control over their behavior. So while > > there is > > >unacknowledged data, it is not that the client is > > not acking any > > >data. It is responding to the probe but that it > > continuously > > >advertises a window of zero. There is currently to > > my knowledge no > > >timeout for this state for the server. This can > > manifest itself as a > > >DOS situation if there are several such connections > > where the server > > >is forced to hold data. > >=20 > > I'd argue that this should be handled by an application-level timer. > >=20 > > The problem with the scenario you point out is that there=20 > will always=20 > > be one more way to do the same thing. > >=20 > > If we're talking about connections wasting resources, there=20 > are many=20 > > protocols (POP3, SMTP) in which after the initial greeting by the=20 > > server, the client is supposed to go ahead. In all those cases, the=20 > > client could just sit there. And only an application-layer timeout=20 > > would help you. > >=20 > > I'm not sure how many servers implement this type of > >=20 > > application-layer timer. But there are some (Apache) that I have=20 > > checked, and do. > >=20 > > Nevertheless, I'm interested in the behaviour you described. Is it=20 > > supposed to be malicious activity? > >=20 > > Kindest regards, > >=20 > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809=20 > > 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > >=20 > >=20 > >=20 > >=20 > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Aug 26 23:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHAsJ-00005J-5D; Sat, 26 Aug 2006 22:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHAsI-00005E-KV for tcpm@ietf.org; Sat, 26 Aug 2006 22:59:50 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHAsH-0004hw-9h for tcpm@ietf.org; Sat, 26 Aug 2006 22:59:50 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.6/8.13.6) with ESMTP id k7R2whJ1003993; Sat, 26 Aug 2006 19:58:43 -0700 (PDT) Message-ID: <44F10A63.90700@isi.edu> Date: Sat, 26 Aug 2006 19:58:43 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? References: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> In-Reply-To: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1685694265==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1685694265== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0726549813BE97F3D92B55E4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0726549813BE97F3D92B55E4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > Fernando >=20 > I collaborated with mahesh on this, so let me try > making the case for it a little better. >=20 > The problem was found on a TCP proxy, which does not > have any applicaton awareness. In fact application > awareness is not a goal in that environment. Hence the > TCP level solution. Application-aware proxies are one thing (and they would be able to adjust fine here). TCP proxies for splice-like, transport-only gateways are already known to break so many things it's not clear that considering that as a special case is a good argument for modifying TCP. It's a better argument not to use TCP that way. > Having said that, i'd say this timeout is in the same > spirit as the upper bound on the retransmit mechanism > of TCP. TCP could indefinitely retransmit and have the > application timeout too, correct? The problem is that > TCP has a persist state which can potentially exist > infinitely long and which lends itself to abuse by a > malicious peer.=20 TCP is not intended to be robust to security attacks. A peer that can establish a TCP connection is already presumed to be a non-attacker at the TCP level, IMO. JOe --------------enig0726549813BE97F3D92B55E4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE8QpjE5f5cImnZrsRAvEaAKCzhzMC5SA2x0LJY+f4eJmSiLckZQCeICaT RpOedSLV11PcCNqf8IrQd0Q= =tyfT -----END PGP SIGNATURE----- --------------enig0726549813BE97F3D92B55E4-- --===============1685694265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1685694265==-- From tcpm-bounces@ietf.org Mon Aug 28 03:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHb8B-0007na-AS; Mon, 28 Aug 2006 03:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHb8A-0007nQ-HB for tcpm@ietf.org; Mon, 28 Aug 2006 03:01:58 -0400 Received: from bgerelbas02.asiapac.hp.net ([15.219.201.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHb83-0000UQ-Ac for tcpm@ietf.org; Mon, 28 Aug 2006 03:01:58 -0400 Received: from bgeexg12.asiapacific.cpqcorp.net (bgeexg12.asiapacific.cpqcorp.net [16.150.33.62]) by bgerelbas02.asiapac.hp.net (Postfix) with ESMTP id 6159E33088; Mon, 28 Aug 2006 12:31:48 +0530 (IST) Received: from BGEEXC02.asiapacific.cpqcorp.net ([16.150.33.10]) by bgeexg12.asiapacific.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 12:31:47 +0530 Received: from knuth.india.hp.com ([15.76.101.71]) by BGEEXC02.asiapacific.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 12:31:47 +0530 Subject: Re: [tcpm] TCP zero window timeout? From: "Kuthonuzo Luruo (STSD)" To: MURALI BASHYAM In-Reply-To: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> References: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 28 Aug 2006 18:02:15 +0530 Message-Id: <1156768336.4600.3.camel@knuth.india.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2006 07:01:47.0602 (UTC) FILETIME=[D4251B20:01C6CA6F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Sat, 2006-08-26 at 16:05 -0700, MURALI BASHYAM wrote: > Fernando > > I collaborated with mahesh on this, so let me try > making the case for it a little better. > > The problem was found on a TCP proxy, which does not > have any applicaton awareness. In fact application > awareness is not a goal in that environment. Hence the > TCP level solution. > > Having said that, i'd say this timeout is in the same > spirit as the upper bound on the retransmit mechanism > of TCP. TCP could indefinitely retransmit and have the > application timeout too, correct? The problem is that > TCP has a persist state which can potentially exist > infinitely long and which lends itself to abuse by a > malicious peer. Just based purely on this > consideration, don't you think TCP should have a > mechanism that reduces the impact of this problem by > either limiting the number of probes (a la retransmit > timeout) or the duration. And the application can turn > it on per connection via a socket option and set a > value which makes sense for that application, so there > is per application per connection control anyway. Several OSes do include a socket option SO_SNDTIMEO, that can be set by an application to specify the amount of time a transmit function blocks when flow control prevents the transmission of data. -thonuzo > > Murali > > --- Fernando Gont wrote: > > > At 21:00 25/08/2006, Mahesh Jethanandani wrote: > > > > >The situation I was referring to is a little > > different and applies > > >to persist timer. In our situation the client stops > > reading data. > > >These clients are machines out in the Internet and > > as such the > > >server has no control over their behavior. So while > > there is > > >unacknowledged data, it is not that the client is > > not acking any > > >data. It is responding to the probe but that it > > continuously > > >advertises a window of zero. There is currently to > > my knowledge no > > >timeout for this state for the server. This can > > manifest itself as a > > >DOS situation if there are several such connections > > where the server > > >is forced to hold data. > > > > I'd argue that this should be handled by an > > application-level timer. > > > > The problem with the scenario you point out is that > > there will always > > be one more way to do the same thing. > > > > If we're talking about connections wasting > > resources, there are many > > protocols (POP3, SMTP) in which after the initial > > greeting by the > > server, the client is supposed to go ahead. In all > > those cases, the > > client could just sit there. And only an > > application-layer timeout > > would help you. > > > > I'm not sure how many servers implement this type of > > > > application-layer timer. But there are some (Apache) > > that I have > > checked, and do. > > > > Nevertheless, I'm interested in the behaviour you > > described. Is it > > supposed to be malicious activity? > > > > Kindest regards, > > > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont@acm.org > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE > > A9EF D076 FFF1 > > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 28 13:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlAr-0004Ci-C6; Mon, 28 Aug 2006 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlAq-0004Cd-KB for tcpm@ietf.org; Mon, 28 Aug 2006 13:45:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHlAp-0004L1-8z for tcpm@ietf.org; Mon, 28 Aug 2006 13:45:24 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7SHax4N008682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Aug 2006 10:37:00 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7SHax5H080019; Mon, 28 Aug 2006 10:36:59 -0700 (PDT) (envelope-from faber) Date: Mon, 28 Aug 2006 10:36:59 -0700 From: Ted Faber To: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? Message-ID: <20060828173654.GB1252@hut.isi.edu> References: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar> <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> Mime-Version: 1.0 In-Reply-To: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1673044384==" Errors-To: tcpm-bounces@ietf.org --===============1673044384== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 26, 2006 at 04:05:45PM -0700, MURALI BASHYAM wrote: >=20 > Fernando >=20 > I collaborated with mahesh on this, so let me try > making the case for it a little better. >=20 > The problem was found on a TCP proxy, which does not > have any applicaton awareness. In fact application > awareness is not a goal in that environment. Hence the > TCP level solution. (As just a participant) Why get TCP involved here? If a proxy is running out of memory and it has connections that are largely unused, it should close them. The proxy is at the exact right spot to keep track of the connections and their usage. It can tell which connections are wasting its resources and it knows what it considers bad behavior of a connection. When proxy resources get scarce, close the connections that are behaving the worst - have been holding the same proxy resources a long time, for example. None of that requires application-awareness or TCP's complicity. And even if it did, TCP enables many applications. To a first approximation, increasing TCP's complexity increases its fragility. Changes to TCP should benefit more than one application before they're standardized, IMHO. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE8ym2aUz3f+Zf+XsRAsBuAJoDl66y5OaJqfIUfuiMNzgcNPwojACglwl0 aASlj7EiHWeOHWYyn+0Ek1M= =0IyU -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- --===============1673044384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1673044384==-- From tcpm-bounces@ietf.org Mon Aug 28 17:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHonY-0003yM-4e; Mon, 28 Aug 2006 17:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHonW-0003xg-Fz for tcpm@ietf.org; Mon, 28 Aug 2006 17:37:34 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHonV-0002dC-2k for tcpm@ietf.org; Mon, 28 Aug 2006 17:37:34 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 832F0F0D23A; Mon, 28 Aug 2006 18:38:06 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k7SLbFex011925; Mon, 28 Aug 2006 18:37:22 -0300 Message-Id: <7.0.1.0.0.20060828174420.07977518@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 17:50:48 -0300 To: MURALI BASHYAM , Mahesh Jethanandani , "Mahdavi, Jamshid" From: Fernando Gont Subject: Re: [tcpm] TCP zero window timeout? In-Reply-To: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> References: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar> <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 20:05 26/08/2006, MURALI BASHYAM wrote: >Having said that, i'd say this timeout is in the same >spirit as the upper bound on the retransmit mechanism >of TCP. TCP could indefinitely retransmit and have the >application timeout too, correct? I disagree. In the case of the RTO, you don't have any hints of the TCP segments getting to the remote TCP endpoint. Hence, after some number of retransmission, you don;t have much else to do than to abort the connection. In the case of zero window, as far as TCP is concerned, there's nothing wrong with an endpoint advertising a zero window. And you do know that packets are getting to the remote TCP endpoint (that's why you are getting the advertisements, after all). >The problem is that >TCP has a persist state which can potentially exist >infinitely long and which lends itself to abuse by a >malicious peer. This is the same thing as saying that there should be an "idle connection timeout", because a connection can be opened, and no data needs to be transmitted on the connection for the connection to be kept open. That said, some upper limit on the number of window-probes might not hurt, but then you get into which value to use. If too small, you may kill legitimate users. If too long, it may be useless. And I doubt there really is something in between. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 28 19:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHq57-00044N-E3; Mon, 28 Aug 2006 18:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHq56-00044I-GM for tcpm@ietf.org; Mon, 28 Aug 2006 18:59:48 -0400 Received: from web31704.mail.mud.yahoo.com ([68.142.201.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHq54-0002Hv-4q for tcpm@ietf.org; Mon, 28 Aug 2006 18:59:48 -0400 Received: (qmail 74383 invoked by uid 60001); 28 Aug 2006 22:59:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x01qcYe2J7O+3+l8FI9q4zFgrCgJU9HR34ODLAlLTs5DenGWC9bXveg7tw5AQBpXYitbLoCsELllg3BFOvEuK/+GlKnpmSAX0C8f+PekvO98Uj/cSaRVCnFfa/k2L93BQFS8ZFcmnFphdSPd9O/8laqXtctmVRAPfsAIb1Dm1y0= ; Message-ID: <20060828225943.74381.qmail@web31704.mail.mud.yahoo.com> Received: from [24.6.24.35] by web31704.mail.mud.yahoo.com via HTTP; Mon, 28 Aug 2006 15:59:43 PDT Date: Mon, 28 Aug 2006 15:59:43 -0700 (PDT) From: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? To: Ted Faber In-Reply-To: <20060828173654.GB1252@hut.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Ted Faber wrote: > On Sat, Aug 26, 2006 at 04:05:45PM -0700, MURALI > BASHYAM wrote: > > > > Fernando > > > > I collaborated with mahesh on this, so let me try > > making the case for it a little better. > > > > The problem was found on a TCP proxy, which does > not > > have any applicaton awareness. In fact application > > awareness is not a goal in that environment. Hence > the > > TCP level solution. > > (As just a participant) > > Why get TCP involved here? Because TCP's requirement to persist indefinitely creates the problem and only TCP is aware of how long the peer has been doing zero window offering. > > If a proxy is running out of memory and it has > connections that are > largely unused, it should close them. The proxy is > at the exact right > spot to keep track of the connections and their > usage. It can tell > which connections are wasting its resources and it > knows what it > considers bad behavior of a connection. When proxy > resources get > scarce, close the connections that are behaving the > worst - have been > holding the same proxy resources a long time, for > example. > This does not take into account the fact that connections are persisting and probing for peer's zero window which is fundamental to the discussion. > None of that requires application-awareness or TCP's > complicity. > > And even if it did, TCP enables many applications. > To a first > approximation, increasing TCP's complexity increases > its fragility. > Changes to TCP should benefit more than one > application before they're > standardized, IMHO. A TCP sender which is simply trying to probe the peer for an indefinitely long amount of time certainly stops helping the application or the system once beyond some amount of time threshold. The threshold may be different for different applications but for a given application and a system the threshold surely exists. Murali > > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 28 19:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqjn-0001a4-2f; Mon, 28 Aug 2006 19:41:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqjm-0001Zz-FI for tcpm@ietf.org; Mon, 28 Aug 2006 19:41:50 -0400 Received: from web31710.mail.mud.yahoo.com ([68.142.201.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHqjl-0001qn-3E for tcpm@ietf.org; Mon, 28 Aug 2006 19:41:50 -0400 Received: (qmail 13659 invoked by uid 60001); 28 Aug 2006 23:15:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=d1Ak//OaUtNTk99kQuWKXC1QtAnkj3Mt6rw+88rjXYDdeNSYf9TmJbg2YvtQqUVRCUkm30UelLWB2dx2vKOkunVSCYXoKJqRgXm8CioFVVGU0+0bdGidXLrXikWWjGDva2FtEWOMAv4bLJxQRZ2MaQtgDrUITS2pAhKBVCEIQJA= ; Message-ID: <20060828231508.13657.qmail@web31710.mail.mud.yahoo.com> Received: from [24.6.24.35] by web31710.mail.mud.yahoo.com via HTTP; Mon, 28 Aug 2006 16:15:07 PDT Date: Mon, 28 Aug 2006 16:15:07 -0700 (PDT) From: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? To: Fernando Gont , Mahesh Jethanandani , "Mahdavi, Jamshid" In-Reply-To: <7.0.1.0.0.20060828174420.07977518@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Fernando Today there is nothing that prevents a client side application from simply stopping to read the TCP receive socket buffer and causing the offered window to go down to 0, and thus causing the sender to hold a large send queue worth of data and probe forever. If this is done by a large number of clients against the same server, u have a distributed DOS attack on that server. We have seen this in practice. To answer an earlier question u had raised, the application cannot timeout on this connection because it does not know when the connection enters and leaves the persist state, only TCP knows that. The application can definitely decide the timeout value, but TCP needs to implement the timer because only it is aware of the state of the peer. More comments inline. --- Fernando Gont wrote: > At 20:05 26/08/2006, MURALI BASHYAM wrote: > > >Having said that, i'd say this timeout is in the > same > >spirit as the upper bound on the retransmit > mechanism > >of TCP. TCP could indefinitely retransmit and have > the > >application timeout too, correct? > > I disagree. In the case of the RTO, you don't have > any hints of the > TCP segments getting to the remote TCP endpoint. > Hence, after some > number of retransmission, you don;t have much else > to do than to > abort the connection. > I agree with you on that, but what i want to borrow from that timer is the aspect of limiting the amount of time trying to retransmit, which is what i meant. > In the case of zero window, as far as TCP is > concerned, there's > nothing wrong with an endpoint advertising a zero > window. And you do > know that packets are getting to the remote TCP > endpoint (that's why > you are getting the advertisements, after all). > And i am not disagreeing with you on that, let's differentiate the legitimate ones from the bad ones or minimize the impact of the bad ones. > > > >The problem is that > >TCP has a persist state which can potentially exist > >infinitely long and which lends itself to abuse by > a > >malicious peer. > > This is the same thing as saying that there should > be an "idle > connection timeout", because a connection can be > opened, and no data > needs to be transmitted on the connection for the > connection to be kept open. > An idle connection does not consume any buffer resources, whereeas here the connection is holding up precious buffer resources. > That said, some upper limit on the number of > window-probes might not > hurt, but then you get into which value to use. > If too small, you may kill legitimate users. If too > long, it may be useless. > I agree, but in the event of a DOS like scenario, this provides the administrator with a tool to control the impact of these bad clients on the system, and he can come up with a value which certainly does not impact legitimate probes. In these scenarios, any limit is better than infinite :-). Murali > And I doubt there really is something in between. > > Kindest regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE > A9EF D076 FFF1 > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 28 19:49:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqrY-0004Yv-PN; Mon, 28 Aug 2006 19:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqrX-0004Yp-AF for tcpm@ietf.org; Mon, 28 Aug 2006 19:49:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqrW-0003Nz-0T for tcpm@ietf.org; Mon, 28 Aug 2006 19:49:51 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 16:49:49 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SNnnkg005436; Mon, 28 Aug 2006 16:49:49 -0700 Received: from [10.34.37.171] ([10.34.37.171]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7SNnm1E016917; Mon, 28 Aug 2006 16:49:48 -0700 (PDT) Message-ID: <44F3811C.70209@cisco.com> Date: Mon, 28 Aug 2006 16:49:48 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fernando Gont Subject: Re: [tcpm] TCP zero window timeout? References: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar> <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> <7.0.1.0.0.20060828174420.07977518@gont.com.ar> In-Reply-To: <7.0.1.0.0.20060828174420.07977518@gont.com.ar> Content-Type: multipart/mixed; boundary="------------090104060508010207040709" DKIM-Signature: a=rsa-sha1; q=dns; l=2265; t=1156808989; x=1157672989; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:Mahesh=20Jethanandani=20 |Subject:Re=3A=20[tcpm]=20TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DqMMY8yA42yCrNp4dBnJrPBJCEUQ=3D; b=hVO+btT8Y2WJCY2FMm6T8f5V+RkfCqVUks8Y3tW8oS/I9qEjvVwR+a4lBZPovEExwC9NU5NB JCdmsxkaR5xCwRHMfv7Ig4rPNIPTAFDSj28SJDhD3UuspHSuklPHyo+W; Authentication-Results: sj-dkim-4.cisco.com; header.From=mahesh@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------090104060508010207040709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Fernando Gont wrote: > In the case of zero window, as far as TCP is concerned, there's > nothing wrong with an endpoint advertising a zero window. And you do > know that packets are getting to the remote TCP endpoint (that's why > you are getting the advertisements, after all). The problem with the client advertising a zero window is that it lends itself to a DOS attack. The problem is particularly bad if you are dealing with thousands of connections each of them chewing up connection blocks and TCP data buffers. That is what happened in the particular customer scenario. >> The problem is that >> TCP has a persist state which can potentially exist >> infinitely long and which lends itself to abuse by a >> malicious peer. > > > This is the same thing as saying that there should be an "idle > connection timeout", because a connection can be opened, and no data > needs to be transmitted on the connection for the connection to be > kept open. But you would agree that a large number of idle connections without a idle timeout is a problem for any TCP implementation. > > That said, some upper limit on the number of window-probes might not > hurt, but then you get into which value to use. > If too small, you may kill legitimate users. If too long, it may be > useless. If we agree that a limit is required on the number of probes then we can move to discussing how to implement that, what its default value should be and whether that value can be changed by the user etc. --------------090104060508010207040709 Content-Type: text/x-vcard; charset=utf-8; name="mahesh.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mahesh.vcf" begin:vcard fn:Mahesh Jethanandani n:Jethanandani;Mahesh org:Cisco Systems Inc.;ADBU adr:;;170 West Tasman Drive;San Jose;CA;95134;United States of America email;internet:mahesh@cisco.com tel;work:408 527-8230 tel;fax:408 527-0147 tel;pager:408 308-6353 tel;cell:408 761-9683 url:http://www.cisco.com version:2.1 end:vcard --------------090104060508010207040709 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------090104060508010207040709-- From tcpm-bounces@ietf.org Mon Aug 28 19:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqss-0005Ra-KA; Mon, 28 Aug 2006 19:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqsr-0005RV-Eh for tcpm@ietf.org; Mon, 28 Aug 2006 19:51:13 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqsp-0003ZG-3o for tcpm@ietf.org; Mon, 28 Aug 2006 19:51:13 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Mon, 28 Aug 2006 16:50:55 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1B4522AF; Mon, 28 Aug 2006 16:50:55 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id EAE602AE; Mon, 28 Aug 2006 16:50:54 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDX11882; Mon, 28 Aug 2006 16:50:50 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E510720501; Mon, 28 Aug 2006 16:50:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCP zero window timeout? Date: Mon, 28 Aug 2006 16:50:49 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F189ECE8@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20060828231508.13657.qmail@web31710.mail.mud.yahoo.com> Thread-Topic: [tcpm] TCP zero window timeout? Thread-Index: AcbK+6tuodG+zLWjQe+U2DjxW0aAiQAAQfnA From: "Caitlin Bestler" To: "MURALI BASHYAM" , "Fernando Gont" , "Mahesh Jethanandani" , "Mahdavi, Jamshid" X-TMWD-Spam-Summary: TS=20060828235056; SEV=2.0.2; DFV=A2006082813; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230312E34344633383032362E303031452D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006082813_4.00.0004_4.0-8 X-WSS-ID: 68ED5ED522G2759068-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org MURALI BASHYAM wrote: > Fernando >=20 > Today there is nothing that prevents a client side > application from simply stopping to read the TCP receive > socket buffer and causing the offered window to go down to 0, > and thus causing the sender to hold a large send queue worth > of data and probe forever. If this is done by a large number > of clients against the same server, u have a distributed DOS > attack on that server. We have seen this in practice. >=20 > To answer an earlier question u had raised, the application > cannot timeout on this connection because it does not know > when the connection enters and leaves the persist state, only > TCP knows that. The application can definitely decide the > timeout value, but TCP needs to implement the timer because > only it is aware of the state of the peer. >=20 True, but why does TCP need any wire protocol modifications to implement such a timeout locally? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 28 20:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrBm-0007O9-9k; Mon, 28 Aug 2006 20:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrBk-0007O4-W1 for tcpm@ietf.org; Mon, 28 Aug 2006 20:10:44 -0400 Received: from web31701.mail.mud.yahoo.com ([68.142.201.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHrBj-0006dv-N9 for tcpm@ietf.org; Mon, 28 Aug 2006 20:10:44 -0400 Received: (qmail 13217 invoked by uid 60001); 29 Aug 2006 00:04:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MZ22pe1Wlh5MJRSWf3mO+cKKM17DHs38J+mqB4tLzgqLNMw+uQubGjIdxbZvRYCEZBx60BU+zp5U2BYfsoCFxTvHTlRvNk6YoLmkRz5fx3htwlEaU5z/khU1BIo3O8/fpFXZAbadNMoFzagIaWwNt8z+5Xd61wUzLoOkfCWGqsw= ; Message-ID: <20060829000402.13215.qmail@web31701.mail.mud.yahoo.com> Received: from [24.6.24.35] by web31701.mail.mud.yahoo.com via HTTP; Mon, 28 Aug 2006 17:04:02 PDT Date: Mon, 28 Aug 2006 17:04:02 -0700 (PDT) From: MURALI BASHYAM Subject: RE: [tcpm] TCP zero window timeout? To: Caitlin Bestler , Fernando Gont , Mahesh Jethanandani , "Mahdavi, Jamshid" In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F189ECE8@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Caitlin Bestler wrote: > MURALI BASHYAM wrote: > > Fernando > > > > Today there is nothing that prevents a client side > > application from simply stopping to read the TCP > receive > > socket buffer and causing the offered window to go > down to 0, > > and thus causing the sender to hold a large send > queue worth > > of data and probe forever. If this is done by a > large number > > of clients against the same server, u have a > distributed DOS > > attack on that server. We have seen this in > practice. > > > > To answer an earlier question u had raised, the > application > > cannot timeout on this connection because it does > not know > > when the connection enters and leaves the persist > state, only > > TCP knows that. The application can definitely > decide the > > timeout value, but TCP needs to implement the > timer because > > only it is aware of the state of the peer. > > > > True, but why does TCP need any wire protocol > modifications to > implement such a timeout locally? It does not need any wire protocol modifications, but the intent of this discussion is whether it is worthwhile to document this at all and if so as a good practice or as an informational RFC so that implementers are aware of the issue and potential solutions and so on. Murali > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Aug 28 20:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrKX-0005Bk-9h; Mon, 28 Aug 2006 20:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrKV-0005BL-SO for tcpm@ietf.org; Mon, 28 Aug 2006 20:19:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpSt-00051D-Pc for tcpm@ietf.org; Mon, 28 Aug 2006 18:20:19 -0400 Received: from smtp1.xmundo.net ([201.216.232.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHonS-0002JP-UD for tcpm@ietf.org; Mon, 28 Aug 2006 17:37:32 -0400 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AECF3F0D237; Mon, 28 Aug 2006 18:38:02 -0300 (ART) Received: from fgont.gont.com.ar (171-180-231-201.fibertel.com.ar [201.231.180.171]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id k7SLbFev011925; Mon, 28 Aug 2006 18:37:19 -0300 Message-Id: <7.0.1.0.0.20060828174015.05ff6df8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 17:43:29 -0300 To: "Kuthonuzo Luruo (STSD)" , MURALI BASHYAM From: Fernando Gont Subject: Re: [tcpm] TCP zero window timeout? In-Reply-To: <1156768336.4600.3.camel@knuth.india.hp.com> References: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> <1156768336.4600.3.camel@knuth.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.9 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 09:32 28/08/2006, Kuthonuzo Luruo (STSD) wrote: >Several OSes do include a socket option SO_SNDTIMEO, that can be set by >an application to specify the amount of time a transmit function blocks >when flow control prevents the transmission of data. This is not exactly true. IIRC, SND_SNDTIMEO is a timeout on the relevant socket call (send(), write(), etc.), and not on actual data delivery to the remote TCP endpoint. As long as there's is enough free space in the socket send buffer, write()/send() won't block, and therefore the SO_SNDTIMEO timeout won;t apply. (Yes, if the TCP sender is sending bulk data, at some point the send buffer will most lilely fill up, and this timeout will kick in....) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 29 13:00:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI6vD-0004Ob-Kl; Tue, 29 Aug 2006 12:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI6vB-0004ON-OU for tcpm@ietf.org; Tue, 29 Aug 2006 12:58:41 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI6v9-0001qW-CQ for tcpm@ietf.org; Tue, 29 Aug 2006 12:58:41 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7TGvuY6024451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2006 09:57:56 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7TGvupq091256; Tue, 29 Aug 2006 09:57:56 -0700 (PDT) (envelope-from faber) Date: Tue, 29 Aug 2006 09:57:56 -0700 From: Ted Faber To: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? Message-ID: <20060829165756.GB89836@hut.isi.edu> References: <20060828173654.GB1252@hut.isi.edu> <20060828225943.74381.qmail@web31704.mail.mud.yahoo.com> Mime-Version: 1.0 In-Reply-To: <20060828225943.74381.qmail@web31704.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1224607630==" Errors-To: tcpm-bounces@ietf.org --===============1224607630== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 28, 2006 at 03:59:43PM -0700, MURALI BASHYAM wrote: >=20 >=20 > --- Ted Faber wrote: > > Why get TCP involved here? >=20 > Because TCP's requirement to persist indefinitely > creates the problem and only TCP is aware of how long > the peer has been doing zero window offering. TCP is completely unaware of how long a client has been offering a 0 receive window. You'd have to change it to keep count of that. That's what you're proposing, correct? =20 As an aside, RFC1122 says pretty unambiguously that both holding a zero window and probing it regularly are intentionally supported. > This does not take into account the fact that > connections are persisting and probing for peer's zero > window which is fundamental to the discussion. The resource your proxy is running out of is CPU to do window probes??? If so, that's very surprising. If not, can you tell me what your concern is? Looking at RFC1122 Section 4.2.2.17, it's hard to imagine a less CPU- intensive way to deal with window probing than the exponential backoff algorithm suggested there. > A TCP sender which is simply trying to probe the peer > for an indefinitely long amount of time certainly > stops helping the application or the system once > beyond some amount of time threshold. The threshold > may be different for different applications but for a > given application and a system the threshold surely > exists. =20 Without getting too philosophical, the designers of TCP did explicitly support connections that lock out transmission via a zero window size. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE9HITaUz3f+Zf+XsRAtdaAJ4uxxzpqexplmYM957kzrGLnUDivQCfecP5 2u1DQlORO9ygNAHUkChVYqw= =+rgc -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- --===============1224607630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1224607630==-- From tcpm-bounces@ietf.org Tue Aug 29 14:14:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI85T-00075C-P4; Tue, 29 Aug 2006 14:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI85S-000757-DZ for tcpm@ietf.org; Tue, 29 Aug 2006 14:13:22 -0400 Received: from web31715.mail.mud.yahoo.com ([68.142.201.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GI85Q-0003gK-1d for tcpm@ietf.org; Tue, 29 Aug 2006 14:13:22 -0400 Received: (qmail 50828 invoked by uid 60001); 29 Aug 2006 18:13:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NNzjzqN6N4vRX+sR/iiLDQIW6rYf3OjjY0ror7LFx1j3tVuuL+iyNSQQMalZ3zmvt9tZYDSSq2iKjJ0+QuaV07ItP/Mx+DcvDdPBHgRw2DSxCM+U1sNBvZSJOuorQkiwzv1cp9ZpmAw1Kf0HWForlLa04+u1F9/Nbttso/zHjg8= ; Message-ID: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> Received: from [24.6.24.35] by web31715.mail.mud.yahoo.com via HTTP; Tue, 29 Aug 2006 11:13:14 PDT Date: Tue, 29 Aug 2006 11:13:14 -0700 (PDT) From: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? To: Ted Faber In-Reply-To: <20060829165756.GB89836@hut.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Ted Faber wrote: > On Mon, Aug 28, 2006 at 03:59:43PM -0700, MURALI > BASHYAM wrote: > > > > > > --- Ted Faber wrote: > > > Why get TCP involved here? > > > > Because TCP's requirement to persist indefinitely > > creates the problem and only TCP is aware of how > long > > the peer has been doing zero window offering. > > TCP is completely unaware of how long a client has > been offering a 0 > receive window. You'd have to change it to keep > count of that. That's > what you're proposing, correct? Correct. > > As an aside, RFC1122 says pretty unambiguously that > both holding a zero > window and probing it regularly are intentionally > supported. It does, and i dont understand the rationale of probing *infinitely* as long as the client is acknowledging the probe with a zero window. It's possible that the authors did not have the potential of a DOS attack when they created this mechanism. In the scenario that i am talking abt these probes were sometimes running for hours together and such connections were ultimately starving out other legitimate users traffic. > > > This does not take into account the fact that > > connections are persisting and probing for peer's > zero > > window which is fundamental to the discussion. > > The resource your proxy is running out of is CPU to > do window probes??? > If so, that's very surprising. If not, can you tell > me what your > concern is? > The resources in question are connections and buffers. Here we are talking potentially huge numbers of them (100000 connections and even if each connection holds 1 buffer, that's a lot of buffer memory). A mechanism to reclaim these resources would have to take into account the duration of the persist state of the connections, it can't be done blindly. > Looking at RFC1122 Section 4.2.2.17, it's hard to > imagine a less CPU- > intensive way to deal with window probing than the > exponential backoff > algorithm suggested there. > > > A TCP sender which is simply trying to probe the > peer > > for an indefinitely long amount of time certainly > > stops helping the application or the system once > > beyond some amount of time threshold. The > threshold > > may be different for different applications but > for a > > given application and a system the threshold > surely > > exists. > > Without getting too philosophical, the designers of > TCP did explicitly > support connections that lock out transmission via a > zero window size. > I think the crux of the issue here is that this is left to the client side application control which means open game for hackers. Murali > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 29 14:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8Pr-0000wj-OJ; Tue, 29 Aug 2006 14:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8Pq-0000we-Ji for tcpm@ietf.org; Tue, 29 Aug 2006 14:34:26 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI8Pn-0000bD-Rm for tcpm@ietf.org; Tue, 29 Aug 2006 14:34:26 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Tue, 29 Aug 2006 11:34:09 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A4EE42AF; Tue, 29 Aug 2006 11:34:09 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 806B12AE; Tue, 29 Aug 2006 11:34:09 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDY57405; Tue, 29 Aug 2006 11:33:57 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E09C020501; Tue, 29 Aug 2006 11:33:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCP zero window timeout? Date: Tue, 29 Aug 2006 11:33:56 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F189EDC5@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> Thread-Topic: [tcpm] TCP zero window timeout? Thread-Index: AcbLlx1pmkkXC2DtTGaQ5ZYc3Z0XjgAAdXLQ From: "Caitlin Bestler" To: "MURALI BASHYAM" , "Ted Faber" X-TMWD-Spam-Summary: TS=20060829183411; SEV=2.0.2; DFV=A2006082906; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230332E34344634383736312E303033442D412D; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006082906_4.00.0004_4.0-8 X-WSS-ID: 68EA572B22G2957656-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org MURALI BASHYAM wrote: =20 >>=20 >=20 > I think the crux of the issue here is that this is left to > the client side application control which means open game for hackers. >=20 > Murali I think it is a given that a server application can terminate the connection to any client if the behaviour of that client means that the server no longer wishes to maintain the connection. I am not aware of any RFC that would impair the ability of the server application to interact with the local TCP stack to achieve these results. Is there a specific RFC requirement that you believe impairs creation of local interfaces to achieve the results you desire? In general, if the application layer has the right to do something it has the right to delegate that authority to a lower layer on the local stack and doing so will contradict the wire protocol. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 29 14:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8Wn-0004Fi-Mv; Tue, 29 Aug 2006 14:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8Wl-0004FR-RB for tcpm@ietf.org; Tue, 29 Aug 2006 14:41:35 -0400 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI8Wj-00026R-Hi for tcpm@ietf.org; Tue, 29 Aug 2006 14:41:35 -0400 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer2.psc.edu (8.13.5.20060308/8.13.3) with ESMTP id k7TIfOEV018883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 14:41:24 -0400 (EDT) Message-ID: <44F48A55.2030304@psc.edu> Date: Tue, 29 Aug 2006 14:41:25 -0400 From: John Heffner User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] TCP zero window timeout? References: <7.0.1.0.0.20060722170818.05a59eb8@gont.com.ar> <44EF8F0D.7030803@cisco.com> In-Reply-To: <44EF8F0D.7030803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I was looking at a similar problem a while ago as a result of a conversation with Stanislav Shalunov about his netkill (http://www.internet2.edu/~shalunov/netkill/) attack tool. The netkill problem is different than the zero window problem (and simpler for the attacker, requiring less state), but the end result is essentially the same: the sender is forced to maintain data in the send buffer for a large number of connections, running the server out of memory. Thinking about possible solutions, I didn't like the strictly TCP or strictly application solutions, for reasons already described on this list. My favored approach was to write a daemon that accesses TCP state through instrumentation, applies a policy if memory is running low, and kills connections as appropriate by using the deleteTCB(12) state defined in the TCP MIB. This does not require any additional protocol standardization. I wrote a simple proof-of-concept python script (below) that utilizes the Web100 implementation of the TCP ESTATS MIB. What it does essentially is if the system TCP send buffer memory is over some threshold value (100 MB), then it kills all connections that are over their fair share, and haven't made any forward progress in the last second. There's clearly room for improvement, like more complicated policy (protect or favor certain applications, etc.), but it does defend against netkill, and should work for the zero-window attack as well. -John import Web100 import time agent = Web100.Web100Agent() THRESH = 100 * 1024 *1024 omem = 0 conns = {} while True: cmem = 0 cl = agent.all_connections() for c in cl: state = c.read('State') try: old = conns[c.cid] if state == 1: del(conns[c.cid]) else: cur = c.readall() cmem = cmem + cur['CurAppWQueue'] if omem > THRESH and \ cur['SndUna'] == old['SndUna'] and \ cur['CurAppWQueue'] > THRESH / len(conns): print("Deleting connection %d."%c.cid) c.write('State', 12) conns[c.cid] = cur except: # New connection. Ignore if it's already closed. if state != 1: conns[c.cid] = c.readall() cmem = cmem + c.read('CurAppWQueue') omem = cmem time.sleep(1) _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 29 15:02:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8q1-0006Qq-PM; Tue, 29 Aug 2006 15:01:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8q0-0006Pj-AE for tcpm@ietf.org; Tue, 29 Aug 2006 15:01:28 -0400 Received: from web31701.mail.mud.yahoo.com ([68.142.201.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GI8py-0006aJ-0I for tcpm@ietf.org; Tue, 29 Aug 2006 15:01:28 -0400 Received: (qmail 88553 invoked by uid 60001); 29 Aug 2006 18:54:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rAw9GEaryZkZkaT2wc9kEgdrBmKEh374VwOwn+uSBiLr6myGG/vCkPSqYvp9LWD7LZ093gXTc+T1KaRiTOkhHTwswBRCkhEU0ufN3JSQjCKH+i/8coI6qdtqzZoclyt4p0t7eDsDGYN07/GJWY0fxRBS6p4AEQtUTw6joUYarb8= ; Message-ID: <20060829185444.88551.qmail@web31701.mail.mud.yahoo.com> Received: from [24.6.24.35] by web31701.mail.mud.yahoo.com via HTTP; Tue, 29 Aug 2006 11:54:44 PDT Date: Tue, 29 Aug 2006 11:54:44 -0700 (PDT) From: MURALI BASHYAM Subject: RE: [tcpm] TCP zero window timeout? To: Caitlin Bestler , Ted Faber In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F189EDC5@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --- Caitlin Bestler wrote: > MURALI BASHYAM wrote: > > >> > > > > I think the crux of the issue here is that this is > left to > > the client side application control which means > open game for hackers. > > > > Murali > > I think it is a given that a server application can > terminate > the connection to any client if the behaviour of > that client > means that the server no longer wishes to maintain > the connection. > The application is not aware of the client's behaviour here and as far as he is concerned the data is out of his control. > I am not aware of any RFC that would impair the > ability of > the server application to interact with the local > TCP stack > to achieve these results. Are u suggesting that the application query TCP to determine that the connection is stuck in persist state and how much of the data has been sent or not and so on? That sounds a little roundabout and complicated... > > Is there a specific RFC requirement that you believe > impairs > creation of local interfaces to achieve the results > you desire? > In general, if the application layer has the right > to do something > it has the right to delegate that authority to a > lower layer on > the local stack and doing so will contradict the > wire protocol. The application layer does not have enough information to take the corrective actions here. Murali > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 29 15:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9MA-0005bw-5b; Tue, 29 Aug 2006 15:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9M9-0005br-77 for tcpm@ietf.org; Tue, 29 Aug 2006 15:34:41 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9M7-0005m3-SB for tcpm@ietf.org; Tue, 29 Aug 2006 15:34:41 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 29 Aug 2006 12:34:21 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A82CF2B1; Tue, 29 Aug 2006 12:34:21 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 823522B0; Tue, 29 Aug 2006 12:34:21 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDY67060; Tue, 29 Aug 2006 12:34:17 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id ECA3020501; Tue, 29 Aug 2006 12:34:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] TCP zero window timeout? Date: Tue, 29 Aug 2006 12:34:15 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F189EDD1@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20060829185444.88551.qmail@web31701.mail.mud.yahoo.com> Thread-Topic: [tcpm] TCP zero window timeout? Thread-Index: AcbLnJuykJjkq5SsRoqQquxx/IorVAABNvzg From: "Caitlin Bestler" To: "MURALI BASHYAM" , "Ted Faber" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006082907; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230312E34344634393538302E303033362D412D; ENG=IBF; TS=20060829193426; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006082907_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68EA49373CC3019331-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org MURALI BASHYAM wrote: > --- Caitlin Bestler wrote: >=20 >> MURALI BASHYAM wrote: >>=20 >>>>=20 >>>=20 >>> I think the crux of the issue here is that this is left to >>> the client side application control which means open game for >>> hackers.=20 >>>=20 >>> Murali >>=20 >> I think it is a given that a server application can terminate the >> connection to any client if the behaviour of that client means that >> the server no longer wishes to maintain the connection. >>=20 >=20 > The application is not aware of the client's behaviour here > and as far as he is concerned the data is out of his control. >=20 >> I am not aware of any RFC that would impair the ability of the server >> application to interact with the local TCP stack to achieve these >> results. >=20 > Are u suggesting that the application query TCP to determine > that the connection is stuck in persist state and how much of > the data has been sent or not and so on? That sounds a little > roundabout and complicated... And/or the application convey an application specific tolerance for such a state through a local interface. If the behavior can be corrected through a local interface, and there is no IETF language barring or discouraging such an interface, then why is this something that TCPM should consider? At first glance, John Hefner's post would seem to show that the required information is already available. The nature of the Denial of Service attack presented does not seem to require real-time defenses and definitely does not present a strong case for any network element modifying their "fast path" handling of packets. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Aug 29 17:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB8s-00040F-1j; Tue, 29 Aug 2006 17:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB8q-000402-E4 for tcpm@ietf.org; Tue, 29 Aug 2006 17:29:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIB8n-0001i8-Rw for tcpm@ietf.org; Tue, 29 Aug 2006 17:29:04 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 29 Aug 2006 14:29:02 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7TLT1YB018683; Tue, 29 Aug 2006 14:29:01 -0700 Received: from [10.34.37.171] ([10.34.37.171]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7TLT01E008775; Tue, 29 Aug 2006 14:29:00 -0700 (PDT) Message-ID: <44F4B19C.5050001@cisco.com> Date: Tue, 29 Aug 2006 14:29:00 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] TCP zero window timeout? References: <54AD0F12E08D1541B826BE97C98F99F189EDD1@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F189EDD1@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: multipart/mixed; boundary="------------070203020001030101070202" DKIM-Signature: a=rsa-sha1; q=dns; l=4837; t=1156886941; x=1157750941; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:Mahesh=20Jethanandani=20 |Subject:Re=3A=20[tcpm]=20TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3D9Dr6uzpTon5iKrVxEhPCDHqT2s4=3D; b=atBUeduotxhKA5yfroPNRERRY5NAU/7T0DQEBEegimAM9w3DvpjbHzez8CeS8Lm2XNC3Z1EP 7BJNEnkUT/Tlh8VhV3y9mYC+DtvYdn0LGy6w1qF/dh9Ji7iqP42TZ6Gf; Authentication-Results: sj-dkim-2.cisco.com; header.From=mahesh@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: tcpm@ietf.org, Ted Faber , "Anantha Ramaiah \(ananth\)" , "Mahdavi, Jamshid" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --------------070203020001030101070202 Content-Type: multipart/alternative; boundary="------------010007070106070601080303" --------------010007070106070601080303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: >>Are u suggesting that the application query TCP to determine >>that the connection is stuck in persist state and how much of >>the data has been sent or not and so on? That sounds a little >>roundabout and complicated... >> >> > >And/or the application convey an application specific tolerance >for such a state through a local interface. > > We agree that application can help TCP by suggesting how tolerant it wants to be. >If the behavior can be corrected through a local interface, >and there is no IETF language barring or discouraging such >an interface, then why is this something that TCPM should >consider? > > Information of how long the connection has been stuck in persist state, how many retry probes have been made and whether each of them has resulted in a zero window is all in TCP. So TCP(m) has to be involved. Who actually issues the reset on the connection is a implementation level detail which we can get into once we agree that we have a DOS situation. >The nature of the Denial of Service attack presented does >not seem to require real-time defenses and definitely does >not present a strong case for any network element modifying >their "fast path" handling of packets. > If we accept that it is a DOS attack, then the problem needs to be addressed. Our suggestion only says that today's behavior of infinite TCP probes in persist state lends itself open to a DOS and so the probes should have the option to be capped with a timeout. --------------010007070106070601080303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Caitlin Bestler wrote:

Are u suggesting that the application query TCP to determine
that the connection is stuck in persist state and how much of
the data has been sent or not and so on? That sounds a little
roundabout and complicated...
    

And/or the application convey an application specific tolerance
for such a state through a local interface.
We agree that application can help TCP by suggesting how tolerant  it wants to be. 
If the behavior can be corrected through a local interface,
and there is no IETF language barring or discouraging such
an interface, then why is this something that TCPM should
consider?
Information of how long the connection has been stuck in persist state, how many retry probes have been made and whether each of them has resulted in a zero window is all in TCP. So TCP(m) has to be involved. Who actually issues the reset on the connection is a implementation level detail which we can get into once we agree that we have a DOS situation.
The nature of the Denial of Service attack presented does
not seem to require real-time defenses and definitely does
not present a strong case for any network element modifying
their "fast path" handling of packets.
If we accept that it is a DOS attack, then the problem needs to be addressed. Our suggestion only says that today's behavior of infinite TCP probes in persist state lends itself open to a DOS and so the probes should have the option to be capped with a timeout.
--------------010007070106070601080303-- --------------070203020001030101070202 Content-Type: text/x-vcard; charset=utf-8; name="mahesh.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mahesh.vcf" begin:vcard fn:Mahesh Jethanandani n:Jethanandani;Mahesh org:Cisco Systems Inc.;ADBU adr:;;170 West Tasman Drive;San Jose;CA;95134;United States of America email;internet:mahesh@cisco.com tel;work:408 527-8230 tel;fax:408 527-0147 tel;pager:408 308-6353 tel;cell:408 761-9683 url:http://www.cisco.com version:2.1 end:vcard --------------070203020001030101070202 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --------------070203020001030101070202-- From tcpm-bounces@ietf.org Tue Aug 29 19:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIDL9-0004zE-6C; Tue, 29 Aug 2006 19:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIDL8-0004z4-Ms for tcpm@ietf.org; Tue, 29 Aug 2006 19:49:54 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIDL5-0007CD-BW for tcpm@ietf.org; Tue, 29 Aug 2006 19:49:54 -0400 Received: from [128.9.176.224] (c2-vpn07.isi.edu [128.9.176.224]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k7TNn69s022397; Tue, 29 Aug 2006 16:49:06 -0700 (PDT) Message-ID: <44F4D271.4090500@isi.edu> Date: Tue, 29 Aug 2006 16:49:05 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? References: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> In-Reply-To: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Mahdavi, Jamshid" , "Anantha Ramaiah \(ananth\)" , tcpm@ietf.org, Ted Faber , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1274056917==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1274056917== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45A8BFAB8490563438C21537" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45A8BFAB8490563438C21537 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > It's > possible that the authors did not have the potential > of a DOS attack when they created this mechanism. TCP does not itself defend from DOS attacks. If you want to prevent that, run connections over IPsec. =2E.. > The resources in question are connections and buffers. > Here we are talking potentially huge numbers of them > (100000 connections and even if each connection holds > 1 buffer, that's a lot of buffer memory). A mechanism > to reclaim these resources would have to take into > account the duration of the persist state of the > connections, it can't be done blindly. TCP isn't there to clean up state. If old connection state is interfering with new connections, and the connection isn't making progress, the application layer (the layer that runs the buffers) can tell. That's an application-layer timeout. Joe --------------enig45A8BFAB8490563438C21537 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9NJyE5f5cImnZrsRAsxXAKCN6Ny1N2klHlBBDsj3LNRep5RXiQCgrihd ssb05SM0+bpaewCkyuclz9c= =UQEZ -----END PGP SIGNATURE----- --------------enig45A8BFAB8490563438C21537-- --===============1274056917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1274056917==-- From tcpm-bounces@ietf.org Wed Aug 30 12:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIShn-0005oj-2E; Wed, 30 Aug 2006 12:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIShl-0005oe-8l for tcpm@ietf.org; Wed, 30 Aug 2006 12:14:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISB6-0005Ex-RO for tcpm@ietf.org; Wed, 30 Aug 2006 11:40:32 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIRvi-00021S-8J for tcpm@ietf.org; Wed, 30 Aug 2006 11:24:40 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7UFMBGi011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 08:22:11 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7UFMB04017186; Wed, 30 Aug 2006 08:22:11 -0700 (PDT) (envelope-from faber) Date: Wed, 30 Aug 2006 08:22:11 -0700 From: Ted Faber To: MURALI BASHYAM Subject: Re: [tcpm] TCP zero window timeout? Message-ID: <20060830152210.GI15769@hut.isi.edu> References: <20060829165756.GB89836@hut.isi.edu> <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> Mime-Version: 1.0 In-Reply-To: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810722732==" Errors-To: tcpm-bounces@ietf.org --===============0810722732== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZY5CS28jBCfb727c" Content-Disposition: inline --ZY5CS28jBCfb727c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 29, 2006 at 11:13:14AM -0700, MURALI BASHYAM wrote: > > As an aside, RFC1122 says pretty unambiguously that > > both holding a zero > > window and probing it regularly are intentionally > > supported. >=20 > It does, and i dont understand the rationale of > probing *infinitely* as long as the client is > acknowledging the probe with a zero window. It's > possible that the authors did not have the potential > of a DOS attack when they created this mechanism. In > the scenario that i am talking abt these probes were > sometimes running for hours together and such > connections were ultimately starving out other > legitimate users traffic. The probes come a long time apart after a little while - exponential backoff. If you're running out of buffer space, abort the connections. > >=20 > > > This does not take into account the fact that > > > connections are persisting and probing for peer's > > zero > > > window which is fundamental to the discussion. > >=20 > > The resource your proxy is running out of is CPU to > > do window probes??? > > If so, that's very surprising. If not, can you tell > > me what your > > concern is? > >=20 >=20 > The resources in question are connections and buffers. > Here we are talking potentially huge numbers of them > (100000 connections and even if each connection holds > 1 buffer, that's a lot of buffer memory). A mechanism > to reclaim these resources would have to take into > account the duration of the persist state of the > connections, it can't be done blindly. But that state is easily kept track of by the application. Close the ones that are using the most space and have made the least progress. Even if your implementation doesnt give you access to the full state a conformant TCP stack does (RFC 793 p. 49) gathering that information is pretty easy. I don't know what your environment is, but most have some way to get this or infer it. Once the app is short of space and knows which connections it likes least, it can abort them and reclaim all the resources. > > Without getting too philosophical, the designers of > > TCP did explicitly > > support connections that lock out transmission via a > > zero window size. > >=20 >=20 > I think the crux of the issue here is that this is > left to the client side application control which > means open game for hackers. I agree with your premise, but not your conclusion. I don't understand why you're against doing this in the app, but I don't think I understand your whole problem either. I suggest writing a draft and giving us the full picture. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --ZY5CS28jBCfb727c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE9a0iaUz3f+Zf+XsRAt8fAKDVZt3tRo3eEPzVLw/KBCDjU8Ue7gCffo0G rVz3hv7+W3OHuXowIP64Vto= =IXCH -----END PGP SIGNATURE----- --ZY5CS28jBCfb727c-- --===============0810722732== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0810722732==-- From tcpm-bounces@ietf.org Wed Aug 30 12:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISnw-0000rl-VC; Wed, 30 Aug 2006 12:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISnw-0000rc-82 for tcpm@ietf.org; Wed, 30 Aug 2006 12:20:40 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISnu-0003z3-U1 for tcpm@ietf.org; Wed, 30 Aug 2006 12:20:40 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k7UGJK2Q004056; Wed, 30 Aug 2006 09:19:20 -0700 (PDT) Message-ID: <44F5BA87.4050602@isi.edu> Date: Wed, 30 Aug 2006 09:19:19 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] TCP zero window timeout? References: <20060829165756.GB89836@hut.isi.edu> <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> <20060830152210.GI15769@hut.isi.edu> In-Reply-To: <20060830152210.GI15769@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0153554662==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0153554662== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B814FB3137C138678EE1D8D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B814FB3137C138678EE1D8D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: =2E.. > I don't understand why you're against doing this in the app, but I don'= t > think I understand your whole problem either. I suggest writing a draf= t > and giving us the full picture. I'd rather see succinct answers to the alternatives suggested here that motivate a TCP-level solution first. IDs can easily themselves be a DOS attack on IETF resources. Joe --------------enig3B814FB3137C138678EE1D8D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9bqHE5f5cImnZrsRAqJJAJ4oMt2uWvYSGDOm03WRXPOl4EVAJQCg07u8 eXKwUAtWUsoxozs5fEqH05k= =4OaF -----END PGP SIGNATURE----- --------------enig3B814FB3137C138678EE1D8D-- --===============0153554662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0153554662==-- From tcpm-bounces@ietf.org Wed Aug 30 12:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISry-00034z-2G; Wed, 30 Aug 2006 12:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISrx-00034t-0p for tcpm@ietf.org; Wed, 30 Aug 2006 12:24:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISrv-000546-Kp for tcpm@ietf.org; Wed, 30 Aug 2006 12:24:49 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7UGNkig002857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 09:23:46 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7UGNkqM018538; Wed, 30 Aug 2006 09:23:46 -0700 (PDT) (envelope-from faber) Date: Wed, 30 Aug 2006 09:23:46 -0700 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] TCP zero window timeout? Message-ID: <20060830162345.GL15769@hut.isi.edu> References: <20060829165756.GB89836@hut.isi.edu> <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> <20060830152210.GI15769@hut.isi.edu> <44F5BA87.4050602@isi.edu> Mime-Version: 1.0 In-Reply-To: <44F5BA87.4050602@isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1141642015==" Errors-To: tcpm-bounces@ietf.org --===============1141642015== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vJI8q/aziP9idhqk" Content-Disposition: inline --vJI8q/aziP9idhqk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2006 at 09:19:19AM -0700, Joe Touch wrote: >=20 >=20 > Ted Faber wrote: > ... > > I don't understand why you're against doing this in the app, but I don't > > think I understand your whole problem either. I suggest writing a draft > > and giving us the full picture. >=20 > I'd rather see succinct answers to the alternatives suggested here that > motivate a TCP-level solution first. There are six people exchanging mail about a problem and a solution that don't seem well defined to me. IMHO agreeing on what we're talking about will simplify that discussion. >=20 > IDs can easily themselves be a DOS attack on IETF resources. Or a necessary step forward. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --vJI8q/aziP9idhqk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE9buRaUz3f+Zf+XsRAr52AJ9AlD81v+k5u42W9Y31+OvYQdJ6tACgnnw1 wa6a6Gt++4xtjoGrZekfW4A= =u0b5 -----END PGP SIGNATURE----- --vJI8q/aziP9idhqk-- --===============1141642015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1141642015==-- From tcpm-bounces@ietf.org Wed Aug 30 12:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISx9-0006XA-TS; Wed, 30 Aug 2006 12:30:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISx8-0006X5-O6 for tcpm@ietf.org; Wed, 30 Aug 2006 12:30:10 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISx7-0006CV-Cm for tcpm@ietf.org; Wed, 30 Aug 2006 12:30:10 -0400 Received: from [192.168.1.42] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.6) with ESMTP id k7UGT1f8006044; Wed, 30 Aug 2006 09:29:01 -0700 (PDT) Message-ID: <44F5BCCC.1060105@isi.edu> Date: Wed, 30 Aug 2006 09:29:00 -0700 From: Joe Touch User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] TCP zero window timeout? References: <20060829165756.GB89836@hut.isi.edu> <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com> <20060830152210.GI15769@hut.isi.edu> <44F5BA87.4050602@isi.edu> <20060830162345.GL15769@hut.isi.edu> In-Reply-To: <20060830162345.GL15769@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "Mahdavi, Jamshid" , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , Fernando Gont X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0835720558==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0835720558== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig41D22F9BBA67B290A77E16A4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig41D22F9BBA67B290A77E16A4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Wed, Aug 30, 2006 at 09:19:19AM -0700, Joe Touch wrote: >> >> Ted Faber wrote: >> ... >>> I don't understand why you're against doing this in the app, but I do= n't >>> think I understand your whole problem either. I suggest writing a dr= aft >>> and giving us the full picture. >> I'd rather see succinct answers to the alternatives suggested here tha= t >> motivate a TCP-level solution first. >=20 >=20 > There are six people exchanging mail about a problem and a solution tha= t > don't seem well defined to me. So far here's what I see: the proposers consider "application" to be the end-to-end user program, which may have a data format unavailable to the proxy TCP considers "application" to be the controlling program that manages the TCP connection, e.g., the user program at the endpoints, or the system inside the proxy The system inside the proxy may not know what the user is doing at the endpoints, but it DOES know whether its buffers are empty or full, and whether the connection is making progress. That system can easily decide when to shut connections down if progress isn't being made. --- If an ID described the details of the proxy system such that the above were NOT possible, then that's fine. If the ID makes assertions about "proxies out there" and how they "might" work, then an ID is not productive. > IMHO agreeing on what we're talking > about will simplify that discussion. Yes, but an ID isn't necessarily a step in that direction. A one-page description of the problem is more productive and less work for everyone. If one page is insufficient, a one page explanation of WHY one page is insufficient seems a more useful step forward. Joe --------------enig41D22F9BBA67B290A77E16A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9bzME5f5cImnZrsRAgPxAJ9cbFSANMYBs23i1Qk00bbDKaF9KACgw6p0 fS/K5JC3cXyqzcX2X/8sxRc= =zP6o -----END PGP SIGNATURE----- --------------enig41D22F9BBA67B290A77E16A4-- --===============0835720558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0835720558==-- From tcpm-bounces@ietf.org Wed Aug 30 12:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT9H-0001b4-GY; Wed, 30 Aug 2006 12:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT9F-0001ax-FP for tcpm@ietf.org; Wed, 30 Aug 2006 12:42:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIRtZ-0001jl-9r for tcpm@ietf.org; Wed, 30 Aug 2006 11:22:25 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIRhh-0001Tg-8N for tcpm@ietf.org; Wed, 30 Aug 2006 11:10:12 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7UF9Mls006975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 08:09:22 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7UF9Mc4016897; Wed, 30 Aug 2006 08:09:22 -0700 (PDT) (envelope-from faber) Date: Wed, 30 Aug 2006 08:09:22 -0700 From: Ted Faber To: Mahesh Jethanandani Subject: Re: [tcpm] TCP zero window timeout? Message-ID: <20060830150922.GF15769@hut.isi.edu> References: <44BFE95C.4070001@cisco.com> Mime-Version: 1.0 In-Reply-To: <44BFE95C.4070001@cisco.com> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0755015474==" Errors-To: tcpm-bounces@ietf.org --===============0755015474== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s5/bjXLgkIwAv6Hi" Content-Disposition: inline --s5/bjXLgkIwAv6Hi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2006 at 01:36:44PM -0700, Mahesh Jethanandani wrote: > If not, would it be of interest to this group for me to write a draft, > describing the changes we made? Write a draft. NB: this is the IETF - a standards body. We care what standards you want to change to make your hacks compliant with standards, not what kernel data structures you munged. If you don't have to change any standards to operate, we don't have anything to do. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --s5/bjXLgkIwAv6Hi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE9aoiaUz3f+Zf+XsRAhw+AJ41tUyy1337mUxJl+tr2LWdh8jmawCfd3MZ X89Wm8U8QI/iybZ/LsJcHe8= =kmXm -----END PGP SIGNATURE----- --s5/bjXLgkIwAv6Hi-- --===============0755015474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0755015474==-- From tcpm-bounces@ietf.org Wed Aug 30 15:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVL4-0001Fx-Qa; Wed, 30 Aug 2006 15:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVL3-0001Fg-Eu for tcpm@ietf.org; Wed, 30 Aug 2006 15:03:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITyV-0004vp-58 for tcpm@ietf.org; Wed, 30 Aug 2006 13:35:39 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GITRh-0004jE-DK for tcpm@ietf.org; Wed, 30 Aug 2006 13:01:48 -0400 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7UH17hV013873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 10:01:08 -0700 (PDT) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7UH17FA019352; Wed, 30 Aug 2006 10:01:07 -0700 (PDT) (envelope-from faber) Date: Wed, 30 Aug 2006 10:01:07 -0700 From: Ted Faber To: Mahesh Jethanandani Subject: Re: [tcpm] TCP zero window timeout? Message-ID: <20060830170107.GQ15769@hut.isi.edu> References: <44BFE95C.4070001@cisco.com> <20060830150922.GF15769@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060830150922.GF15769@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1951218263==" Errors-To: tcpm-bounces@ietf.org --===============1951218263== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4dIe/AmYstFUGHTF" Content-Disposition: inline --4dIe/AmYstFUGHTF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2006 at 08:09:22AM -0700, Ted Faber wrote: > On Thu, Jul 20, 2006 at 01:36:44PM -0700, Mahesh Jethanandani wrote: > > If not, would it be of interest to this group for me to write a draft, > > describing the changes we made? >=20 > Write a draft. >=20 > NB: this is the IETF - a standards body. We care what standards you > want to change to make your hacks compliant with standards, not what > kernel data structures you munged. If you don't have to change any > standards to operate, we don't have anything to do. FYI, that's just as a participant. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --4dIe/AmYstFUGHTF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE9cRTaUz3f+Zf+XsRAmgMAKDo9A0z7B9aalGFL4Nm5Y3kqMv63QCbBHSh 4vAn3+dHy9eiEya+80GIUE0= =F0sm -----END PGP SIGNATURE----- --4dIe/AmYstFUGHTF-- --===============1951218263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1951218263==-- From tcpm-bounces@ietf.org Thu Aug 31 14:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqtw-00063G-Om; Thu, 31 Aug 2006 14:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqtt-0005zB-9k; Thu, 31 Aug 2006 14:04:25 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqtr-0008G9-U6; Thu, 31 Aug 2006 14:04:25 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7VI4N59019491; Thu, 31 Aug 2006 11:04:23 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7VI4NxS019490; Thu, 31 Aug 2006 11:04:23 -0700 Date: Thu, 31 Aug 2006 11:04:23 -0700 Message-Id: <200608311804.k7VI4NxS019490@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 4653 on Improving the Robustness of TCP to Non-Congestion Events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4653 Title: Improving the Robustness of TCP to Non-Congestion Events Author: S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton Status: Experimental Date: August 2006 Mailbox: sumitha@tamu.edu, reddy@ee.tamu.edu, mallman@icir.org, eblanton@cs.purdue.edu Pages: 18 Characters: 42268 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-tcp-dcr-07.txt URL: http://www.rfc-editor.org/rfc/rfc4653.txt This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. This memo defines an Experimental Protocol for the Internet community. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm