From tcpm-bounces@ietf.org Sat Dec 01 01:32:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyLtk-0004R0-7H; Sat, 01 Dec 2007 01:32:20 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IyLti-0004Hj-8t for tcpm-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 01:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyLth-0004FH-Qw for tcpm@ietf.org; Sat, 01 Dec 2007 01:32:17 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyLth-0008HZ-D4 for tcpm@ietf.org; Sat, 01 Dec 2007 01:32:17 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lB16W7Hj018211; Fri, 30 Nov 2007 22:32:08 -0800 (PST) Message-ID: <4750FFD6.8070001@isi.edu> Date: Fri, 30 Nov 2007 22:31:50 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] References: <354788.4675.qm@web31710.mail.mud.yahoo.com> In-Reply-To: <354788.4675.qm@web31710.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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="===============1446257231==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1446257231== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig041908E4C670719C04C68080" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig041908E4C670719C04C68080 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: =2E.. > The issue here is that TCP cannot inform the application and have the=20 > application initiate the abort, because it is not necessary that the a= pplication has that connection state=20 > around anymore, it could have been destroyed already, i've alluded to = this issue before.=20 And I have already shown how to address it - SO_LINGER. In the case of a Unix close() call, this can be used to cause close() to block until either the graceful shutdown completes (i.e., all data is sent and ack'd, and the other end closes) OR a timer expires. SO_LINGER already supports a timer for this purpose. Can we please stop trying to add to TCP that which ***ALREADY*** exists in the implementation? Joe --------------enig041908E4C670719C04C68080 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUP/WE5f5cImnZrsRAthBAJsFAUO7nqg+zlGFpjB2qOih/H4E4ACfQmB/ UfruFI2OmXghl/BdEm0/dcI= =RzaJ -----END PGP SIGNATURE----- --------------enig041908E4C670719C04C68080-- --===============1446257231== 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 --===============1446257231==-- From tcpm-bounces@ietf.org Sun Dec 02 11:47:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyrye-0003Gv-Bi; Sun, 02 Dec 2007 11:47:32 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iyryd-0003Gn-Oq for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 11:47:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyryd-0003Gb-FN for tcpm@ietf.org; Sun, 02 Dec 2007 11:47:31 -0500 Received: from web31704.mail.mud.yahoo.com ([68.142.201.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iyryd-00080T-1g for tcpm@ietf.org; Sun, 02 Dec 2007 11:47:31 -0500 Received: (qmail 83270 invoked by uid 60001); 2 Dec 2007 16:47:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Sj0KHWYPG75EhL5UPbUuaenpX0aDjZfsqr7qA5yi9KpsNjwZGSvGgF1bWeQmhuT9nMyv1lymklhc57iEAQ7jsC9ba8nGq8zZF3WS29f8MJvo+A6+22eRBm8agdcqcljtaE+Hvc/qgBldKVzstC7mlCmNMNJFGyvt543ZqQwLfQY=; X-YMail-OSG: MpppZBcVM1nTpbaPDzpqm07xoR_ZwgYtYbgwdITn_X4AuOiYXPPcLvl8fIbKWXkVUm2yR9bMbqvB2uHMtJt.lM5Ky8COcmbR5JPrsBCFgq3.3LTuADg- Received: from [67.161.9.166] by web31704.mail.mud.yahoo.com via HTTP; Sun, 02 Dec 2007 08:47:30 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Sun, 2 Dec 2007 08:47:30 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <442337.83267.qm@web31704.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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 ----- Original Message ---- > From: Joe Touch > To: MURALI BASHYAM > Cc: David Borman ; Anantha Ramaiah ; TCP Maintenance and Minor Extensions WG > Sent: Friday, November 30, 2007 10:31:50 PM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] > > > > MURALI BASHYAM wrote: > ... > > The issue here is that TCP cannot inform the application and have > the > > > application initiate the abort, because it is not necessary that > the > application has that connection state > > around anymore, it could have been destroyed already, i've alluded > to > this issue before. > > And I have already shown how to address it - SO_LINGER. > > In the case of a Unix close() call, this can be used to cause > close() > to > block until either the graceful shutdown completes (i.e., all data is > sent and ack'd, and the other end closes) OR a timer expires. > > SO_LINGER already supports a timer for this purpose. > > Can we please stop trying to add to TCP that which ***ALREADY*** exists > in the implementation? Turning SO_LINGER on causes the application to pay a penalty in the normal scenario, where the close call will block even with a legitimate receiver (or a slow network). This is precisely why applications do not use it, it ties up resources unnecessarily, and how about applications that want non-blocking semantics?. High performance applications care about non-blocking semantics. Let's stop recommending to applications how to use the socket layer, we have to approach this in a manner that doesn't question or change their socket layer usage model. Application changes should be incremental and not disruptive, that's the idea of doing this in the transport layer in the first place. > > Joe > > ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 12:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IysFs-0000pZ-0Z; Sun, 02 Dec 2007 12:05:20 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IysFq-0000nw-O6 for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 12:05:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IysFq-0000nF-Cv for tcpm@ietf.org; Sun, 02 Dec 2007 12:05:18 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IysFp-0001P3-TL for tcpm@ietf.org; Sun, 02 Dec 2007 12:05:18 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lB2H56tf019221; Sun, 2 Dec 2007 09:05:07 -0800 (PST) Message-ID: <4752E5A9.3000502@isi.edu> Date: Sun, 02 Dec 2007 09:04:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] References: <442337.83267.qm@web31704.mail.mud.yahoo.com> In-Reply-To: <442337.83267.qm@web31704.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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="===============1488158378==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1488158378== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig979DC4D4867C676F6BEDF36C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig979DC4D4867C676F6BEDF36C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: =2E.. >> >> MURALI BASHYAM wrote: >> ... >>> The issue here is that TCP cannot inform the application and have the= >>> application initiate the abort, because it is not necessary that >>> the application has that connection state around anymore, it >>> could have been destroyed already, i've alluded to this issue >>> before. >>=20 >> And I have already shown how to address it - SO_LINGER. >>=20 >> In the case of a Unix close() call, this can be used to cause=20 >> close() to block until either the graceful shutdown completes >> (i.e., all data is sent and ack'd, and the other end closes) OR a >> timer expires. >> >> SO_LINGER already supports a timer for this purpose. >> >> Can we please stop trying to add to TCP that which ***ALREADY*** exist= s >> in the implementation? >=20 > Turning SO_LINGER on causes the application to pay a penalty in the nor= mal > scenario, where the close call will block even with a legitimate receiv= er (or a slow > network). This is precisely why applications do not use it, it ties up = resources=20 > unnecessarily, and how about applications that want non-blocking semant= ics?. High > performance applications care about non-blocking semantics. Modern applications programmers are aware of multithreading. You can either leave the app around watching the connection, or offload that to a socket library - i.e., a SOCKET timer (note - note a protocol timer). > Let's stop recommending to applications how to use the=20 > socket layer, we have to approach this in a manner that doesn't questio= n or change > their socket layer usage model. But you want to change their protocol interface model instead? > Application changes should be incremental and not > disruptive, that's the idea of doing this in the transport layer in the= first place. Applications should have changed long ago. Some definitely need to catch up. There is no way to handle DOS attacks with legacy applications written in a legacy manner. Joe --------------enig979DC4D4867C676F6BEDF36C 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUuWuE5f5cImnZrsRAq8mAKCHGLpEClloUUxz++t0poFvASXLqACdHTZQ LnczqCUuAyl5blIiIVXLbgo= =apth -----END PGP SIGNATURE----- --------------enig979DC4D4867C676F6BEDF36C-- --===============1488158378== 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 --===============1488158378==-- From tcpm-bounces@ietf.org Sun Dec 02 12:56:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyt3A-0001MY-GG; Sun, 02 Dec 2007 12:56:16 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iyt39-0001MR-Gh for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 12:56:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyt39-0001MI-5r for tcpm@ietf.org; Sun, 02 Dec 2007 12:56:15 -0500 Received: from web31708.mail.mud.yahoo.com ([68.142.201.188]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iyt38-0007g1-Ge for tcpm@ietf.org; Sun, 02 Dec 2007 12:56:15 -0500 Received: (qmail 78814 invoked by uid 60001); 2 Dec 2007 17:56:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=SKLgPbwNkwXB/5ZoO9qdql/++D/H2jRmddlTAz9fCewgxDuZh0IvydiP2ss0d19w/GJ5MhCMQJ6F4tRl1pJ/pMRgR42XCjrjAyVvKUOhHyrV5v/lRuj74HLtDYuoo/+M3s/zDxP4AbVTgapykDmpKDE3kXK1IXLKKUlbLPQRrRc=; X-YMail-OSG: ReptNrYVM1k5O_qWl8GepHt0PUhPO98ALfn938LrQcylT8K9NJjOxJeEtKdg4F3ybJVns1KJJX.IYUx4MUfFT.fxAYplkxzkHg9SE2ADWuRRXw5jhij0bD5KroW87w-- Received: from [67.161.9.166] by web31708.mail.mud.yahoo.com via HTTP; Sun, 02 Dec 2007 09:56:12 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Sun, 2 Dec 2007 09:56:12 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <825882.78624.qm@web31708.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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 ----- Original Message ---- > From: Joe Touch > To: MURALI BASHYAM > Cc: David Borman ; Anantha Ramaiah ; TCP Maintenance and Minor Extensions WG > Sent: Sunday, December 2, 2007 9:04:41 AM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] > > > > MURALI BASHYAM wrote: > ... > >> > >> MURALI BASHYAM wrote: > >> ... > >>> The issue here is that TCP cannot inform the application and > have > the > >>> application initiate the abort, because it is not necessary that > >>> the application has that connection state around anymore, it > >>> could have been destroyed already, i've alluded to this issue > >>> before. > >> > >> And I have already shown how to address it - SO_LINGER. > >> > >> In the case of a Unix close() call, this can be used to cause > >> close() to block until either the graceful shutdown completes > >> (i.e., all data is sent and ack'd, and the other end closes) OR a > >> timer expires. > >> > >> SO_LINGER already supports a timer for this purpose. > >> > >> Can we please stop trying to add to TCP that which > ***ALREADY*** > exists > >> in the implementation? > > > > Turning SO_LINGER on causes the application to pay a penalty in > the > normal > > scenario, where the close call will block even with a > legitimate > receiver (or a slow > > network). This is precisely why applications do not use it, it > ties > up resources > > unnecessarily, and how about applications that want > non-blocking > semantics?. High > > performance applications care about non-blocking semantics. > > Modern applications programmers are aware of multithreading. > > You can either leave the app around watching the connection, or offload > that to a socket library - i.e., a SOCKET timer (note - note a protocol > timer). > > > Let's stop recommending to applications how to use the > > socket layer, we have to approach this in a manner that > doesn't > question or change > > their socket layer usage model. > > But you want to change their protocol interface model instead? > > > Application changes should be incremental and not > > disruptive, that's the idea of doing this in the transport layer > in > the first place. > > Applications should have changed long ago. Some definitely need > to > catch > up. There is no way to handle DOS attacks with legacy applications > written in a legacy manner. I think you missed my point, let me explain. Application here does NOT care about reliable delivery of data to the peer after it has closed the connection. Hence SO_LINGER is out. Web behaves this way and by any standards it is not a legacy application. Can you explain why an application should keep a connection or socket state around after it has closed the connection AND it does not care about reliable delivery of data to the peer? If it did, they would be using SO_LINGER already, hence my comment about not making socket layer usage recommendations to the app. Even in this scenario, it's important that *****TCP**** does not run out of connection and buffer resources, however. I think the key point this issue illustrates is that it is TCP's resources which are under attack here, and not the application's. I think this distinction has emerged in this email thread a while back, and i don't think there is any disagreement abt it. In most modern systems, these are managed as distinct resources and TCP resources (read connection memory and buffer memory) can get starved with app resources available in plenty. If application resources are under attack, that's application responsibility, of course. Murali > > Joe > > ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 13:33:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytdZ-0000B9-JJ; Sun, 02 Dec 2007 13:33:53 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IytdY-0000Au-Qw for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 13:33:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytdY-00009w-Gf for tcpm@ietf.org; Sun, 02 Dec 2007 13:33:52 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IytdY-0004Ew-0t for tcpm@ietf.org; Sun, 02 Dec 2007 13:33:52 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lB2IXCs0011490; Sun, 2 Dec 2007 10:33:13 -0800 (PST) Message-ID: <4752FA54.3050801@isi.edu> Date: Sun, 02 Dec 2007 10:32:52 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] References: <825882.78624.qm@web31708.mail.mud.yahoo.com> In-Reply-To: <825882.78624.qm@web31708.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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="===============1517731987==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1517731987== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigADB4C9FE2EA2EB15B5E7CD9D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADB4C9FE2EA2EB15B5E7CD9D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: =2E.. >> Applications should have changed long ago. Some definitely need to >> catch up. There is no way to handle DOS attacks with legacy >> applications written in a legacy manner. >=20 > I think you missed my point, let me explain. Application here does NOT = care > about reliable delivery of data to the peer after it has closed the con= nection. > Hence SO_LINGER is out. Web behaves this way and by any standards it is= not a legacy > application. =20 By your metrics, so are any modifications of the TCP API that require rewriting the app. Web servers have been multithreaded for a long time - and even reuse threads to avoid thread creation (see Apache). > Can you explain why an application should keep a connection or socket s= tate around=20 > after it has closed the connection AND it does not care about reliable = delivery of data to the peer? If it doesn't care about reliable delivery, why did it use TCP? Why didn't it ABORT the connection instead of CLOSE? Your example is inconsistent; if you care about reliable delivery AND you care about resource attacks you stick around. If you don't, you are susceptible to DOS attacks. > If it did, they would be using SO_LINGER already, hence my comment abou= t not making > socket layer usage recommendations to the app. Even in this scenario, i= t's important > that *****TCP**** does not run out of connection and buffer resources, = however. TCP doesn't have resources. The OS does. > I think the key point this issue illustrates is that it is TCP's resour= ces which are under attack > here, and not the application's. I think this distinction has emerged i= n this email thread=20 > a while back, and i don't think there is any disagreement abt it. There have been a few of us who believe that the resources under attack are the OS's, not TCP, and then there are the authors - who believe otherwise. > In most modern systems, these are managed as distinct resources and TCP= resources (read > connection memory and buffer memory) can get starved with app resources= available in plenty. > If application resources are under attack, that's application responsib= ility, of course. An app IS under attack when its connections are attacked. Joe --------------enigADB4C9FE2EA2EB15B5E7CD9D 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUvpUE5f5cImnZrsRAgk4AJ9xJzRhmDbWOsHwS4as5lUvusvnSQCgn8Of 7q1YnLkb8EGfbIxbaNm7S4w= =e5z9 -----END PGP SIGNATURE----- --------------enigADB4C9FE2EA2EB15B5E7CD9D-- --===============1517731987== 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 --===============1517731987==-- From tcpm-bounces@ietf.org Sun Dec 02 14:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyubl-0006Md-O0; Sun, 02 Dec 2007 14:36:05 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iyubk-0006MR-Fo for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:36:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyubk-0006MC-3I for tcpm@ietf.org; Sun, 02 Dec 2007 14:36:04 -0500 Received: from web31701.mail.mud.yahoo.com ([68.142.201.181]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iyubj-0003tz-8A for tcpm@ietf.org; Sun, 02 Dec 2007 14:36:04 -0500 Received: (qmail 15731 invoked by uid 60001); 2 Dec 2007 19:36:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=P7RKDB3VELX12LT/ATKqXB/SxJSvOAsIz97SHDnS0SEltV36lmjgHnze9uRNESvy6cvI/plGdcOou+/m9JbmBTfNGs0j7Y1N/z0fnh/RP01FXtEVvZQve2pdHPJz/2UHDF2hLXaSW6xcYopHlEXFiVaBqDb+JFX+1rfVpKEgWZ4=; X-YMail-OSG: fZ4UWOsVM1m75_2fsPiJD6Px1fs1ZDEk9lsjAwt_Prlsnmkvnc760A_D1zluBVkheNem6NjkgzwaJfmQg.SOi8N3flxXcV.iP3R4csiORmBciR_txz4- Received: from [67.161.9.166] by web31701.mail.mud.yahoo.com via HTTP; Sun, 02 Dec 2007 11:36:02 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Sun, 2 Dec 2007 11:36:02 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <491975.14585.qm@web31701.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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 ----- Original Message ---- > From: Joe Touch > To: MURALI BASHYAM > Cc: David Borman ; Anantha Ramaiah ; TCP Maintenance and Minor Extensions WG > Sent: Sunday, December 2, 2007 10:32:52 AM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] > > > > MURALI BASHYAM wrote: > ... > >> Applications should have changed long ago. Some definitely need to > >> catch up. There is no way to handle DOS attacks with legacy > >> applications written in a legacy manner. > > > > I think you missed my point, let me explain. Application here > does > NOT care > > about reliable delivery of data to the peer after it has closed > the > connection. > > Hence SO_LINGER is out. Web behaves this way and by any standards > it > is not a legacy > > application. > > By your metrics, so are any modifications of the TCP API that require > rewriting the app. Web servers have been multithreaded for a long > time > - > and even reuse threads to avoid thread creation (see Apache). > > > Can you explain why an application should keep a connection or > socket > state around > > after it has closed the connection AND it does not care > about > reliable delivery of data to the peer? > > If it doesn't care about reliable delivery, why did it use TCP? Why > didn't it ABORT the connection instead of CLOSE? Reliable delivery is important to the application, but for it to introduce blocking semantics on close and hold up connection resources when 99% of the time data is delivered reliably, is not an acceptable trade-off. For high speed web servers, this is an important requirement. > > Your example is inconsistent; if you care about reliable delivery AND > you care about resource attacks you stick around. If you don't, you are > susceptible to DOS attacks. > > > If it did, they would be using SO_LINGER already, hence my > comment > about not making > > socket layer usage recommendations to the app. Even in this > scenario, > it's important > > that *****TCP**** does not run out of connection and > buffer > resources, however. > > TCP doesn't have resources. The OS does. TCP borrows resources from the OS, just like any other entity in the system does. TCP is the one that knows how to proportion resources among its connections, elephants vs mice, well-behaved vs malicious receivers etc. How do you expect the OS to handle this? And handle it properly? > > > I think the key point this issue illustrates is that it is > TCP's > resources which are under attack > > here, and not the application's. I think this distinction has > emerged > in this email thread > > a while back, and i don't think there is any disagreement abt it. > > There have been a few of us who believe that the resources under attack > are the OS's, not TCP, and then there are the authors - who believe > otherwise. Not necessarily, by that token, so is SYN flood attack on connection memory, and it is the OS that's responsible for memory management, isn';t it?. Isn't that an OS issue? Every protocol attack and vulnerability can be regarded as an OS issue, to keep the protocol designer's life simple :-), that's a poor argument. Another TCP attack is out of order reassembly vulnerability, holding large number of buffers in the out of order queue waiting for the in order segments to arrive. Sure, from an OS perspective there are a large number of buffers being held up in the TCP's queues, does that make it a OS issue? It's protocol vulnerabilities and loopholes that's being exploited here. Protocol designers have a responsibility to think about resource lifetimes during protocol design, TCP is no exception to it. That's just good protocol design 101. > > > In most modern systems, these are managed as distinct resources > and > TCP resources (read > > connection memory and buffer memory) can get starved with > app > resources available in plenty. > > If application resources are under attack, that's > application > responsibility, of course. > > An app IS under attack when its connections are attacked. I agree, the app is under attack too, but the question is who has the visibility to manage this better and under ALL circumstances without impacting performance under normal conditions. To manage this vulnerability caused by a requirement in the TCP protocol, it's not a good idea to ask the application to enable SO_LINGER, when the app has made a conscious decision not do so in the interest of performance. Can you think of WHY this shouldn't be done in TCP, with the go-ahead from the application via a socket option and/or globally by the adminstrator? I've asked this question quite a few times, and i've not received a satisfactory answer from the list so far, i've heard responses a) that it is too risky for TCP to do this, b) that it's a flawed application that's causing this, c) that the OS has failed its responsibility to manage resources, None of these are convincing, when we all agree that it's a protocol vulnerability being exploited by the attacker. Let's just fix the protocol. Murali > > Joe > > ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 15:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvF3-0004Kx-RF; Sun, 02 Dec 2007 15:16:41 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IyvF2-0004IM-AQ for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:16:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvF2-0004Hq-0u for tcpm@ietf.org; Sun, 02 Dec 2007 15:16:40 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyvF1-0000cZ-KC for tcpm@ietf.org; Sun, 02 Dec 2007 15:16:40 -0500 Received: from [75.213.61.14] (14.sub-75-213-61.myvzw.com [75.213.61.14]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lB2KFxIb007263; Sun, 2 Dec 2007 12:16:00 -0800 (PST) Message-ID: <47531269.9070005@isi.edu> Date: Sun, 02 Dec 2007 12:15:37 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] References: <491975.14585.qm@web31701.mail.mud.yahoo.com> In-Reply-To: <491975.14585.qm@web31701.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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="===============1369824051==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1369824051== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6ED4C18BAD329583A5EFB370" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6ED4C18BAD329583A5EFB370 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: =2E.. > Can you think of WHY this shouldn't be done in TCP, with the go-ahead f= rom the application via a socket > option and/or globally by the adminstrator?=20 That would be an implementation decision, which is fine. However, I don't agree that any of this needs to be explained further. RFCs are not substitute for undergraduate background in OS and socket programming techniques. > I've asked this question quite a few times, and i've not received a sat= isfactory answer from the list so far, i've heard responses=20 > a) that it is too risky for TCP to do this, > b) that it's a flawed application that's causing this,=20 > c) that the OS has failed its responsibility to manage resources,=20 >=20 > None of these are convincing, We understand that none of this is convincing you. I don't think you appreciate that it is you who have not convinced us yet that this is NOT one of the above. > when we all agree that it's a protocol vulnerability being exploited by= the attacker.=20 We never agreed to that; in fact, many of us feel that this is a protocol feature that you have shown an artificial attack against which is not necessarily more of a vulnerability than many other attacks against other TCP features. In short, you have not shown a problem that needs to be fixed in TCP yet.= Joe --------------enig6ED4C18BAD329583A5EFB370 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUxJqE5f5cImnZrsRAhA8AKCJKMJJdRuzREslW1CwqFwpYgKoBgCghJ+h eQeE+hPU5TbnNGigiTAWX5w= =raf/ -----END PGP SIGNATURE----- --------------enig6ED4C18BAD329583A5EFB370-- --===============1369824051== 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 --===============1369824051==-- From tcpm-bounces@ietf.org Sun Dec 02 15:29:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvRA-0005r9-6b; Sun, 02 Dec 2007 15:29:12 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IyvR8-0005qb-PO for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 15:29:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvR8-0005pY-FQ for tcpm@ietf.org; Sun, 02 Dec 2007 15:29:10 -0500 Received: from web31711.mail.mud.yahoo.com ([68.142.201.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyvR7-0002Es-Uz for tcpm@ietf.org; Sun, 02 Dec 2007 15:29:10 -0500 Received: (qmail 62944 invoked by uid 60001); 2 Dec 2007 20:29:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=niJGtlNtjUWDEeZjX3N2B/kMZAnWat//QwC5NppFOL0wX8gG2O32BEevfEeQIyHschvLnJ42epTUgDx0C3i/VoKT2fd73hOUq+dvnN7HFELyYKXqdnUd36rTLgoAksnFTRKj9Y63xQ45xfP3S6AjE/+cOtkFXc0G0Me01GfdKi4=; X-YMail-OSG: rmLLzt4VM1lybdhz_PxdTAhoUxSqpNhkiDw9a.YV7ZKqIEJ3.2u191fJr72ssGQ8zcJItYMP1yifOPhmV1WataYBWB6MLpJvm2S52m.lKbCNAHiOsdI- Received: from [67.161.9.166] by web31711.mail.mud.yahoo.com via HTTP; Sun, 02 Dec 2007 12:29:09 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Sun, 2 Dec 2007 12:29:09 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <190369.62707.qm@web31711.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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 ----- Original Message ---- > From: Joe Touch > To: MURALI BASHYAM > Cc: David Borman ; Anantha Ramaiah ; TCP Maintenance and Minor Extensions WG > Sent: Sunday, December 2, 2007 12:15:37 PM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] > > > > MURALI BASHYAM wrote: > ... > > Can you think of WHY this shouldn't be done in TCP, with the > go-ahead > from the application via a socket > > option and/or globally by the adminstrator? > > That would be an implementation decision, which is fine. > > However, I don't agree that any of this needs to be explained further. > RFCs are not substitute for undergraduate background in OS and socket > programming techniques. > > > I've asked this question quite a few times, and i've not received > a > satisfactory answer from the list so far, i've heard responses > > a) that it is too risky for TCP to do this, > > b) that it's a flawed application that's causing this, > > c) that the OS has failed its responsibility to manage resources, > > > > None of these are convincing, > > We understand that none of this is convincing you. I don't think you > appreciate that it is you who have not convinced us yet that this > is > NOT > one of the above. > > > when we all agree that it's a protocol vulnerability being > exploited > by the attacker. > > We never agreed to that; in fact, many of us feel that this is a > protocol feature that you have shown an artificial attack against which > is not necessarily more of a vulnerability than many other attacks > against other TCP features. Explain to me specifically and clearly what the INDEFINITE wait in that ZWP state buys for the protocol or the application. Emphasis on the word INDEFINITE, i.e your arguments cannot relying on using a finite value to limit that duration. We know what its fallouts are. Where is the justification for making it INDEFINITE? The document doesn't give me enough justification for why it made that decision. Murali > > In short, you have not shown a problem that needs to be fixed in > TCP > yet. > > Joe > > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 16:31:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywPF-0004it-25; Sun, 02 Dec 2007 16:31:17 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IywPE-0004eZ-27 for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:31:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywPD-0004cI-Kk for tcpm@ietf.org; Sun, 02 Dec 2007 16:31:15 -0500 Received: from web31702.mail.mud.yahoo.com ([68.142.201.182]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IywPC-0001uJ-VH for tcpm@ietf.org; Sun, 02 Dec 2007 16:31:15 -0500 Received: (qmail 32163 invoked by uid 60001); 2 Dec 2007 21:31:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=rDQut2GjtziY6ODLUakOvaVsw0mqF4RfyE82+QODlC21b1tUINZ8ihk0Q4vyj899KFdNrfRGc1mh2xTqt66sQ0jBeC92BpqBDfj9onYIBC/dIlRKNQN9t6C6xZml3UY9xYxoQjG9fZZ5TwSc+/R/G3zyASQD6IKWrS0MWppfm0w=; X-YMail-OSG: Iw.FsHcVM1mHr31uCHzfJUXyA_.GPH12rMJqtd7wkFY5lLzF4Y8F7rvxm8wDDFmL_0D0R7rU6ZkHREvoIEP25R9tWvnRghbNpVFNp.QYQNXcPeArLGc- Received: from [67.161.9.166] by web31702.mail.mud.yahoo.com via HTTP; Sun, 02 Dec 2007 13:31:13 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Sun, 2 Dec 2007 13:31:13 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] To: David Borman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <486515.31936.qm@web31702.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: TCP Maintenance and Minor Extensions WG , Mark Allman , Joe Touch 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 ----- Original Message ---- > From: David Borman > To: MURALI BASHYAM > Cc: TCP Maintenance and Minor Extensions WG ; Joe Touch ; Mark Allman > Sent: Thursday, November 29, 2007 9:09:29 AM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] > > > On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote: > ... > > The second aspect is the ability of the application to explicitly > > cause the TCP connection > > to leave the ZWP state at the specified time independent of > > available resources. There are > > applications where having this level of control over the TCP > > connection makes sense (web, game servers). > > But aborting this connection with trigger from TCP or OS or > > application is a protocol violation, i don't buy the fact > > that if the OS does it, it's not a violation, that's what i was > > referring to as pure wordplay. > > Fine. Call it wordplay. There's nothing wrong with that, because > you > > *have* to get the words right. You have to be crisp on the protocol > definition. The implementation can blur the boundaries, but the > protocol definition can't. The aborting of a connection (whether in > persist or any other state) when the other side is alive and > responding has to be done by the application. TCP should not be > doing > > that without direct instructions from the application. Whether that > is done directly by the application by using the existing abort or > user timeout interface, or whether a new interface is defined to > allow > > the application tells the OS to run a timer and abort the connection > when the timer goes off, it is still being done under the direction > of > > the application. > > > > A protocol is a contract between the sender and receiver here, and > > the contract defines the wire > > behaviour. > > The TCP protocol is what is defined in RFC 793/1122, and any other > RFCs that are applicable. It is more than just the wire behavior. > > > > I care about the wire behaviour of the > > connection, and if i observe the behaviour of the connection in the > > ZWP state prior to this change, i see > > ACKs and probes exchanged infinitely. With this change (no matter > > who does it, OS, app, TCP), i see > > ACKs and probes being exchanged for some time, followed by a RST > > segment to abort the connection. > > > > Do you agree that if we do the latter without changing the wording > > of RFC1122, it's a protocol > > violation? > > My claim all along has been that it is. > > There already exists two mechanisms for the application to abort a > connection, directly with the abort interface, or indirectly with the > user timeout on the send interface, and you will get the same wire > behavior, a connection in persist state gets aborted. > > The only protocol problem here is to have TCP abort a connection in > ZWP state without the application having first explicitly asked for > that to happen. And if you need a new interface to provide that > functionality, then that will be a change to the TCP protocol. > > The OS freeing up resources when they run out by doing things like > aborting connections is not a protocol violation, because it isn't > TCP > > making that decision. Take that to the extreme, and you'd be arguing > that the system crashing is a TCP protocol violation, and that's just > silly. > > > > > > > If we agree that it's a violation, then it's a standards track > > nature of draft. > > If it changes TCP, in this case adding a new User/TCP interface, then > it should be on the standards track. I agree with your suggestions, a new User/TCP interface is needed to enable the ZWP timer specificially, and have TCP inform the app to ensure that we limit the duration of the connection in the ZWP state. It's upto the application to enable the timer and take the abort action when the timer expires. But TCP will have to take abort action in the scenario where the application has already closed the connection. A separate document (informational) can be written to describe how the application can use the new interface, and also discuss the DoS implications of the ZWP state and provide recommendations on a solution and what it needs to accomplish. Ted, Mark : What do you think? Murali > > -David Borman > > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 16:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywVf-0006dC-GR; Sun, 02 Dec 2007 16:37:55 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IywVe-0006cw-7g for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:37:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywVd-0006cf-TA for tcpm@ietf.org; Sun, 02 Dec 2007 16:37:53 -0500 Received: from smtpoutm.mac.com ([17.148.16.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IywVd-0002mi-72 for tcpm@ietf.org; Sun, 02 Dec 2007 16:37:53 -0500 Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id lB2Lbqwh008782; Sun, 2 Dec 2007 13:37:52 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-20-192.dsl.snfc21.sbcglobal.net [70.132.20.192]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id lB2LbnZH016986; Sun, 2 Dec 2007 13:37:49 -0800 (PST) In-Reply-To: <5.2.1.1.2.20071129221357.04986008@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20071128164030.03e1aa48@pop3.jungle.bt.co.uk> <5.2.1.1.2.20071128164030.03e1aa48@pop3.jungle.bt.co.uk> <5.2.1.1.2.20071129221357.04986008@pop3.jungle.bt.co.uk> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9ee77c9bed4cf392d49f6aeff4774470@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Date: Sun, 2 Dec 2007 13:37:59 -0800 To: Bob Briscoe X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , tcpm@ietf.org, Amit Mondal Subject: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility 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 To Bob and the working group: The discussion with Bob Briscoe concerns the following paragraph in the ECN/SYN draft: The discussion with Bob Briscoe concerns the following paragraph in Section 4 of the ECN/SYN draft: Backwards compatibility: In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node B must have received an ECN-setup SYN packet from node A. However, it is possible that node A supports ECN, but either ignores the CE codepoint on received SYN/ACK packets, or ignores SYN/ACK packets with the ECT or CE codepoint set. If the TCP initiator ignores the CE codepoint on received SYN/ACK packets, this would mean that the TCP responder would not respond to this congestion indication. However, this seems to us an acceptable cost to pay in the incremental deployment of ECN-Capability for TCP's SYN/ACK packets. It would mean that the responder would not reduce the initial congestion window from two, three, or four segments down to one segment, as it should. However, the TCP end nodes would still respond correctly to any subsequent CE indications on data packets later on in the connection. Thus, to be explicit, when a TCP connection includes an initiator that supports ECN but *does not* support ECN-Capability for SYN/ACK packets, in combination with a responder that *does* support ECN-Capabililty for SYN/ACK packets, it is quite possible that the ECN-Capable SYN/ACK packets will be marked rather than dropped in the network, and that the responder will not learn about the ECN mark on the SYN/ACK packet. There are three choices: (1) Leave it as it is, and accept it that sometimes, as a cost of incemental deployment, a SYN/ACK packet would be ECN-marked, and the originator, with an older TCP implementation (ECN-capable, but not understanding ECN-marked SYN/ACK packets), would ignore the ECN mark on the SYN/ACK packet. (I don't know what the Microsoft, Max OS X, and Linux ECN implementations do about ECN-marked SYN/ACK packets, but I would assume that they ignore the ECN marks on SYN/ACK packets...) (2) Use one of the four remaining TCP header flags. On a SYN packet, the flag would mean ECN-SYN ("I want to use ECN, and I understand ECN-marked SYN/ACK packets"). On a packet other than a SYN packet, the TCP flag could be used for something else. The responder already has to look at the TCP header flags to learn that the originator is ECN-capable, so looking at one more flag should not be a problem. (3) Use a two-byte ECN-SYN TCP option on SYN packets, meaning "I understand ECN-marked SYN/ACK packets." There is at most 40 bytes for TCP options, and other options that might be carried by SYN packets include Sack Permitted (2 bytes), MSS (4 bytes), Window Scale (3 bytes), Timestamp (10 bytes). The downside of (1) is that during congestion, SYN-ACK packets could be ECN-marked rather than dropped, and the TCP response might never find out about the ECN-mark on the SYN-ACK packet. This could happen if the TCP originator uses an old ECN-Capable TCP implementation that doesn't response to ECN marks on incoming SYN/ACK packets, and the congested link has ECN enabled. The downside of (2) and (3) is that the TCP flag or TCP option would have to be used in perpetuity, long after all ECN-capable TCP implementations were updated to respond to incoming ECN-marked SYN/ACK packets. This would be a drag for (3), but less of a drag for (2) - the cost of using one of the four remaining header flags might be an acceptable cost. So would the working group like us to use a TCP header flag for this, or not? This is scheduled for a 5-minute slot at TCMP on Tuesday, so we can discuss it then. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 16:40:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywYX-0008KM-OP; Sun, 02 Dec 2007 16:40:53 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IywYW-0008JN-F2 for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 16:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IywYW-0008JE-5V for tcpm@ietf.org; Sun, 02 Dec 2007 16:40:52 -0500 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IywYT-000337-R4 for tcpm@ietf.org; Sun, 02 Dec 2007 16:40:52 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lB2Lem2b023518; Sun, 2 Dec 2007 13:40:48 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 13:40:48 -0800 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Dec 2007 13:40:48 -0800 Message-Id: <72DEBA97-BB90-4347-AAD0-F6BADD9DB6D5@windriver.com> From: David Borman To: MURALI BASHYAM In-Reply-To: <190369.62707.qm@web31711.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] Date: Sun, 2 Dec 2007 15:40:46 -0600 References: <190369.62707.qm@web31711.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 02 Dec 2007 21:40:48.0570 (UTC) FILETIME=[00A4E9A0:01C8352C] X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: TCP Maintenance and Minor Extensions WG , Anantha Ramaiah , Joe Touch 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 Dec 2, 2007, at 2:29 PM, MURALI BASHYAM wrote: > ----- Original Message ---- >> From: Joe Touch ... >> We never agreed to that; in fact, many of us feel that this is a >> protocol feature that you have shown an artificial attack against >> which >> is not necessarily more of a vulnerability than many other attacks >> against other TCP features. > > Explain to me specifically and clearly what the INDEFINITE wait in > that ZWP state buys for the protocol or the application. Emphasis on > the word INDEFINITE, i.e your arguments cannot relying on using a > finite value to limit that duration. We know what its fallouts are. > Where is the justification for making it INDEFINITE? The document > doesn't give me enough justification for why it made that decision. It's called robustness; that's what it buys you. As long as a TCP session is up and responding, TCP does not abort it. And an indefinite wait doesn't mean it'll never end, it just means you don't know *when* it is going to end. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 17:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyxiu-0000Fo-DA; Sun, 02 Dec 2007 17:55:40 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iyxit-00007c-FG for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 17:55:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyxit-0008UG-07 for tcpm@ietf.org; Sun, 02 Dec 2007 17:55:39 -0500 Received: from smtpoutm.mac.com ([17.148.16.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iyxis-0004gM-J7 for tcpm@ietf.org; Sun, 02 Dec 2007 17:55:38 -0500 Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id lB2MtW7b003917; Sun, 2 Dec 2007 14:55:32 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-20-192.dsl.snfc21.sbcglobal.net [70.132.20.192]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id lB2MtVQv013930; Sun, 2 Dec 2007 14:55:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <632f9f6e14ce76205b84f49256c5ddeb@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Date: Sun, 2 Dec 2007 14:55:41 -0800 To: Ted Faber , Mark Allman X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm Subject: [tcpm] slides for ACKCC and for ECN/SYN for 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 I have some slides for discussing ECN-SYN in Vancouver next week. The slides for ECN-SYN are at: http://www.icir.org/floyd/talks/ecnsyn-dec07.pdf http://www.icir.org/floyd/talks/ecnsyn-dec07.ppt The slides for ACKCC are at: http://www.icir.org/floyd/talks/ackcc-dec07.pdf http://www.icir.org/floyd/talks/ackcc-dec07.ps Many thanks. (There is always the chance that these will be modified before Tuesday...) - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Dec 02 21:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz0w8-0008UN-Ot; Sun, 02 Dec 2007 21:21:32 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iz0w7-0008UF-Gj for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 21:21:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz0w7-0008U4-6Z for tcpm@ietf.org; Sun, 02 Dec 2007 21:21:31 -0500 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz0w6-0003NG-H2 for tcpm@ietf.org; Sun, 02 Dec 2007 21:21:30 -0500 Received: from dhcp-4669.ietf70.org (dhcp-4669.ietf70.org [130.129.70.105]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id lB32Kt1K022238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Dec 2007 02:20:59 GMT Message-ID: <47536805.5050804@erg.abdn.ac.uk> Date: Sun, 02 Dec 2007 18:20:53 -0800 From: Gorry Fairhurst User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mallman@icir.org, tcpm@ietf.org, Gorry Fairhurst References: <20071127004720.GD3385@hut.isi.edu> In-Reply-To: <20071127004720.GD3385@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [tcpm] WGLC: comments on 2581bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I have a few comments/questions... --- 1) SMSS - I think the document should also refer to PLPMTUD as a valid IETF-specified way to choose a segment size. --- 2) RMSS - The wording in the draft is not clear whether this is an upper bound to the SMSS, or just one of many ways to discover a sensible SMSS. - Is the default RMSS still 536 bytes also for IPv6, since [RFC1122] does not apply in this context to IPv6. --- 3) ECN - The document speaks only of loss, but I'm assuming that this applies equally to ECN. If that is so, perhaps we should explicitly say so up-front. --- My other comments duplicated some of those already sent:-) Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Dec 03 00:57:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4Ii-0002EG-Em; Mon, 03 Dec 2007 00:57:04 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iz4Ih-0002D4-Q3 for tcpm-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 00:57:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4Ih-0002Ap-EB for tcpm@ietf.org; Mon, 03 Dec 2007 00:57:03 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iz4Ig-0005QT-UV for tcpm@ietf.org; Mon, 03 Dec 2007 00:57:03 -0500 X-AuditID: c0a8013c-aef25bb000001e2e-3b-47539aaca235 Received: from [198.18.174.153] (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 56B584DC007; Sun, 2 Dec 2007 22:56:54 -0700 (MST) Message-ID: <47539A8B.8080708@isi.edu> Date: Sun, 02 Dec 2007 21:56:27 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] References: <190369.62707.qm@web31711.mail.mud.yahoo.com> In-Reply-To: <190369.62707.qm@web31711.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Anantha Ramaiah , TCP Maintenance and Minor Extensions WG , David Borman 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="===============1961566466==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1961566466== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig591E01AFD05E943E901CA475" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig591E01AFD05E943E901CA475 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: =2E.. >>> when we all agree that it's a protocol vulnerability being >> exploited >> > by the attacker.=20 >> We never agreed to that; in fact, many of us feel that this is a >> protocol feature that you have shown an artificial attack against whic= h >> is not necessarily more of a vulnerability than many other attacks >> against other TCP features. >=20 > Explain to me specifically and clearly what the INDEFINITE wait in > that ZWP state buys for the protocol or the application. Emphasis on th= e > word INDEFINITE, i.e your arguments cannot relying on using a finite > value to limit that duration. We know what its fallouts are. Where is > the justification for making it INDEFINITE? The document doesn't give m= e > enough justification for why it made that decision. We've explained the reason for indefinite ZWP multiple times. To repeat it here, TCP is allowed - explicitly - to permit the receiving application to stall the transfer of data until its application is ready to receive it. There is no limit on how long that can take; that has been already described as a *feature* of TCP on this list. You may disagree with this reason. However, the burden of proof of why this is NOT appropriate is on you, since the above is how TCP is already designed, and it is you who consider this an issue. joe --------------enig591E01AFD05E943E901CA475 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHU5qPE5f5cImnZrsRAo8VAKDFmsbSm4spAb+k22G8E+0T56gSaQCfZrsn BAwIO2d48nIhwRW8/P1aaso= =RNPw -----END PGP SIGNATURE----- --------------enig591E01AFD05E943E901CA475-- --===============1961566466== 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 --===============1961566466==-- From tcpm-bounces@ietf.org Mon Dec 03 12:45:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFMU-0006P4-VX; Mon, 03 Dec 2007 12:45:42 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzFMT-0006K9-DZ for tcpm-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 12:45:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFMT-0006K0-2n for tcpm@ietf.org; Mon, 03 Dec 2007 12:45:41 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzFMS-0005ky-KG for tcpm@ietf.org; Mon, 03 Dec 2007 12:45:40 -0500 Received: from [130.129.16.194] (dhcp-10c2.ietf70.org [130.129.16.194]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lB3Hj9Qf003094; Mon, 3 Dec 2007 09:45:10 -0800 (PST) Message-ID: <47544093.8060403@isi.edu> Date: Mon, 03 Dec 2007 09:44:51 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <486515.31936.qm@web31702.mail.mud.yahoo.com> In-Reply-To: <486515.31936.qm@web31702.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: TCP Maintenance and Minor Extensions WG , David Borman , Mark Allman 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="===============0707502759==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0707502759== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F088C68120838A0E93F9E8C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F088C68120838A0E93F9E8C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: =2E.. >>> If we agree that it's a violation, then it's a standards track =20 >>> nature of draft. >> If it changes TCP, in this case adding a new User/TCP interface, then = =20 >> it should be on the standards track. >=20 > I agree with your suggestions, a new User/TCP interface is needed to > enable the ZWP timer specificially, and have TCP inform the app to > ensure that we limit the duration of the connection in the ZWP > state. It's upto the application to enable the timer and take the > abort action when the timer expires. But TCP will have to take abort > action in the scenario where the application has already closed the > connection. >=20 > A separate document (informational) can be written to describe how > the application can use the new interface, and also discuss the DoS > implications of the ZWP state and provide recommendations on a > solution and what it needs to accomplish. It might be more useful to write a single document. That doc should focus on the first item above - convincing the WG to agree this is a "violation" or requires a TCP-level solution. It would also explain why considering this a DOS attack that needs to be prevented is useful. Ultimately, *IF* we agree to change TCP, then that doc would be expanded to include the TCP interface changes and application use example. It should also include solutions that do not change the TCP interface, since it would be unlikely this would be a required immediate change even if it were to go forward. Joe --------------enig8F088C68120838A0E93F9E8C 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.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHVECTE5f5cImnZrsRAsACAJ9p6YU/IK+UjZUr8wXKCN8y4OzxnACfepMM 00CAA/AjIBvbhHlNuBNDcVA= =1tcb -----END PGP SIGNATURE----- --------------enig8F088C68120838A0E93F9E8C-- --===============0707502759== 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 --===============0707502759==-- From tcpm-bounces@ietf.org Tue Dec 04 12:12:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbK9-0008Q9-W0; Tue, 04 Dec 2007 12:12:45 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzbK9-0008Pp-17 for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 12:12:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbK8-0008Pe-2J for tcpm@ietf.org; Tue, 04 Dec 2007 12:12:44 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzbK7-0003eA-M9 for tcpm@ietf.org; Tue, 04 Dec 2007 12:12:43 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lB4HCgur002886 for ; Tue, 4 Dec 2007 09:12:42 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 8B22A12BAE4E for ; Tue, 4 Dec 2007 12:12:38 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0CD1A307A27 for ; Tue, 4 Dec 2007 12:12:25 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Tue, 04 Dec 2007 12:12:24 -0500 Message-Id: <20071204171225.0CD1A307A27@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [tcpm] meeting information 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="===============1048305955==" Errors-To: tcpm-bounces@ietf.org --===============1048305955== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Information for today's TCPM meeting .... Audio for the TCPM meeting: http://videolab.uoregon.edu/events/ietf/ Meeting materials: https://datatracker.ietf.org/meeting/70/materials.html Jabber chat room: tcpm@jabber.ietf.org I haven't gotten all the slides yet, but I will post them as they roll in. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHVYp4WyrrWs4yIs4RAgvQAKCKK+FmUQ88FJlcc6RBdt88tuJO2ACglbnq LpHl8K9xm4o383/fUHjacvE= =TnMq -----END PGP SIGNATURE----- --=_bOundary-- --===============1048305955== 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 --===============1048305955==-- From tcpm-bounces@ietf.org Tue Dec 04 14:30:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdTB-0005VS-7r; Tue, 04 Dec 2007 14:30:13 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzdT5-0005I6-3E for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 14:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdT4-0005HF-8B for tcpm@ietf.org; Tue, 04 Dec 2007 14:30:06 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdT1-00049o-UH for tcpm@ietf.org; Tue, 04 Dec 2007 14:30:06 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lB4JTx9L005550; Tue, 4 Dec 2007 11:29:59 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id E4F9A12BBE92; Tue, 4 Dec 2007 14:29:54 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5FDB4307D60; Tue, 4 Dec 2007 14:29:41 -0500 (EST) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <47536805.5050804@erg.abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lightning Crashes MIME-Version: 1.0 Date: Tue, 04 Dec 2007 14:29:41 -0500 Message-Id: <20071204192941.5FDB4307D60@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tcpm@ietf.org Subject: [tcpm] Re: WGLC: comments on 2581bis 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="===============0860044295==" Errors-To: tcpm-bounces@ietf.org --===============0860044295== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Gorry- Thanks for the comments. > --- > 1) SMSS > - I think the document should also refer to PLPMTUD as a valid > IETF-specified way to choose a segment size. Fair enough. I am adding a reference. > --- > 2) RMSS > - The wording in the draft is not clear whether this is an upper > bound to the SMSS, or just one of many ways to discover a sensible > SMSS. The latter. I guess I am not quite sure what to do with this comment. > - Is the default RMSS still 536 bytes also for IPv6, since [RFC1122] > does not apply in this context to IPv6. I think so. Are you suggesting here that we specify a different value when we're going over IPv6? I am not sure if that is a 2581bis thing or a 1122bis thing. > 3) ECN > - The document speaks only of loss, but I'm assuming that this applies > equally to ECN. If that is so, perhaps we should explicitly say so up-front. In the intro to section 3 I have put these words: Also note that the algorithms specified in this document work in terms of using loss as the signal of congestion. Explicit Congestion Notification (ECN) could also be used as discussed in [RFC3168]. Does this work? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHVaqlWyrrWs4yIs4RAgztAJ9GN4QZGG9QA4SjcWgT0xgotYt1wgCePU/0 l2f2mFy6d4oC9KaSl3ZVoww= =mNVZ -----END PGP SIGNATURE----- --=_bOundary-- --===============0860044295== 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 --===============0860044295==-- From tcpm-bounces@ietf.org Tue Dec 04 16:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfRN-00062R-D6; Tue, 04 Dec 2007 16:36:29 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzfRL-0005zE-Q1 for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:36:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfRL-0005xW-EM for tcpm@ietf.org; Tue, 04 Dec 2007 16:36:27 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzfRL-0000Y8-5C for tcpm@ietf.org; Tue, 04 Dec 2007 16:36:27 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lB4LaPk2015248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2007 15:36:26 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lB4LaPKk020323; Tue, 4 Dec 2007 13:36:25 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lB4LaOll020286; Tue, 4 Dec 2007 13:36:25 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 13:36:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] FW: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.txt Date: Tue, 4 Dec 2007 13:36:04 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040499FC@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF317C7A@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] FW: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.txt Thread-Index: AcgqkemR2filvGOwSHK+YLDvy+fHUwFigDSgAafyNaA= References: <5F6519BF2DE0404D99B7C75607FF76FF317C7A@mx1.office> From: "Henderson, Thomas R" To: "Simon Schuetz" X-OriginalArrivalTime: 04 Dec 2007 21:36:24.0363 (UTC) FILETIME=[B7FD9FB0:01C836BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 =20 > -----Original Message----- > From: Simon Schuetz [mailto:Simon.Schuetz@nw.neclab.eu]=20 > Sent: Monday, November 26, 2007 3:14 AM > To: tcpm@ietf.org > Cc: draft-schuetz-tcpm-tcp-rlci@tools.ietf.org > Subject: [tcpm] FW: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.txt=20 >=20 > Hi, >=20 > We submitted a revision of the TCP RLCI draft. >=20 > Major changes/improvements: > - state machine now implements 3-way handshake to guarantee=20 > delivery of connectivity-change indication > - better "stale ack" detection > - improved handling in case of out-of-order delivery >=20 > Comments welcome, > Simon >=20 Simon, I was curious whether you or anyone on the list knows of a Linux implementation of any portions of the above draft. Thanks, Tom _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Dec 04 16:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfnQ-0002b5-PA; Tue, 04 Dec 2007 16:59:16 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzfnO-0002aR-P9 for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:59:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfnO-0002aD-F0 for tcpm@ietf.org; Tue, 04 Dec 2007 16:59:14 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzfnO-0002Rl-4o for tcpm@ietf.org; Tue, 04 Dec 2007 16:59:14 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.14.1/8.13.3) with ESMTP id lB4Lx99k002506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 16:59:09 -0500 (EST) Message-ID: <4755CDA8.1010207@psc.edu> Date: Tue, 04 Dec 2007 16:59:04 -0500 From: John Heffner User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Re: WGLC: comments on 2581bis References: <20071204192941.5FDB4307D60@lawyers.icir.org> In-Reply-To: <20071204192941.5FDB4307D60@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: gorry@erg.abdn.ac.uk, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > Gorry- >> - Is the default RMSS still 536 bytes also for IPv6, since [RFC1122] >> does not apply in this context to IPv6. > > I think so. Are you suggesting here that we specify a different value > when we're going over IPv6? I am not sure if that is a 2581bis thing or > a 1122bis thing. In principle, the TCP's MSS may be independent of MTU, even though in most reasonable implementations it's going to be at least as large (minus headers). I think 536 applies to IPv6 as well. Linux uses this value hard-coded for both IPv4 and IPv6. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Dec 04 17:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfy0-0000pD-VE; Tue, 04 Dec 2007 17:10:12 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Izfxz-0000mo-Tp for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:10:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfxz-0000mV-Ib for tcpm@ietf.org; Tue, 04 Dec 2007 17:10:11 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izfxz-0003Pj-4T for tcpm@ietf.org; Tue, 04 Dec 2007 17:10:11 -0500 Received: from jurassic.eng.sun.com ([129.146.56.36]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB4MA3MD011783; Tue, 4 Dec 2007 22:10:03 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4MA2OV625236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 14:10:02 -0800 (PST) Message-ID: <4755D039.9000203@sun.com> Date: Tue, 04 Dec 2007 14:10:01 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: David Borman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> In-Reply-To: <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: TCP Maintenance and Minor Extensions WG , Joe Touch , Mark Allman 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 David Borman wrote: > While I agree with the document on the identification of the problem, I > disagree with the proposed solution (changing TCP to time out > connections in persist state). Having a connection stay in persist > state for long periods of time (i.e., zero window probes continue to be > ACKed) by itself is not a bad thing. That is how TCP was designed to > work. Connections can survive through lots of adversity. If a > connection is stuck because it is waiting for user action and the user > walked away and went home for the day, he should be able to come back > the next morning and do what needs to be done, and then the connection > will continue. I'm of the same opinion. As far as it comes to recommending a mitigation technique when TCP and the OS runs out of memory resources I think we can do better than merely looking at connections in persist state. As others have pointed out there is also the case of a connection which makes very slow progress (and uses up a fair bit of send buffer space). Ideally one don't want to penalize connections that happen to be over slow links, so some care would be needed. Erik _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Dec 04 20:03:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izifd-0004HK-Qn; Tue, 04 Dec 2007 20:03:25 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Izifc-000485-JM for tcpm-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 20:03:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izifc-00045O-5J for tcpm@ietf.org; Tue, 04 Dec 2007 20:03:24 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izifb-0008DY-M2 for tcpm@ietf.org; Tue, 04 Dec 2007 20:03:24 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB5130SL002639; Wed, 5 Dec 2007 03:03:19 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 03:03:17 +0200 Received: from dhcp-177a.ietf70.org ([10.162.252.137]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 03:03:16 +0200 Message-Id: <5C2B207C-B26D-49A6-9D12-9A1C739A8F78@nokia.com> From: Lars Eggert To: "ext Henderson, Thomas R" In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040499FC@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [tcpm] FW: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.txt Date: Tue, 4 Dec 2007 17:03:14 -0800 References: <5F6519BF2DE0404D99B7C75607FF76FF317C7A@mx1.office> <77F357662F8BFA4CA7074B0410171B6D040499FC@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 05 Dec 2007 01:03:16.0737 (UTC) FILETIME=[9E579710:01C836DA] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tcpm@ietf.org, Simon Schuetz 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="===============1850192648==" Errors-To: tcpm-bounces@ietf.org --===============1850192648== Content-Type: multipart/signed; boundary=Apple-Mail-40--533937775; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-40--533937775 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2007-12-4, at 13:36, ext Henderson, Thomas R wrote: > I was curious whether you or anyone on the list knows of a Linux > implementation of any portions of the above draft. We have ns2 code that we'll make available in a few weeks. There is no Linux implementation for RLCI. There was some Linux code for the earlier drafts of which RLCI is a merge. But RLCI is now very different from those, so that code is not very useful anymore. Lars --Apple-Mail-40--533937775 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTIwNTAxMDMxNFowIwYJKoZI hvcNAQkEMRYEFDeVOY+inwPp5zvwsM9xw3sXb5MvMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQa3GQsUdC7WDruGWZh/A+4jCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQa3GQsUdC7WDruGWZh/A+4jANBgkqhkiG9w0BAQEFAASCAQBYklvpdotVe2s383kaOIYNf55U v81w3Q0DHjMU0Ryn+ZhFyI4SLmOBlzia2eMYKDuNPiEEyBrvA7vk3+fXu2yyoRffQsJ35PAL3U95 ubGS+s4+Lwb/ANjEdDRltfOIDtp+PrL4LeqCt0QqqBEjizr1wtMsaiCTN6BIyR9Acubkb0iVhgoi rjfS4RqYesvtVx70vcYbnl1GAuVJz3+RujI5cVM0WKcCxbSUAKBigZVMXCcssBNgQmvUUckdN1fR k0sTAocs25Ocsz1kXUkWggZ+YrBE7YhEzHm2W+VsDECAD6DvMXBCk7l8mw4p6rNAyoiqrDbUWcvY fTEXEC7btAMHAAAAAAAA --Apple-Mail-40--533937775-- --===============1850192648== 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 --===============1850192648==-- From tcpm-bounces@ietf.org Wed Dec 05 00:18:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzmeL-0000X1-Hy; Wed, 05 Dec 2007 00:18:21 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IzmeK-0000Ue-MT for tcpm-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 00:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzmeK-0000TX-BX for tcpm@ietf.org; Wed, 05 Dec 2007 00:18:20 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzmeJ-0007Ir-Q0 for tcpm@ietf.org; Wed, 05 Dec 2007 00:18:20 -0500 Received: from dhcp-4669.ietf70.org (dhcp-4669.ietf70.org [130.129.70.105]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id lB55HkLm017866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Dec 2007 05:17:48 GMT Message-ID: <47563473.8000909@erg.abdn.ac.uk> Date: Tue, 04 Dec 2007 21:17:39 -0800 From: Gorry Fairhurst User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Re: WGLC: comments on 2581bis References: <20071204192941.5FDB4307D60@lawyers.icir.org> In-Reply-To: <20071204192941.5FDB4307D60@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gf@erg.abdn.ac.uk X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: gorry@erg.abdn.ac.uk, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > Gorry- > >> --- >> 2) RMSS >> - The wording in the draft is not clear whether this is an upper >> bound to the SMSS, or just one of many ways to discover a sensible >> SMSS. > > The latter. I guess I am not quite sure what to do with this comment. > >> - Is the default RMSS still 536 bytes also for IPv6, since [RFC1122] >> does not apply in this context to IPv6. > > I think so. Are you suggesting here that we specify a different value > when we're going over IPv6? > I queried if this should have been different for v6, because I'd have expected it was safe to use 1220. > I am not sure if that is a 2581bis thing or a 1122bis thing. RFC 2460, only says: " For example, in IPv4, TCP's MSS option is computed as the maximum packet size (a default value or a value learned through Path MTU Discovery) minus 40 octets (20 octets for the minimum-length IPv4 header and 20 octets for the minimum-length TCP header). When using TCP over IPv6, the MSS must be computed as the maximum packet size minus 60 octets, extension headers) is 20 octets longer than a minimum-length IPv4 header." - All of which is true, but does not explicitly update TCP's default MSS. Looking at code, it seems 1024 is not uncommon.... Well that was fun, if you know better, do improve the text, otherwise I expect the current text is fine. >> 3) ECN >> - The document speaks only of loss, but I'm assuming that this applies >> equally to ECN. If that is so, perhaps we should explicitly say so up-front. > > In the intro to section 3 I have put these words: > > Also note that the algorithms specified in this document work in > terms of using loss as the signal of congestion. Explicit > Congestion Notification (ECN) could also be used as discussed in > [RFC3168]. > > Does this work? > Yes, that would be fine - I'd prefer /defined in [3168]/specified in [3168]/ or something of the like. > allman > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm best wishes, Gorry _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Dec 06 17:47:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PV2-0006GD-GU; Thu, 06 Dec 2007 17:47:20 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1J0PV1-0006G7-Dh for tcpm-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 17:47:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PV1-0006EJ-1I for tcpm@ietf.org; Thu, 06 Dec 2007 17:47:19 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0PV0-00082B-2M for tcpm@ietf.org; Thu, 06 Dec 2007 17:47:18 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6CFEC5A8AA6 for ; Thu, 6 Dec 2007 19:47:20 -0300 (ART) Received: from IBM-Kovalski.gont.com.ar (190-48-244-19.speedy.com.ar [190.48.244.19] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id lB6MlDnS008342 for ; Thu, 6 Dec 2007 19:47:15 -0300 Message-Id: <7.0.1.0.0.20071206194615.059a7d40@gmx.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 06 Dec 2007 19:49:01 -0500 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 06 Dec 2007 19:47:19 -0300 (ART) X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [tcpm] Fwd: [Tsvwg] I-D Action:draft-ietf-tsvwg-port-randomization-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Folks, FYI, we have submitted a new revision of our port randomization draft. This is the first revision of the doc since it was accepted as a wg item of the tsvwg. Any feedback will be more than welcome. Thanks! >To: i-d-announce@ietf.org >From: Internet-Drafts@ietf.org >Date: Thu, 06 Dec 2007 17:20:01 -0500 >X-Spam-Score: 0.0 (/) >X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 >Cc: tsvwg@ietf.org >Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-port-randomization-00.txt >X-BeenThere: tsvwg@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: Transport Area Working Group >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) >X-GMX-Htest: 0.46 >X-GMX-Antispam: 0 (Mail was not recognized as spam) >X-GMX-UID: qgQxKIBAMydyh9prVGtlb79raGRhZlpf > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Transport Area Working Group >Working Group of the IETF. > > > Title : Port Randomization > Author(s) : M. Larsen, F. Gont > Filename : draft-ietf-tsvwg-port-randomization-00.txt > Pages : 22 > Date : 2007-12-06 > >Recently, awareness has been raised about a number of "blind" attacks >that can be performed against the Transmission Control Protocol (TCP) >and similar protocols. The consequences of these attacks range from >throughput-reduction to broken connections or data corruption. These >attacks rely on the attacker's ability to guess or know the five- >tuple (Protocol, Source Address, Destination Address, Source Port, >Destination Port) that identifies the transport protocol instance to >be attacked. This document describes a simple and efficient method >for random selection of the client port number, such that the >possibility of an attacker guessing the exact value is reduced. >While this is not a replacement for cryptographic methods, the >described port number randomization algorithms provide improved >security/obfuscation with very little effort and without any key >management overhead. The mechanisms described in this document are a >local modification that may be incrementally deployed, and that does >not violate the specifications of any of the transport protocols that >may benefit from it, such as TCP, UDP, SCTP, DCCP, and RTP. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then > "get draft-ietf-tsvwg-port-randomization-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-tsvwg-port-randomization-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2007-12-06171011.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-tsvwg-port-randomization-00.txt > > > -- 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 Fri Dec 14 20:52:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3MCC-0007fs-QF; Fri, 14 Dec 2007 20:52:04 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1J3MCB-0007fR-D9 for tcpm-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 20:52:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3MCB-0007fH-1u for tcpm@ietf.org; Fri, 14 Dec 2007 20:52:03 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3MCA-0000qd-J1 for tcpm@ietf.org; Fri, 14 Dec 2007 20:52:02 -0500 Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lBF1paWk005100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Dec 2007 17:51:36 -0800 (PST) Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id lBF1pZ6u065541 for tcpm@ietf.org; Fri, 14 Dec 2007 17:51:35 -0800 (PST) (envelope-from faber) Date: Fri, 14 Dec 2007 17:51:35 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: 2581bis Message-ID: <20071215015135.GA65347@zod.isi.edu> References: <20071127004720.GD3385@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20071127004720.GD3385@hut.isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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="===============0968510763==" Errors-To: tcpm-bounces@ietf.org --===============0968510763== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2007 at 04:47:20PM -0800, Ted Faber wrote: > Mark and I would like to start a WGLC for the revision of 2581 from > Proposed Standard to Draft Standard. >=20 > As you know, this is a central document in TCP and the revision pretty > much just recognized that and adds an implementation report. The > implementation report notes that basically all TCPs support the > algorithms in the document interoperably. We believe this is ready for > publication. >=20 > Other than the addition of the report, changes to the document from the > published Proposed Standard are minimal. >=20 > Please read and let us know if you agree or disagree and why. This will > be a long WGLC to accomodate for the IETF meeting next week and the > holiday season. The WGLC will end 21 Dec 2007. >=20 Just a reminder: this WGLC ends 21 Dec 2007. Please comment if you have an opinion - including an opinion that the draft is publishable. Thanks! --=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 --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHYzMmaUz3f+Zf+XsRArbIAJ9AFH18gnh3nM1/7RiIMqr2HTVLbACg9hX4 sf1NMK+p9SMNb9Py5/CkGkw= =VSwV -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- --===============0968510763== 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 --===============0968510763==-- From tcpm-bounces@ietf.org Sun Dec 16 19:21:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J43j7-0002tA-AT; Sun, 16 Dec 2007 19:20:57 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1J43j6-0002t5-Q0 for tcpm-confirm+ok@megatron.ietf.org; Sun, 16 Dec 2007 19:20:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J43j6-0002sx-G6 for tcpm@ietf.org; Sun, 16 Dec 2007 19:20:56 -0500 Received: from gateway.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J43j3-0005fA-SW for tcpm@ietf.org; Sun, 16 Dec 2007 19:20:56 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA117670802; Mon, 17 Dec 2007 01:20:02 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA02239; Mon, 17 Dec 2007 01:20:01 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200712170020.BAA02239@TR-Sys.de> Subject: Re: [tcpm] WGLC: 2581bis To: tcpm@ietf.org Date: Mon, 17 Dec 2007 01:20:01 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Fri, 14 Dec 2007 17:51:35 -0800, Ted Faber wrote: > ... > > Just a reminder: this WGLC ends 21 Dec 2007. > Please comment if you have an opinion - including ... I had commented in private communication successively on previous revisions of 2581bis, and the comments have been discussed and resolved; hence ... > an opinion that the draft is publishable. ... IMHO, it is, provided that the remaining minor issues already raised in comments posted to the list and discussed since WGLC are getting resolved! Alfred. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Dec 21 22:04:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5uf4-0007ak-1E; Fri, 21 Dec 2007 22:04:26 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1J5uf2-0007af-Jg for tcpm-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 22:04:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5uf2-0007aX-8E for tcpm@ietf.org; Fri, 21 Dec 2007 22:04:24 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5uf1-00034O-Bv for tcpm@ietf.org; Fri, 21 Dec 2007 22:04:24 -0500 Received: from x40-26.cs.helsinki.fi (a88-112-189-166.elisa-laajakaista.fi [88.112.189.166]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 22 Dec 2007 05:04:21 +0200 id 000805C0.476C7EB5.00007DDB Received: by x40-26.cs.helsinki.fi (Postfix, from userid 3011) id 8B1A8BFC5; Sat, 22 Dec 2007 05:04:20 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by x40-26.cs.helsinki.fi (Postfix) with ESMTP id 63BC7BFB4; Sat, 22 Dec 2007 05:04:20 +0200 (EET) Date: Sat, 22 Dec 2007 05:04:19 +0200 (EET) From: Markku Kojo To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: 2581bis In-Reply-To: <20071127004720.GD3385@hut.isi.edu> Message-ID: References: <20071127004720.GD3385@hut.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: blanton@cs.purdue.edu, Ted Faber , vern@icir.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ted, Mark, all, I'd like to see this document to advance to DS. However, after reading the draft and taking a look at a few traces from Linux TCP implementation it seems that there is one issue that may need some attention first. Looking into the Linux TCP behavior (that differs from what the draft specifies) seems to reveal an issue with the draft in its usage of FlightSize as a bad estimate for the amount of outstanding data in the *network* and consequently inappropriate adjustment of ssthresh (and cwnd). That is, replacing cwnd with FlightSize in equation 4 seem to have resulted in similar kind of problems as there were earlier when cwnd was used in the equation: When Limited Transmit alg (step 1 of fast rexmit & fast recovery alg in Section 3.2) is used with the current definition of FlightSize and equation 4, ssthresh and cwnd will be assigned larger value than what would be appropriate. The reason is that FlightSize is increased in step 1 and it is then used in step 2 and 3 to determine the new value of ssthresh and cwnd. However, allowing Limited Transmit to send a new data segment on the arrival of the 1st and 2nd dupack rests on the assumption that a dupack indicates that a segment has left the network and thereby the number of outstanding segments in the network remains unchanged (like cwnd remains). This means that using Limited Transmit results in less reduction in ssthresh and cwnd compared to the case where Limited Transmit is not in use. As the difference in the new ssthresh (and cwnd) value is only (at most) one MSS, this does not make TCP significantly more aggressive with large windows, but with a small window size the difference is significant. For example, with cwnd of 4 segments and a single segment loss, a TCP sender applying Limited Transmit per current spec continues with cwnd of 3 segments while a TCP sender not applying Limited Transmit halves its cwnd and continues with cwnd of 2 segments. This may have a significant effect on a bottleneck link that is shared by a number of connections proceeding with a small window. One simple possibility of fixing this is to redefine equation 4 as ssthresh = max ( min(FlightSize,cwnd) / 2, 2*SMSS) Similar problems in correctly determining a new value of ssthresh may occur also in other cases where the actual amount of outstanding data (significanly) differs from FlightSize, i.e., when TCP sender is already in loss recovery. Linux does not experience this problem with FlightSize as it maintains a more accurate estimate (akin to pipe variable in RFC 3517) for the amount of outstanding data, and uses it to determine the new value of ssthresh (and cwnd) when entering loss recovery. Other comments/suggestions: 1. Section 3.1, 3rd para: It might be useful also note that the purpose of the slow start algorithm is to (re)start the ack clock (in addition to determining the available capacity). 2. Section 3.1: "On the other hand, when a TCP sender detects segment loss using the retransmission timer and the given segment has already been retransmitted at least once, the value of ssthresh is held constant." Should be clarified that this applies only when the retransmission timer expires again for the same segment, not when retransmission timer expires for a fast retransmitted segment. 3. Section 3.2, 1st step of the fast retransmit and fast recovery alg: It would be useful to note that allowing a TCP sender to send a new data segment on the 1st and 2nd dupack is in violation to the definition of cwnd in Section 2: "At any given time, a TCP MUST NOT send data with a sequence number higher than the sum of the highest acknowledged sequence number and the minimum of cwnd and rwnd." 4. Section 4.3: "Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case." Lowering ssthresh twice on the loss of a retransmission triggered by an RTO would be in contradiction with what is said in Section 3.1 (see item 2 above). Should clarify that this is valid only with the loss of a fast retransmit (or the loss of a retransmission in fast recovery with an advanced loss recovery alg such as NewReno or SACK-based fast recovery) Thanks, /Markku _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Dec 26 22:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7j8I-0001O9-Dm; Wed, 26 Dec 2007 22:10:06 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1J7j8F-0001HH-OC for tcpm-confirm+ok@megatron.ietf.org; Wed, 26 Dec 2007 22:10:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7j8F-0001FY-CU; Wed, 26 Dec 2007 22:10:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7j8E-0006aZ-Ly; Wed, 26 Dec 2007 22:10:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 670EE26E4D; Thu, 27 Dec 2007 03:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J7j8E-0004eO-9u; Wed, 26 Dec 2007 22:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Dec 2007 22:10:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-soft-errors-07.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-07.txt Pages : 16 Date : 2007-12-26 This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-07.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-07.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-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-26220650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-26220650.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--