From tcpm-bounces@ietf.org Wed Jan 03 19:54:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Grt-0006eD-5T; Wed, 03 Jan 2007 19:54:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Grr-0006e2-Ie for tcpm@ietf.org; Wed, 03 Jan 2007 19:54:03 -0500 Received: from smtp.osdl.org ([65.172.181.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Grq-0002lj-5L for tcpm@ietf.org; Wed, 03 Jan 2007 19:54:03 -0500 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l040rkh7019160 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 3 Jan 2007 16:53:46 -0800 Received: from freekitty (freekitty.pdx.osdl.net [10.8.0.54]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id l040rhDF005173; Wed, 3 Jan 2007 16:53:44 -0800 Date: Wed, 3 Jan 2007 16:53:43 -0800 From: Stephen Hemminger To: Ted Faber Subject: Re: [tcpm] encouraging wider participation Message-ID: <20070103165343.2e79d7c0@freekitty> In-Reply-To: <20061127212724.GC45754@hut.isi.edu> References: <20061122103922.6aefdda1@freekitty> <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.com> <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> <20061127212724.GC45754@hut.isi.edu> Organization: OSDL X-Mailer: Sylpheed-Claws 2.5.0-rc3 (GTK+ 2.10.6; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.695 required=5 tests=AWL, OSDL_HEADER_SUBJECT_BRACKETED X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.107__ X-MIMEDefang-Filter: osdl$Revision: 1.165 $ X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org, Mark Allman , Fernando Gont , Lars Eggert , Jeffrey Hsu 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 Mon, 27 Nov 2006 13:27:24 -0800 Ted Faber wrote: > On Mon, Nov 27, 2006 at 02:31:52AM -0300, Fernando Gont wrote: > > At 20:56 22/11/2006, Duke, Martin wrote: > > > > >If IETF would like to coordinate more with Linux, is the right move to > > >send IETF reps to the next Linux meeting, to tell them what we're > > >working on and how it might be useful to them? > > > > I'd argue that, if anything, somebody from each major open source OS > > should be sent to the IETF meetings. That way, they could share their > > implementation/real-world experience in the meetings. > > Make it so. > > (See the problem?) > Several core networking developers already go to IETF meetings. Jamal Hadi Salam who worked on Traffic Control, and Yoshifuji from Linux IPV6 project attends as well. -- Stephen Hemminger _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 04 04:29:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ote-00058E-DI; Thu, 04 Jan 2007 04:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Otc-000585-NE for tcpm@ietf.org; Thu, 04 Jan 2007 04:28:24 -0500 Received: from wall.ikr.uni-stuttgart.de ([129.69.170.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Otb-0000Yc-95 for tcpm@ietf.org; Thu, 04 Jan 2007 04:28:24 -0500 Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id A706756CF5 for ; Thu, 4 Jan 2007 10:28:20 +0100 (CET) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 9F5E3BC080; Thu, 4 Jan 2007 10:28:05 +0100 (CET) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 4A6AFBC082 for ; Thu, 4 Jan 2007 10:28:02 +0100 (CET) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Thu, 4 Jan 2007 10:28:02 +0100 Date: Thu, 28 Dec 2006 14:23:03 +0100 From: Michael Scharf To: Lloyd Wood Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Message-ID: <20061228132303.GA13341@ikr.uni-stuttgart.de> References: <200611171813.kAHIDsX5011589@nlpi015.sbcis.sbc.com> <200611211541.PAA21521@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611211541.PAA21521@cisco.com> User-Agent: Mutt/1.4.2.2i Resent-From: michael.scharf@ikr.uni-stuttgart.de Resent-Date: Thu, 4 Jan 2007 10:28:02 +0100 Resent-To: tcpm@ietf.org Resent-Message-Id: <20070104092802.4A6AFBC082@netsrv1.ikr.uni-stuttgart.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, 21 Nov 2006 at 15:41:04, Lloyd Wood wrote: > >FWIW, Linux has had ABC for quite some time now as well. First it was > >enabled by default, but no it's disabled now due to the performance > >problems in lots of applications which seem to rely on earlier > >behaviour. > > Do you have a pointer to information on the problems with applications? > > I'd been presuming that ABC is universally a good thing, even though its use blocks the count-the-acks-not-the-bytes sender hole that allows simple ack-splitting intercept-one-ack-send-two 'TCP acceleration', which isn't outlined in RFC3135, but is implemented in Cisco IOS: > http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a0080683d9d.html Performance problems might also occur with typical signaling applications, e. g., in IP telephony platforms: We have performed measurements on the end-to-end delay of small-sized signaling messages for the case that a (small) percentage of messages get lost, i. e., head-of-line blocking effects occur. We have studied this effect both for TCP and SCTP with Linux kernel 2.6.15, and we have compared the measurement results to the theoretical optimum. We found that using ABC in Linux TCP results in significantly higher latencies. Some of our findings can be found in the following presentation from IEEE Globecom 2006: http://www.ikr.uni-stuttgart.de/~scharf/globecom2006_scharf_kiesel.pdf Details on the theoretical model can be found in the corresponding paper: Michael Scharf, Sebastian Kiesel: "Head-of-Line Blocking in TCP and SCTP: Analysis and Measurements", Proc. IEEE Globecom, Nov. 2006 Note that TCP performs significantly worse than SCTP in our setup. Best regards, Michael Scharf and Sebastian Kiesel _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 04 11:47:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VkB-0002QF-JH; Thu, 04 Jan 2007 11:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VkA-0002QA-Jz for tcpm@ietf.org; Thu, 04 Jan 2007 11:47:06 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Vk9-00027T-3R for tcpm@ietf.org; Thu, 04 Jan 2007 11:47:06 -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 l04Gj5Ah011840; Thu, 4 Jan 2007 18:45:35 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 18:44:34 +0200 Received: from esdhcp039125.research.nokia.com ([172.21.39.125]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Jan 2007 18:44:34 +0200 Subject: Re: [tcpm] spurious timeout reaction From: Pasi Sarolahti To: mallman@icir.org In-Reply-To: <20061215200029.EC7E3152828@lawyers.icir.org> References: <20061215200029.EC7E3152828@lawyers.icir.org> Organization: Nokia Research Center Date: Thu, 04 Jan 2007 18:40:34 +0200 Message-Id: <1167928834.22196.133.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 04 Jan 2007 16:44:34.0401 (UTC) FILETIME=[9D44F510:01C7301F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Ethan Blanton , tcpm@ietf.org, Ted Faber , Josh Blanton 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="===============1388743823==" Errors-To: tcpm-bounces@ietf.org --===============1388743823== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KLIYHCF1hMbREpjjL7OT" --=-KLIYHCF1hMbREpjjL7OT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-12-15 at 15:00 -0500, ext Mark Allman wrote: > We think the document is in decent shape and that it might make a good > standards track mechanism for reacting to spurious timeouts. The basic > idea is that we say a TCP MAY make the RTO estimate more conservative in > the face of spurious timeouts with the hopes of avoiding future > timeouts. In particular, we believe that since RFC2988 explicitly > allows a TCP to be more conservative than the estimator given in that > RFC that this reaction is already allowed and a stack using it would be > considered compliant. Wouldn't it be better to make this Experimental at first, like the other related RFCs are? I have to say I'm (still) somewhat unconvinced about this scheme. If one link on the path is having delay spikes, it does not make the other links any less likely to have loss patterns that cause legitimate timeouts. Also, a wireless host that suffers from delay spikes can also suffer from wireless packet losses that may cause legitimate timeouts (that are not an indication of congestion) -- for example in a case where a wireless host is able to use both Wireless LAN (RTTs of about few milliseconds) and GPRS (RTTs in the range of 500 - 1000 ms + occasional delay spikes) links, which is a fairly common case in the recent mobile terminals. When a host is getting to the edge of the wireless LAN coverage, it starts suffering from packet losses that could easily cause a timeout before the host gets a new access interface up and running. On the other hand, while using the GPRS interface the same TCP connection can suffer from delay spikes. So I don't think that delay spikes and legitimate timeouts during the same TCP connection are necessarily as unlikely phenomenon as Section 4 on the disadvantages indicates (with a note that a legitimate RTO is not necessarily a signal of bad congestion, like the text says -- it could be an indication of loss of entire window on a WLAN link that just got out of coverage, or loss of a retransmission). I was also wondering about the dynamics of K' in the above case, because hand-off to a high-latency link can also cause a spurious timeout. Consider a host using WLAN for a while, so that the SRTT becomes around 5-10 ms and RTTVAR a few ms. Then the host moves to use GPRS where the RTT is around 500-1000 ms and RTTVAR would maybe be in the ballpark of 100 ms. If the first RTT sample on the GPRS link is a longer one (as it often is), the following scenario could be possible K' =3D ceil ((R' - SRTT_prev) / RTTVAR_prev) could make ceil ((1000 - 10) / 3) =3D 330 and after a while on the GPRS link the RTO would be around RTO <- SRTT + max (G, K*RTTVAR), that could make (with an example SRTT of 700 ms) 700 ms + max (G, 330 * 100 ms) =3D 33700 ms (did I get everything right above?) So I believe there are possible real-world scenarios where this scheme could kill the RTO performance, which is another reason why I would prefer this becoming Experimental rather than Standards Track. - Pasi --=-KLIYHCF1hMbREpjjL7OT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFnS4CoNa7NH1G2csRAhxnAKD4wL8GHtkHxKzgp81M0/qdbcPOHQCfTwHk +J1mumzIuYSWBptvl/Xi0gY= =7+z7 -----END PGP SIGNATURE----- --=-KLIYHCF1hMbREpjjL7OT-- --===============1388743823== 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 --===============1388743823==-- From tcpm-bounces@ietf.org Thu Jan 04 17:42:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bI7-0001lx-Jh; Thu, 04 Jan 2007 17:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bI1-0001eH-PT for tcpm@ietf.org; Thu, 04 Jan 2007 17:42:25 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bH7-00052x-1V for tcpm@ietf.org; Thu, 04 Jan 2007 17:41:30 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l04Mf3X8014802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jan 2007 14:41:03 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l04Mf35c045881; Thu, 4 Jan 2007 14:41:03 -0800 (PST) (envelope-from faber) Date: Thu, 4 Jan 2007 14:41:03 -0800 From: Ted Faber To: Stephen Hemminger Subject: Re: [tcpm] encouraging wider participation Message-ID: <20070104224103.GF85755@hut.isi.edu> References: <20061122103922.6aefdda1@freekitty> <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.com> <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> <20061127212724.GC45754@hut.isi.edu> <20070103165343.2e79d7c0@freekitty> Mime-Version: 1.0 In-Reply-To: <20070103165343.2e79d7c0@freekitty> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0386449149==" Errors-To: tcpm-bounces@ietf.org --===============0386449149== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CXFpZVxO6m2Ol4tQ" Content-Disposition: inline --CXFpZVxO6m2Ol4tQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 03, 2007 at 04:53:43PM -0800, Stephen Hemminger wrote: > On Mon, 27 Nov 2006 13:27:24 -0800 > Ted Faber wrote: > > On Mon, Nov 27, 2006 at 02:31:52AM -0300, Fernando Gont wrote: > > > I'd argue that, if anything, somebody from each major open source OS= =20 > > > should be sent to the IETF meetings. That way, they could share their= =20 > > > implementation/real-world experience in the meetings. > >=20 > > Make it so. > >=20 > > (See the problem?) >=20 > Several core networking developers already go to IETF meetings. > Jamal Hadi Salam who worked on Traffic Control, and Yoshifuji from Linux = IPV6 > project attends as well. I believe that OS network implementors attend. I intended to point out that *compelling* that participation is problematic at best. It's the "should be sent" that's hard to make so. :-) --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --CXFpZVxO6m2Ol4tQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFnYJ+aUz3f+Zf+XsRAkktAJ9NqHYxlEOeIdLFrRAxk2bI5W1DyQCg08E7 r4E+ITyD08vyjRT9CNyNKoU= =opiX -----END PGP SIGNATURE----- --CXFpZVxO6m2Ol4tQ-- --===============0386449149== 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 --===============0386449149==-- From tcpm-bounces@ietf.org Thu Jan 04 22:31:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2fmf-0002CJ-16; Thu, 04 Jan 2007 22:30:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2fme-0002CD-Ho for tcpm@ietf.org; Thu, 04 Jan 2007 22:30:20 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2fmd-0006Dl-5a for tcpm@ietf.org; Thu, 04 Jan 2007 22:30:20 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0A529F0C3F0; Fri, 5 Jan 2007 00:30:16 -0300 (ART) Received: from fgont.gont.com.ar (46-162-231-201.fibertel.com.ar [201.231.162.46]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l053UCao002332; Fri, 5 Jan 2007 00:30:12 -0300 Message-Id: <7.0.1.0.0.20070104232436.05a8b680@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 04 Jan 2007 23:31:12 -0300 To: Ted Faber , Stephen Hemminger From: Fernando Gont Subject: Re: [tcpm] encouraging wider participation In-Reply-To: <20070104224103.GF85755@hut.isi.edu> References: <20061122103922.6aefdda1@freekitty> <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.com> <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> <20061127212724.GC45754@hut.isi.edu> <20070103165343.2e79d7c0@freekitty> <20070104224103.GF85755@hut.isi.edu> 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-2.0.2 (venus.xmundo.net [201.216.232.56]); Fri, 05 Jan 2007 00:30:14 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At 19:41 04/01/2007, Ted Faber wrote: > > Several core networking developers already go to IETF meetings. > > Jamal Hadi Salam who worked on Traffic Control, and Yoshifuji > from Linux IPV6 > > project attends as well. > >I believe that OS network implementors attend. I intended to point out >that *compelling* that participation is problematic at best. It's the >"should be sent" that's hard to make so. :-) IMHO, the main reason for which many implementers don't come to (or actively participate in) the IETF is because participation usually leads into electro-political discussions. I have seen many instances in which pretty straightforward stuff leads to endless discussions. A current thread in the IETF list is one example. Discussions we have had here during the last couple of years is just another. So it's really hard to come to the IETF, and at the same time be productive for the OS in which you work on. And, when you read claims that "if you implement X, and it's not in the RFCs, it's a bug", you get even more reasons for doing the above. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 05 13:36:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tuq-0005R0-HM; Fri, 05 Jan 2007 13:35:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tup-0005Qn-QQ for tcpm@ietf.org; Fri, 05 Jan 2007 13:35:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tum-0006hi-Dt for tcpm@ietf.org; Fri, 05 Jan 2007 13:35:43 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2007 10:35:40 -0800 X-IronPort-AV: i="4.13,154,1167638400"; d="scan'208"; a="455436398:sNHT48903788" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l05IZd4a024976; Fri, 5 Jan 2007 10:35:39 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05IZUZP000999; Fri, 5 Jan 2007 10:35:39 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 10:35:34 -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] encouraging wider participation Date: Fri, 5 Jan 2007 10:35:32 -0800 Message-ID: <13D1EAB852BE194C94773A947138483D02DB239E@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] encouraging wider participation Thread-Index: AccwegpWMKpmdfK4Q8euLTfMXcb5TgAfRPIA From: "Mitesh Dalal \(mdalal\)" To: "Fernando Gont" X-OriginalArrivalTime: 05 Jan 2007 18:35:34.0589 (UTC) FILETIME=[4976BED0:01C730F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1859; t=1168022139; x=1168886139; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20\(mdalal\)=22=20 |Subject:=20RE=3A=20[tcpm]=20encouraging=20wider=20participation |Sender:=20; bh=NOvGR77KYe6nq5Wdqi9hU/Q3AEooPtCEk+EZL9JO1wU=; b=b+UpUa1zy7MrqZlKGwWoDNoHveh1odvyLbCNKyRDTg3yUGZT954DNE/+4IUGyJZqCKq4AcPi p45EHqHhXCx6rLVfsDPz5kKIoK/NhxlK+Jkhhed/pgbCdoVm8b89PBSw; Authentication-Results: sj-dkim-1; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 well said Fernando! analysis paralysis is the name of the game! =20 > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Thursday, January 04, 2007 6:31 PM > To: Ted Faber; Stephen Hemminger > Cc: tcpm@ietf.org > Subject: Re: [tcpm] encouraging wider participation >=20 > At 19:41 04/01/2007, Ted Faber wrote: >=20 > > > Several core networking developers already go to IETF meetings. > > > Jamal Hadi Salam who worked on Traffic Control, and Yoshifuji > > from Linux IPV6 > > > project attends as well. > > > >I believe that OS network implementors attend. I intended=20 > to point out=20 > >that *compelling* that participation is problematic at best.=20 > It's the=20 > >"should be sent" that's hard to make so. :-) >=20 > IMHO, the main reason for which many implementers don't come=20 > to (or actively participate in) the IETF is because=20 > participation usually leads into electro-political discussions. >=20 > I have seen many instances in which pretty straightforward=20 > stuff leads to endless discussions. > A current thread in the IETF list is one example. Discussions=20 > we have had here during the last couple of years is just another. > So it's really hard to come to the IETF, and at the same time=20 > be productive for the OS in which you work on. >=20 > And, when you read claims that "if you implement X, and it's=20 > not in the RFCs, it's a bug", you get even more reasons for=20 > doing the above. >=20 > Kindest regards, >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP=20 > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 08 10:31:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wS0-000077-IT; Mon, 08 Jan 2007 10:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wRz-00006j-82 for tcpm@ietf.org; Mon, 08 Jan 2007 10:30:15 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wRy-0000P9-LS for tcpm@ietf.org; Mon, 08 Jan 2007 10:30:15 -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 l08FTuUu024011; Mon, 8 Jan 2007 07:29:56 -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 F06DA6807EE; Mon, 8 Jan 2007 10:31:54 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1759815E929; Mon, 8 Jan 2007 10:28:57 -0500 (EST) To: Pasi Sarolahti From: Mark Allman Subject: Re: [tcpm] spurious timeout reaction In-Reply-To: <1167928834.22196.133.camel@siddha.research.nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Entertainer MIME-Version: 1.0 Date: Mon, 08 Jan 2007 10:28:57 -0500 Message-Id: <20070108152857.1759815E929@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Ethan Blanton , tcpm@ietf.org, Ted Faber , Josh Blanton 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="===============1669969934==" Errors-To: tcpm-bounces@ietf.org --===============1669969934== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Pasi- Thanks for the note. Some thoughts ... > On Fri, 2006-12-15 at 15:00 -0500, ext Mark Allman wrote: > > We think the document is in decent shape and that it might make a > > good standards track mechanism for reacting to spurious timeouts. > > The basic idea is that we say a TCP MAY make the RTO estimate more > > conservative in the face of spurious timeouts with the hopes of > > avoiding future timeouts. In particular, we believe that since > > RFC2988 explicitly allows a TCP to be more conservative than the > > estimator given in that RFC that this reaction is already allowed > > and a stack using it would be considered compliant. > > Wouldn't it be better to make this Experimental at first, like the > other related RFCs are? IMO, no. I have a few reasons for that opinion: (1) As noted above, nothing we suggest in this document would make a TCP non-conformant with RFC 2988. So, as far as I am concerned RFC or not this change could be implemented by a stack today and nobody could complain about it. (2) This change would not be a MUST. That is, implementers could use this scheme or not. (3) I think we are way too conservative with the "PS" designation. We seem to have this feeling that everything needs a run at experimental first without any real reason. Some things certainly should take a spin there. And, where the line should be is clearly fuzzy. I would personally draw it differently than the community has drawn it. (4) The change is not overall hurtful to the network. > If one link on the path is having delay spikes, it does not make the > other links any less likely to have loss patterns that cause > legitimate timeouts. Also, a wireless host that suffers from delay > spikes can also suffer from wireless packet losses that may cause > legitimate timeouts (that are not an indication of congestion) -- for > example in a case where a wireless host is able to use both Wireless > LAN (RTTs of about few milliseconds) and GPRS (RTTs in the range of > 500 - 1000 ms + occasional delay spikes) links, which is a fairly > common case in the recent mobile terminals. When a host is getting to > the edge of the wireless LAN coverage, it starts suffering from packet > losses that could easily cause a timeout before the host gets a new > access interface up and running. On the other hand, while using the > GPRS interface the same TCP connection can suffer from delay spikes. I understand that we can think about scenarios where anything can cause problems. And, it is not my goal to cause problems here, of course. But, I really have to wonder about all this and how much of it is *real* and how much of it is just *possible*. (And, even for things that are real one also wonders about the prevalence. Seemingly every corner case happens sometimes or somewhere, but I am not sure that should drive our engineering.) We explicitly added a bit to the document that says one could not use K' when the connection would be for sure in the regime where it would be using the RTO for all loss recovery. I guess it is not clear to me what these other scenarios are that really dictate the use of the RTO. We know how to do pretty robust loss recovery without relying on the RTO. And, recall that by increasing the K we are avoiding spurious timeouts that ultimately collapse the window, cause some go-back-N and generally do not help connection performance at all. > So I don't think that delay spikes and legitimate timeouts during the > same TCP connection are necessarily as unlikely phenomenon as Section > 4 on the disadvantages indicates (with a note that a legitimate RTO is > not necessarily a signal of bad congestion, like the text says -- it > could be an indication of loss of entire window on a WLAN link that > just got out of coverage, or loss of a retransmission). Losing an entire window is bad congestion. I understand that is not what you meant to convey. But, the thing is .... loss == congestion is the assumption built into TCP. So, when the assumption is busted things break. I am not sure that our particular technique can or should be held up because the underlying assumption sometimes does not hold. (Also note that I am not saying it is ideal that we assume loss == congestion. Clearly it is not. And, clearly work on changing this is useful. I am just saying that is the current situation and that I do not buy 'the assumption is busted' as a really great argument against what we said in our document.) > I was also wondering about the dynamics of K' in the above case, > because hand-off to a high-latency link can also cause a spurious > timeout. Consider a host using WLAN for a while, so that the SRTT > becomes around 5-10 ms and RTTVAR a few ms. Then the host moves to use > GPRS where the RTT is around 500-1000 ms and RTTVAR would maybe be in > the ballpark of 100 ms. If the first RTT sample on the GPRS link is a > longer one (as it often is), the following scenario could be possible > > K' = ceil ((R' - SRTT_prev) / RTTVAR_prev) > could make > ceil ((1000 - 10) / 3) = 330 > > and after a while on the GPRS link the RTO would be around > RTO <- SRTT + max (G, K*RTTVAR), that could make (with an example SRTT > of 700 ms) > 700 ms + max (G, 330 * 100 ms) = 33700 ms > > (did I get everything right above?) Before coffee this looks mostly right. If one thinks the RTO min is being used then the numbers above might not cause a spurious RTO. But, if one increased the spike a little then I think the argument makes sense. One point is that if you ever dropped back to the WLAN you'd be protected. (And, per the above, I am not sure I completely buy this case ...) A couple of thoughts ... + The draft could say that a way to decide to use K' would be to first assess the number of RTOs that would be impacted. So, e.g., if a TCP connection never RTOed and then had a spurious RTO because of a delay spike then it might make fine sense to use the K'. On the other hand, if the spurious RTO was one 1 out of 100 RTOs and the K' ended up big (as above) then the TCP might decide to just not use the K'. The problem is how to do the fuzzy middle of this space. I am not saying that we'd have to work out some scheme to do this. I am just wondering if, since this is not presented to be mandatory, whether we can add a little bit of explicit wiggle room for implementers. + We could keep the fundamental notion that the RTO estimation has failed, but change the particulars of how we cope. Right now we make the argument that delay spikes that cause spurious RTOs indicate that the variance estimator is not coping with the variance in the RTT all that well. I think that is a reasonable line of thinking. But, what if we decided that the variance component was not supposed to catch delay spikes and added another term to catch these things if we experienced any that caused spurious timeouts? So, if we have an R' from a spurious timeout and an RTO_prev, we could do something like this: DS = R' - RTO RTO = SRTT + max (G, K*RTTVAR) + DS (which is the formula from RFC2988 with "+ DS" added) Would that give us the same amount of protection without giving a multiplicative effect that balloons the RTO to ridiculousness? + Also, there are schemes floating around that would essentially re-init all the CC parameters on network change. It seems that it might be useful to include any K' in that re-initialization such that the above case does not happen. That is, when we can explain the delay spike and take a different approach to ensure that spurious RTOs are not repeated then we don't have to kludge up the RTO to try to cope. It is only when we cannot explain the delay spike that we try to cope using the RTO. Make any sense? Further thoughts? Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFomM4WyrrWs4yIs4RAjf/AJ0Q2BO4X8wyJbkMItTybgluPi6rrQCgg7Qd wW4+3ANSEay02dMMX9oCzRA= =69ub -----END PGP SIGNATURE----- --=_bOundary-- --===============1669969934== 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 --===============1669969934==-- From tcpm-bounces@ietf.org Mon Jan 08 11:50:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xhp-0005GX-Ah; Mon, 08 Jan 2007 11:50:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xhn-0005FX-Af for tcpm@ietf.org; Mon, 08 Jan 2007 11:50:39 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3xhj-0001d1-1h for tcpm@ietf.org; Mon, 08 Jan 2007 11:50:39 -0500 Received: from lion.bbn.com ([128.89.80.73]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1H3xhi-0003uP-4g; Mon, 08 Jan 2007 11:50:34 -0500 Message-ID: <45A2765A.5060100@bbn.com> Date: Mon, 08 Jan 2007 11:50:34 -0500 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: eblanton@cs.purdue.edu, jblanton@cs.ohiou.edu, mallman@icir.org Subject: [tcpm] draft-allman-rto-backoff-04.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 Hi, I just re-read the draft more carefully, and I like the approach. I've been thinking that this technique of adjusting K' might be enough to eliminate the special case step (2.4) in RFC 2988. I've always disliked the min RTO = 1 sec rule. I understand why it is there, but the common case on the net seems to usually hit this step. In other words, we do all this work to calculate the RTO to finally find that we have to just set RTO = 1 sec. Any thoughts? -- Armando www.armandocaro.net _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 10 07:43:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cmC-0007qa-LS; Wed, 10 Jan 2007 07:41:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4cmB-0007pv-2N for tcpm@ietf.org; Wed, 10 Jan 2007 07:41:55 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4cmA-0001lp-D5 for tcpm@ietf.org; Wed, 10 Jan 2007 07:41:55 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0ACddaP008730; Wed, 10 Jan 2007 14:39:54 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 14:41:06 +0200 Received: from [172.21.39.125] ([172.21.39.125]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Jan 2007 14:41:06 +0200 Subject: Re: [tcpm] spurious timeout reaction From: Pasi Sarolahti To: mallman@icir.org In-Reply-To: <20070108152857.1759815E929@lawyers.icir.org> References: <20070108152857.1759815E929@lawyers.icir.org> Organization: Nokia Research Center Date: Wed, 10 Jan 2007 14:41:06 +0200 Message-Id: <1168432866.14500.139.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-2.fc6) X-OriginalArrivalTime: 10 Jan 2007 12:41:06.0247 (UTC) FILETIME=[989C0D70:01C734B4] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070110143955-21D6CBB0-5A8B1605/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Ethan Blanton , tcpm@ietf.org, Ted Faber , Josh Blanton 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="===============1901344723==" Errors-To: tcpm-bounces@ietf.org --===============1901344723== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eQeXnll/DPLMNP4EZ+Zd" --=-eQeXnll/DPLMNP4EZ+Zd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable (I'm chopping off the original mail here and there) On Mon, 2007-01-08 at 10:28 -0500, ext Mark Allman wrote:=20 > > Wouldn't it be better to make this Experimental at first, like the > > other related RFCs are? >=20 > IMO, no. >=20 > I have a few reasons for that opinion: >=20 > (1) As noted above, nothing we suggest in this document would make a TCP > non-conformant with RFC 2988. So, as far as I am concerned RFC or > not this change could be implemented by a stack today and nobody > could complain about it. >=20 > (2) This change would not be a MUST. That is, implementers could use > this scheme or not. > > (3) I think we are way too conservative with the "PS" designation. We > seem to have this feeling that everything needs a run at > experimental first without any real reason. Some things certainly > should take a spin there. And, where the line should be is clearly > fuzzy. I would personally draw it differently than the community > has drawn it. Yep, you can say that again... And sometimes it takes time to get even Experimentals through. Speaking of PS, shouldn't the normative references in a PS document also be standards track documents? That would seem logical, at least. In particular, we are missing a spurious timeout detection PS. [...] > I understand that we can think about scenarios where anything can cause > problems. And, it is not my goal to cause problems here, of course. > But, I really have to wonder about all this and how much of it is *real* > and how much of it is just *possible*. (And, even for things that are > real one also wonders about the prevalence. Seemingly every corner case > happens sometimes or somewhere, but I am not sure that should drive our > engineering.)=20 A corner case for you might not be a corner case for me. The WLAN-GPRS example is an existing case from real world, so for some people it is mote than just a corner case. It is quite hard to determine what are the globally typical path characteristics nowadays. > We explicitly added a bit to the document that says one could not use K' > when the connection would be for sure in the regime where it would be > using the RTO for all loss recovery. I guess it is not clear to me what > these other scenarios are that really dictate the use of the RTO. We > know how to do pretty robust loss recovery without relying on the RTO. Because TCP sender is able to detect spurious RTO, it also knows how often genuine RTOs occur, i.e., how typical it is that the normal loss recovery does not work as expected. One possibility could be that when TCP sender detects a genuine RTO, it would reset K' back to the original value. > Losing an entire window is bad congestion. >=20 > I understand that is not what you meant to convey. But, the thing is > .... loss =3D=3D congestion is the assumption built into TCP. So, when t= he > assumption is busted things break. I am not sure that our particular > technique can or should be held up because the underlying assumption > sometimes does not hold. Yep. But even if we assume that genuine RTO is an indication of bad congestion, I'm not sure if we can justify K' as an additional congestion control mechanism. Retransmission timer already has the backoff mechanism that is quite conservative. If the initial RTO estimate was several seconds, with the normal RTO backoff and some bad luck the TCP sender would need to wait for its turn for quite a while. If your neighbor didn't happen to have spurious timeouts, you are in quite bad position in terms of fairness. > A couple of thoughts ... >=20 > + The draft could say that a way to decide to use K' would be to first > assess the number of RTOs that would be impacted. So, e.g., if a > TCP connection never RTOed and then had a spurious RTO because of a > delay spike then it might make fine sense to use the K'. On the > other hand, if the spurious RTO was one 1 out of 100 RTOs and the K' > ended up big (as above) then the TCP might decide to just not use > the K'. The problem is how to do the fuzzy middle of this space. The problem with the statistical methods is that they don't help the short connections. And often the short connections are those where the user can sense and get irritated by the relative effect of an RTO more than in the long transfers. > + We could keep the fundamental notion that the RTO estimation has > failed, but change the particulars of how we cope. =20 >=20 > Right now we make the argument that delay spikes that cause spurious > RTOs indicate that the variance estimator is not coping with the > variance in the RTT all that well. I think that is a reasonable > line of thinking. But, what if we decided that the variance > component was not supposed to catch delay spikes and added another > term to catch these things if we experienced any that caused > spurious timeouts? So, if we have an R' from a spurious timeout and > an RTO_prev, we could do something like this: >=20 > DS =3D R' - RTO > RTO =3D SRTT + max (G, K*RTTVAR) + DS > (which is the formula from RFC2988 with "+ DS" added) >=20 > Would that give us the same amount of protection without giving a > multiplicative effect that balloons the RTO to ridiculousness? This seems better to me. I think it is appropriate to treat a spurious timeout as an exceptional event, rather than a component of the normal RTT variance. > + Also, there are schemes floating around that would essentially > re-init all the CC parameters on network change. It seems that it > might be useful to include any K' in that re-initialization such > that the above case does not happen. That is, when we can explain > the delay spike and take a different approach to ensure that > spurious RTOs are not repeated then we don't have to kludge up the > RTO to try to cope. It is only when we cannot explain the delay > spike that we try to cope using the RTO. Make any sense? Yes, it does. And it could be useful to refer to, for example, the RLCI draft here, maybe with a note that since spurious timeouts have been identified to be a characteristic of some wireless links, it could be worthwhile to consider implementing also RLCI, if this is implemented. - Pasi --=-eQeXnll/DPLMNP4EZ+Zd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFpN7hoNa7NH1G2csRAhDZAKCqLgWwcpf8+lUR4286xY8mQgV8bACdF1qo uQiJwqUW7lqUu96VCd8AZ8w= =ATan -----END PGP SIGNATURE----- --=-eQeXnll/DPLMNP4EZ+Zd-- --===============1901344723== 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 --===============1901344723==-- From tcpm-bounces@ietf.org Wed Jan 10 08:48:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4do8-0003RZ-0p; Wed, 10 Jan 2007 08:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4do6-0003RU-A0 for tcpm@ietf.org; Wed, 10 Jan 2007 08:47:58 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4do1-0002Yx-2b for tcpm@ietf.org; Wed, 10 Jan 2007 08:47:58 -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 l0ADlc0m028710; Wed, 10 Jan 2007 05:47:38 -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 33312692BE6; Wed, 10 Jan 2007 08:49:34 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 64329162DEF; Wed, 10 Jan 2007 08:46:35 -0500 (EST) To: Pasi Sarolahti From: Mark Allman Subject: Re: [tcpm] spurious timeout reaction In-Reply-To: <1168432866.14500.139.camel@siddha.research.nokia.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Pinball Wizard MIME-Version: 1.0 Date: Wed, 10 Jan 2007 08:46:35 -0500 Message-Id: <20070110134635.64329162DEF@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Ethan Blanton , tcpm@ietf.org, Ted Faber , Josh Blanton 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="===============1237616610==" Errors-To: tcpm-bounces@ietf.org --===============1237616610== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Speaking of PS, shouldn't the normative > references in a PS document also be standards track documents? Yes. > That would seem logical, at least. In particular, we are missing a > spurious timeout detection PS. Yes. > A corner case for you might not be a corner case for me. The WLAN-GPRS > example is an existing case from real world, so for some people it is > mote than just a corner case. It is quite hard to determine what are > the globally typical path characteristics nowadays. Of course you are right. So, then how do we engineer things for a network that includes as much heterogeneity as we currently have? > > We explicitly added a bit to the document that says one could not > > use K' when the connection would be for sure in the regime where it > > would be using the RTO for all loss recovery. I guess it is not > > clear to me what these other scenarios are that really dictate the > > use of the RTO. We know how to do pretty robust loss recovery > > without relying on the RTO. > > Because TCP sender is able to detect spurious RTO, it also knows how > often genuine RTOs occur, i.e., how typical it is that the normal loss > recovery does not work as expected. One possibility could be that when > TCP sender detects a genuine RTO, it would reset K' back to the > original value. I don't like this idea or really any idea that collapses K' back down. The issue is that these delay spikes are *unforeseen*. If we could somehow predict that the RTO estimate was going to be too low then we'd clearly do something about it or change the RTO calculation to accommodate the fact that we could see a delay spike coming. But, in the absence of such information all we can do is look to our history about the magnitude of delay spikes. So, after collecting the history, throwing it away seems like a bad idea to me. > > Losing an entire window is bad congestion. > > > > I understand that is not what you meant to convey. But, the thing is > > .... loss == congestion is the assumption built into TCP. So, when the > > assumption is busted things break. I am not sure that our particular > > technique can or should be held up because the underlying assumption > > sometimes does not hold. > > Yep. But even if we assume that genuine RTO is an indication of bad > congestion, I'm not sure if we can justify K' as an additional > congestion control mechanism. Retransmission timer already has the > backoff mechanism that is quite conservative. If the initial RTO > estimate was several seconds, with the normal RTO backoff and some bad > luck the TCP sender would need to wait for its turn for quite a while. > If your neighbor didn't happen to have spurious timeouts, you are in > quite bad position in terms of fairness. I am not quite sure I follow this. K' is not a congestion control mechanism. The RTO is the congestion control mechanism. If you have an increased K (over the standard 4) and are still losing packets and have to backoff the RTO further, you're going to have a hard time convincing me that the increased K is really a big problem. I.e., we're in a bad situation and clearly K' is not a factor. The point of K' is to try to avoid needless timeouts, not to in some what shape a connection's rate or fair hare or whatever. Certainly it may take longer for legit RTOs. But, a connection also may prevent the ill-effects of a needless RTO. > > A couple of thoughts ... > > > > + The draft could say that a way to decide to use K' would be to first > > assess the number of RTOs that would be impacted. So, e.g., if a > > TCP connection never RTOed and then had a spurious RTO because of a > > delay spike then it might make fine sense to use the K'. On the > > other hand, if the spurious RTO was one 1 out of 100 RTOs and the K' > > ended up big (as above) then the TCP might decide to just not use > > the K'. The problem is how to do the fuzzy middle of this space. > > The problem with the statistical methods is that they don't help the > short connections. And often the short connections are those where the > user can sense and get irritated by the relative effect of an RTO more > than in the long transfers. Yep. This technique is clearly for longer-term transfers. (On the other hand, short connections might also always be in the regime the document declares as off-limits for a K'. I.e., a small cwnd.) Thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFpO47WyrrWs4yIs4RAqaiAJ48twyqmE70gMgoqGLk7YHURqgE3QCeMfCZ Q7Ofr1y2NVt2Byd8tm3ee/E= =QCx/ -----END PGP SIGNATURE----- --=_bOundary-- --===============1237616610== 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 --===============1237616610==-- From tcpm-bounces@ietf.org Thu Jan 11 10:58:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52JZ-0000Un-PM; Thu, 11 Jan 2007 10:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H52JY-0000UL-Mv; Thu, 11 Jan 2007 10:58:04 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H52JX-0004LX-B6; Thu, 11 Jan 2007 10:58:04 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 1D25FC275; Thu, 11 Jan 2007 10:58:00 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0BFvumQ007815; Thu, 11 Jan 2007 10:57:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0BFvuUs016666; Thu, 11 Jan 2007 10:57:56 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id krzYsOlfF34d; Thu, 11 Jan 2007 10:57:55 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0BFvsNS016651;Thu, 11 Jan 2007 10:57:54 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id E35F54FE10; Thu, 11 Jan 2007 10:55:41 -0500 (EST) Date: Thu, 11 Jan 2007 10:55:41 -0500 From: Wesley Eddy To: iccrg@cs.ucl.ac.uk, tsvwg@ietf.org, tcpm@ietf.org, tsv-area@ietf.org, dccp@ietf.org, rmt@ietf.org Message-ID: <20070111155541.GA25291@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:65.94000 C:2 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [tcpm] review solicitation for ICCRG congestion control survey X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org In the ICCRG's goal to foster a long-term congestion control architecture for the Internet, its initial step is to understand all of the current mechanisms in use. As an aid to this, the ICCRG is working on a document that summarizes all of the congestion control mechanisms and other guidance that the IETF has produced and published in the RFC series. The initial version of this document is online: http://tools.ietf.org/group/irtf/draft-irtf-iccrg-cc-rfcs-00.txt We think this is a fairly complete listing of the RFCs that relate to congestion control, but if you know of others that should be included, we would like to hear about it. Also, comments on what can be done to make this more useful or readable are welcome. Comments on and improvements to the text summarizing each RFC are also welcome. The goal is to gather these inputs before the ICCRG meeting in mid-February. After the ICCRG meeting, the document will be updated based on these comments and discussion from the meeting. Please send all comments to the ICCRG list (iccrg@cs.ucl.ak.uk). Although this request is being sent to multiple lists, this is only to notify people not on the ICCRG list; we do not want to burden the other mailing lists with replies, so please trim the "to" and "cc" fields of replies. Thanks in advance. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 13:54:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H553v-0005Ub-Fx; Thu, 11 Jan 2007 13:54:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H553u-0005UR-Ep for tcpm@ietf.org; Thu, 11 Jan 2007 13:54:06 -0500 Received: from smtp.osdl.org ([65.172.181.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H553o-0002Cj-Ll for tcpm@ietf.org; Thu, 11 Jan 2007 13:54:06 -0500 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l0BIrnWi000860 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 11 Jan 2007 10:53:49 -0800 Received: from freekitty (freekitty.pdx.osdl.net [10.8.0.54]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id l0BIrnjt032475; Thu, 11 Jan 2007 10:53:49 -0800 Date: Thu, 11 Jan 2007 10:53:48 -0800 From: Stephen Hemminger To: tcpm@ietf.org Message-ID: <20070111105348.546de25e@freekitty> Organization: OSDL X-Mailer: Sylpheed-Claws 2.5.0-rc3 (GTK+ 2.10.6; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.182 required=5 tests=AWL X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.107__ X-MIMEDefang-Filter: osdl$Revision: 1.167 $ X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: david.malone@nuim.ie Subject: [tcpm] DoS attack from misbehaving receivers 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 Has anyone in this group explored the problems described in: "Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse"? http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf http://www.cs.umd.edu/~capveg/ http://www.kb.cert.org/vuls/id/102014 A possible solution (optack) is described in the paper that involves the sender randomly skipping segments and resetting connections that ACK data that was never sent. But it is not clear that the impacts of such a change have been fully investigated. Comments? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 14:22:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55Vj-00087W-S4; Thu, 11 Jan 2007 14:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55Vj-00087R-IH for tcpm@ietf.org; Thu, 11 Jan 2007 14:22:51 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H55Vi-000141-35 for tcpm@ietf.org; Thu, 11 Jan 2007 14:22:51 -0500 Received: from [127.0.0.1] ([128.9.176.75]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0BJMOGB014758; Thu, 11 Jan 2007 11:22:26 -0800 (PST) Message-ID: <45A68E6D.5050303@isi.edu> Date: Thu, 11 Jan 2007 11:22:21 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Stephen Hemminger Subject: Re: [tcpm] DoS attack from misbehaving receivers References: <20070111105348.546de25e@freekitty> In-Reply-To: <20070111105348.546de25e@freekitty> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: david.malone@nuim.ie, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688988792==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0688988792== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB879846CCAE0BBC6FFB8145C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB879846CCAE0BBC6FFB8145C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stephen Hemminger wrote: > Has anyone in this group explored the problems described in: > "Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse"= ? >=20 > http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf > http://www.cs.umd.edu/~capveg/ > http://www.kb.cert.org/vuls/id/102014 >=20 > A possible solution (optack) is described in the paper that involves th= e > sender randomly skipping segments and resetting connections that > ACK data that was never sent. But it is not clear that the impacts > of such a change have been fully investigated. There's very little in TCP that is intended to work well with a byzantine receiver. Except for our security protocols, very little of the Internet deals well with them either. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigB879846CCAE0BBC6FFB8145C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpo5tE5f5cImnZrsRAs67AKDyL6DXwO/ZPosPO5uEJQpmRjX72QCg91dm 1eVdBk5/xjCDF7fFdv4OCJc= =G+2J -----END PGP SIGNATURE----- --------------enigB879846CCAE0BBC6FFB8145C-- --===============0688988792== 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 --===============0688988792==-- From tcpm-bounces@ietf.org Thu Jan 11 15:05:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56Ao-0005ys-Oo; Thu, 11 Jan 2007 15:05:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56An-0005ye-GQ for tcpm@ietf.org; Thu, 11 Jan 2007 15:05:17 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56Am-00041Y-4M for tcpm@ietf.org; Thu, 11 Jan 2007 15:05:17 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 11 Jan 2007 12:02:19 -0800 X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 83E1B2AF; Thu, 11 Jan 2007 12:02:19 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5C7342AE; Thu, 11 Jan 2007 12:02:19 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ETE57324; Thu, 11 Jan 2007 12:01:28 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 9B4D920502; Thu, 11 Jan 2007 12:01:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] DoS attack from misbehaving receivers Date: Thu, 11 Jan 2007 12:00:59 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1EE6E3A@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20070111105348.546de25e@freekitty> Thread-Topic: [tcpm] DoS attack from misbehaving receivers Thread-Index: Acc1sfgl/tcq6oX2TC2xki56IGehMAACHGTw From: "Caitlin Bestler" To: "Stephen Hemminger" , tcpm@ietf.org X-WSS-ID: 69B848412CC19647350-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: david.malone@nuim.ie 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 Stephen Hemminger wrote: > Has anyone in this group explored the problems described in: > "Misbehaving TCP Receivers Can Cause Internet-Wide Congestion > Collapse"?=20 >=20 > http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf > http://www.cs.umd.edu/~capveg/ > http://www.kb.cert.org/vuls/id/102014 >=20 > A possible solution (optack) is described in the paper that > involves the sender randomly skipping segments and resetting > connections that ACK data that was never sent. But it is not > clear that the impacts of such a change have been fully investigated. >=20 > Comments? >=20 The proposed test for a non-compliant receiver would seem to require that the sender be non-compliant itself. For many of the applications cited, wouldn't a more general solution be to apply connection-specific rate limiters at the sender (in the stack or at the application layer)? Even if one client could truly receive at full line rate, is is truly wise at the application layer to agree to give all of your capacity to one client when hundreds or thousands of clients are anticipated? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 16:00:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H571L-0000Oq-Kf; Thu, 11 Jan 2007 15:59:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H571K-0000Ob-Bo for tcpm@ietf.org; Thu, 11 Jan 2007 15:59:34 -0500 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H571E-0001tx-8T for tcpm@ietf.org; Thu, 11 Jan 2007 15:59:34 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 11 Jan 2007 12:59:12 -0800 X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A0E022AF; Thu, 11 Jan 2007 12:59:12 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7C5DF2AE; Thu, 11 Jan 2007 12:59:12 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ETE74774; Thu, 11 Jan 2007 12:59:11 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 2BBC620501; Thu, 11 Jan 2007 12:59:11 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] DoS attack from misbehaving receivers Date: Thu, 11 Jan 2007 12:59:10 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20070111202843.GL2944@loompa.cs.umd.edu> Thread-Topic: [tcpm] DoS attack from misbehaving receivers Thread-Index: Acc1vyb1fHEnyjCSTvqGmKsYeUMr2gAAsW6Q From: "Caitlin Bestler" To: "Rob Sherwood" X-WSS-ID: 69B87AAA3EK19030157-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: david.malone@nuim.ie, 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 Rob Sherwood wrote: > I guess I should probably jump in here somewhere :-) >=20 > On Thu, Jan 11, 2007 at 12:00:59PM -0800, Caitlin Bestler wrote: >> The proposed test for a non-compliant receiver would seem to require >> that the sender be non-compliant itself. >=20 > I'm not sure I understand this comment. Part of the utility > of the solution is that unmodified receivers can communicate > with senders that randomly skip segments, because segment > reordering and dropping is already handled by TCP. >=20 Having the sender skip segments will indeed detect a non-compliant receiver that acks segments that were never sent. But sending non-contiguous TCP segments is itself not compliant. >=20 >> For many of the applications cited, wouldn't a more general solution >> be to apply connection-specific rate limiters at the sender (in the >> stack or at the application layer)? >=20 > As mentioned in the paper, rate limiting does not prevent the attack. > The attack is for many servers to send a small amount of TCP > unfriendly traffic into the network, which results in > significant traffic in aggregate. Reducing the rate of > traffic at any one server only causes the attacker to target > more servers. >=20 You can generate a large amount of traffic simply sending small requests that generate large responses and then bit-bucketing the results. If you are doing so from a botnet you can even actually receive all of the segments in the distributed clients before dropping the segments. Before endorsing a counter-measure that calls for what was previously non-compliant behavior there should be a showing that the problem being solved is indeed severe and unique. If my understanding is correct, the problem is that an attacker can simulate reception of more material than their actual local link can support, and thereby trick a large group of senders into saturating *their* local links and/or intermediate segments. But is it not correct that the same attack could be launched from a botnet just as effectively even without faking acks? Until typical home computers are more secure from being drafted into a botnet is there a real benefit from this counter-measure? Having transmitters engage in non-compliant behavour in order to catch cheaters is a slippery slope best avoided. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 16:27:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57SZ-0008TQ-Ow; Thu, 11 Jan 2007 16:27:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57SY-0008TC-8a for tcpm@ietf.org; Thu, 11 Jan 2007 16:27:42 -0500 Received: from flyer.cs.umd.edu ([128.8.128.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57SX-0007gG-1o for tcpm@ietf.org; Thu, 11 Jan 2007 16:27:42 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by flyer.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l0BLRbCH006116; Thu, 11 Jan 2007 16:27:37 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l0BLRXnW023894; Thu, 11 Jan 2007 16:27:33 -0500 (EST) Date: Thu, 11 Jan 2007 16:27:32 -0500 From: Rob Sherwood To: Caitlin Bestler Subject: Re: [tcpm] DoS attack from misbehaving receivers Message-ID: <20070111212732.GM2944@loompa.cs.umd.edu> References: <20070111202843.GL2944@loompa.cs.umd.edu> <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org, david.malone@nuim.ie 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 > Before endorsing a counter-measure that calls for what was > previously non-compliant behavior there should be a showing > that the problem being solved is indeed severe and unique. Agreed. This is the crux of the discussion: is this attack severe enough to motivate the admittedly invasive change to the TCP stack. > If my understanding is correct, the problem is that an attacker > can simulate reception of more material than their actual local > link can support, and thereby trick a large group of senders > into saturating *their* local links and/or intermediate segments. This is mostly correct. The true concern is that *backbone* links, not just local links, will be saturated, bringing about, as the title suggests, Internet-wide congestion collapse. It is this concern that I feel motivates the need to change the specification. > But is it not correct that the same attack could be launched > from a botnet just as effectively even without faking acks? > Until typical home computers are more secure from being drafted > into a botnet is there a real benefit from this counter-measure? A botnet of sufficient size, maybe. An open question (read: subject of my current research) is how much traffic is required to overcome Internet backbone links. The reason for concern with the OptAck attack is that the amplification factors are large (~1600x and higher from the paper), which reduces the size of the botnet required to cause significant damage. For example, if a 100,000 node botnet has sufficient bandwidth to overwhelm backbone links without OptAck, then a 60 node botnet can overwhelm the network with OptAck. I believe that there is a qualitative difference between these two attacks in terms of attacker capability, i.e., it takes significantly more work to compromise 100K machines then 60. > Having transmitters engage in non-compliant behavour in order > to catch cheaters is a slippery slope best avoided. In general I agree, but I believe that the danger here is significant to warrant futher consideration. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 16:29:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57U6-0001TM-By; Thu, 11 Jan 2007 16:29:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57U4-0001Qd-Vj for tcpm@ietf.org; Thu, 11 Jan 2007 16:29:16 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57U3-0008RY-FZ for tcpm@ietf.org; Thu, 11 Jan 2007 16:29:16 -0500 Received: from [127.0.0.1] ([128.9.176.75]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0BLSe77021307; Thu, 11 Jan 2007 13:28:43 -0800 (PST) Message-ID: <45A6AC06.2030402@isi.edu> Date: Thu, 11 Jan 2007 13:28:38 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] DoS attack from misbehaving receivers References: <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: david.malone@nuim.ie, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0587280065==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0587280065== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E401285E45548C8AD8362CC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E401285E45548C8AD8362CC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: > Rob Sherwood wrote: >> I guess I should probably jump in here somewhere :-) >> >> On Thu, Jan 11, 2007 at 12:00:59PM -0800, Caitlin Bestler wrote: >>> The proposed test for a non-compliant receiver would seem to require >>> that the sender be non-compliant itself. >> I'm not sure I understand this comment. Part of the utility >> of the solution is that unmodified receivers can communicate >> with senders that randomly skip segments, because segment >> reordering and dropping is already handled by TCP. >=20 > Having the sender skip segments will indeed detect a non-compliant > receiver that acks segments that were never sent. But sending > non-contiguous TCP segments is itself not compliant. Technically, that's equivalent to losing or reordering segments. As long as you can't tell the difference from the receiver's point of view, why is this not compliant? Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig7E401285E45548C8AD8362CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpqwGE5f5cImnZrsRAriZAKD46MqVIHMFHYFwFVNaX7SlaHC+igCgvU5U bhyBVDRUUP5E0cfUlaIDYn0= =b2nD -----END PGP SIGNATURE----- --------------enig7E401285E45548C8AD8362CC-- --===============0587280065== 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 --===============0587280065==-- From tcpm-bounces@ietf.org Thu Jan 11 16:37:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57bp-0000tD-P7; Thu, 11 Jan 2007 16:37:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57bo-0000nm-Bx for tcpm@ietf.org; Thu, 11 Jan 2007 16:37:16 -0500 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57bm-0002bE-Py for tcpm@ietf.org; Thu, 11 Jan 2007 16:37:16 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 11 Jan 2007 13:37:03 -0800 X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 065ED2B0; Thu, 11 Jan 2007 13:37:03 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D5F8C2AF; Thu, 11 Jan 2007 13:37:02 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ETE84549; Thu, 11 Jan 2007 13:37:01 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 09E8E20501; Thu, 11 Jan 2007 13:37:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] DoS attack from misbehaving receivers Date: Thu, 11 Jan 2007 13:37:00 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1EE6E61@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <45A6AC06.2030402@isi.edu> Thread-Topic: [tcpm] DoS attack from misbehaving receivers Thread-Index: Acc1x5Bk782TQQt0Qvuag0pyp4s6iwAAFuTA From: "Caitlin Bestler" To: "Joe Touch" X-WSS-ID: 69B872753EK19043549-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: david.malone@nuim.ie, 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 Joe Touch wrote: > Caitlin Bestler wrote: >> Rob Sherwood wrote: >>> I guess I should probably jump in here somewhere :-) >>>=20 >>> On Thu, Jan 11, 2007 at 12:00:59PM -0800, Caitlin Bestler wrote: >>>> The proposed test for a non-compliant receiver would seem to >>>> require that the sender be non-compliant itself. >>> I'm not sure I understand this comment. Part of the utility of the >>> solution is that unmodified receivers can communicate with senders >>> that randomly skip segments, because segment reordering and dropping >>> is already handled by TCP. >>=20 >> Having the sender skip segments will indeed detect a non-compliant >> receiver that acks segments that were never sent. But sending >> non-contiguous TCP segments is itself not compliant. >=20 > Technically, that's equivalent to losing or reordering > segments. As long as you can't tell the difference from the > receiver's point of view, why is this not compliant? >=20 > Joe There's a difference between L3 or L2 dropping a segment because a queue was full and L4 simply not generating it. Granted, there is no method to prove the difference when observing from the other end of the network, but that still isn't a reason to bless generation of non-compliant TCP streams. A TCP connection is supposed to be a peer-to-peer relationship. Once you start playing liar's poker to try to trip up the other end things are going to get messy very quickly. What if receivers started doing things to try to detect sender's who were sending out of order? Be paranoid in what you accept and devious in what you send? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 16:46:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57kF-0000Te-H5; Thu, 11 Jan 2007 16:45:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57kD-0000SJ-SD for tcpm@ietf.org; Thu, 11 Jan 2007 16:45:57 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57k9-00050w-Uj for tcpm@ietf.org; Thu, 11 Jan 2007 16:45:57 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 11 Jan 2007 13:45:53 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.24; Thu, 11 Jan 2007 13:45:52 -0800 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Thu, 11 Jan 2007 13:45:51 -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] DoS attack from misbehaving receivers Date: Thu, 11 Jan 2007 13:45:13 -0800 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064033D11F3@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <20070111212732.GM2944@loompa.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [tcpm] DoS attack from misbehaving receivers thread-index: Acc1x2Z4n0KpUVD1QUii7KCnoXdMJwAAWAoA References: <20070111202843.GL2944@loompa.cs.umd.edu><54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> <20070111212732.GM2944@loompa.cs.umd.edu> From: Christian Huitema To: Rob Sherwood , Caitlin Bestler X-OriginalArrivalTime: 11 Jan 2007 21:45:51.0548 (UTC) FILETIME=[DCFAEFC0:01C735C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: david.malone@nuim.ie, 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 > > But is it not correct that the same attack could be launched > > from a botnet just as effectively even without faking acks? > > Until typical home computers are more secure from being drafted > > into a botnet is there a real benefit from this counter-measure? >=20 > A botnet of sufficient size, maybe. An open question (read: subject of > my current research) is how much traffic is required to overcome > Internet > backbone links. The reason for concern with the OptAck attack is that > the amplification factors are large (~1600x and higher from the paper), > which reduces the size of the botnet required to cause significant > damage. I have witnessed distributed DOS attacks generating several Gbps of traffic, and that was a couple of years ago. I have also witnessed DOS attacks implemented by simply opening multiple TCP connections. The attack software started several threads, and in each thread a loop would keep loading a particular web page. That actually gives a lot of amplification, since the size of the HTTP request is only a fraction of the size of the response. There was no attempt to hide the origin of the attack, spoof the IP address, hack the TCP stack, or any of that. These particular attacks were trying to bring down a web site, but similar attacks could easily target a particular link in the infrastructure. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 17:12:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H589p-0000KE-Bw; Thu, 11 Jan 2007 17:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H589o-0000Is-06 for tcpm@ietf.org; Thu, 11 Jan 2007 17:12:24 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H589m-0003l4-KY for tcpm@ietf.org; Thu, 11 Jan 2007 17:12:23 -0500 Received: from [127.0.0.1] ([128.9.176.75]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0BMC7SW002881; Thu, 11 Jan 2007 14:12:10 -0800 (PST) Message-ID: <45A6B635.30801@isi.edu> Date: Thu, 11 Jan 2007 14:12:05 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] DoS attack from misbehaving receivers References: <54AD0F12E08D1541B826BE97C98F99F1EE6E61@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1EE6E61@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: david.malone@nuim.ie, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2108641758==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2108641758== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD20D57B943425EEB14DDA901" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD20D57B943425EEB14DDA901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: =2E.. >>> Having the sender skip segments will indeed detect a non-compliant >>> receiver that acks segments that were never sent. But sending >>> non-contiguous TCP segments is itself not compliant. >> Technically, that's equivalent to losing or reordering >> segments. As long as you can't tell the difference from the >> receiver's point of view, why is this not compliant? >> >> Joe >=20 > There's a difference between L3 or L2 dropping a segment > because a queue was full and L4 simply not generating it. Not to the receiver! ('goes to intent' - the receiver doesn't know intent). > Granted, there is no method to prove the difference when > observing from the other end of the network, but that still > isn't a reason to bless generation of non-compliant TCP streams. It's not non-compliant to do something that the receiver can't differentiate from legitimate behavior. > A TCP connection is supposed to be a peer-to-peer relationship. > Once you start playing liar's poker to try to trip up the other > end things are going to get messy very quickly. What if receivers > started doing things to try to detect sender's who were sending > out of order? What would you do? You can't punish them, since you can't know whether the network is the cause or not. The better quote might be a version of the (in)famous "don't attribute to malice that which can be attributed to ignorance"; my version here would be: "don't attribute to malice that which can be attributed to entropy" Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigD20D57B943425EEB14DDA901 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFprY1E5f5cImnZrsRAreWAKCFRJQy7UyKUtJ8buQZA46d5V/54QCgx3r3 YKjoaid+v+xLXwPIaxgyGV4= =VD82 -----END PGP SIGNATURE----- --------------enigD20D57B943425EEB14DDA901-- --===============2108641758== 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 --===============2108641758==-- From tcpm-bounces@ietf.org Thu Jan 11 17:15:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Cn-0003kn-C3; Thu, 11 Jan 2007 17:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Cm-0003ja-9K for tcpm@ietf.org; Thu, 11 Jan 2007 17:15:28 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58Cl-0004E2-0a for tcpm@ietf.org; Thu, 11 Jan 2007 17:15:28 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l0BMFPsx006080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jan 2007 17:15:26 -0500 (EST) Message-ID: <45A6B6FC.7020000@psc.edu> Date: Thu, 11 Jan 2007 17:15:24 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Rob Sherwood Subject: Re: [tcpm] DoS attack from misbehaving receivers References: <20070111202843.GL2944@loompa.cs.umd.edu> <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> <20070111212732.GM2944@loompa.cs.umd.edu> In-Reply-To: <20070111212732.GM2944@loompa.cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: david.malone@nuim.ie, 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 Rob Sherwood wrote: >> Before endorsing a counter-measure that calls for what was >> previously non-compliant behavior there should be a showing >> that the problem being solved is indeed severe and unique. > > Agreed. This is the crux of the discussion: is this attack severe > enough to motivate the admittedly invasive change to the TCP stack. Yep. >> If my understanding is correct, the problem is that an attacker >> can simulate reception of more material than their actual local >> link can support, and thereby trick a large group of senders >> into saturating *their* local links and/or intermediate segments. > > This is mostly correct. The true concern is that *backbone* links, > not just local links, will be saturated, bringing about, as the title > suggests, Internet-wide congestion collapse. It is this concern that > I feel motivates the need to change the specification. The links with heavily aggregated traffic from local or regional ISPs up to the tier 1 ISPs are almost always bandwidth capped, and are almost always purchased in such that they are able to carry "just enough" traffic -- that is, it's pegged for at least some of the time. (Who wants to pay for more than they use?) The core of the Internet today is provisioned to handle the load. It seems to me the threat of Internet-wide congestion collapse is a bit overstated these days. (This also applies to recent congestion control discussions.) I could see this attack as being effective at saturating something like a university's access link where a small number of well-connected servers could severely congest it. However, in my experience, server and network admins are very reluctant to run any sort of service that will stream arbitrary amounts of data as fast as they can. (I've sometimes tried to get such services made available for measurement purposes.) The defense proposed in the paper is pretty cool, but implementing it and running it on a production machine would make me a bit nervous. If this were a significant problem, you could always turn on bandwidth caps in the server application or in the kernel's networking system. This would probably be my favored approach. In reality, I've never heard of this attack being perpetrated in the wild, while DDOS is quite common. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 11 17:30:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Qu-0002dY-1V; Thu, 11 Jan 2007 17:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58Qt-0002dJ-6J for tcpm@ietf.org; Thu, 11 Jan 2007 17:30:03 -0500 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58Qs-0000Bl-04 for tcpm@ietf.org; Thu, 11 Jan 2007 17:30:03 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l0BMU19Y027243; Thu, 11 Jan 2007 17:30:01 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l0BMU1YY026042; Thu, 11 Jan 2007 17:30:01 -0500 (EST) Date: Thu, 11 Jan 2007 17:30:01 -0500 From: Rob Sherwood To: John Heffner Subject: Re: [tcpm] DoS attack from misbehaving receivers Message-ID: <20070111223001.GO2944@loompa.cs.umd.edu> References: <20070111202843.GL2944@loompa.cs.umd.edu> <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> <20070111212732.GM2944@loompa.cs.umd.edu> <45A6B6FC.7020000@psc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A6B6FC.7020000@psc.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org, david.malone@nuim.ie 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 Thu, Jan 11, 2007 at 05:15:24PM -0500, John Heffner wrote: > The links with heavily aggregated traffic from local or regional ISPs up > to the tier 1 ISPs are almost always bandwidth capped, and are almost > always purchased in such that they are able to carry "just enough" > traffic -- that is, it's pegged for at least some of the time. (Who > wants to pay for more than they use?) The core of the Internet today is > provisioned to handle the load. It seems to me the threat of > Internet-wide congestion collapse is a bit overstated these days. (This > also applies to recent congestion control discussions.) This is the part that is not clear to me: is it really the case that back bone links have sufficient capacity to handle the sum of all the access link capacity? That is to say not the expected load, but the maximum capacity? I am familiar with many of the link capacity estimation tools available, and it's my understanding that there is not a conclusive answer here. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 12 04:41:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5IuM-0002JG-V3; Fri, 12 Jan 2007 04:41:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5IuL-0002J5-Fl for tcpm@ietf.org; Fri, 12 Jan 2007 04:41:09 -0500 Received: from mail.nuim.ie ([149.157.1.19] helo=LARCH.MAY.IE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5IuG-0005Ld-3S for tcpm@ietf.org; Fri, 12 Jan 2007 04:41:09 -0500 Received: from retina-bcl.hamilton.local ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01MBU5BSLPOE00YYPM@NUIM.IE> for tcpm@ietf.org; Fri, 12 Jan 2007 09:34:56 +0000 (GMT) Received: from gavinmc by retina-bcl.hamilton.local with local (Exim 4.50) id 1H5Inw-0007cm-6p; Fri, 12 Jan 2007 09:34:32 +0000 Date: Fri, 12 Jan 2007 09:34:32 +0000 From: Gavin McCullagh Subject: Re: [tcpm] DoS attack from misbehaving receivers In-reply-to: <20070111212732.GM2944@loompa.cs.umd.edu> To: Rob Sherwood Message-id: <20070112093432.GA31536@nuim.ie> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20070111202843.GL2944@loompa.cs.umd.edu> <54AD0F12E08D1541B826BE97C98F99F1EE6E4E@NT-SJCA-0751.brcm.ad.broadcom.com> <20070111212732.GM2944@loompa.cs.umd.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: david.malone@nuim.ie, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin McCullagh List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thu, 11 Jan 2007, Rob Sherwood wrote: > > Before endorsing a counter-measure that calls for what was > > previously non-compliant behavior there should be a showing > > that the problem being solved is indeed severe and unique. > > Agreed. This is the crux of the discussion: is this attack severe > enough to motivate the admittedly invasive change to the TCP stack. We implemented a basic attack of this recently before realising that others had been here first. I've thrown up a few quick results here using a recent linux kernel on sender and receiver: http://www.hamilton.ie/gavinmc/drop_dupack_attack/ Kernel: 2.6.18 on both OS: Debian GNU/Linux "edgy" Apache v2.0.55 wget v1.10.2 The patch to linux is a short one. I can make it available, but have held off doing so for now. Gavin _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 12 20:10:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5XOV-0005sw-Nn; Fri, 12 Jan 2007 20:09:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5XOT-0005so-Ug for tcpm@ietf.org; Fri, 12 Jan 2007 20:09:13 -0500 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5XOS-0007wK-I8 for tcpm@ietf.org; Fri, 12 Jan 2007 20:09:13 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Fri, 12 Jan 2007 17:08:54 -0800 X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id F30A12AF; Fri, 12 Jan 2007 17:08:53 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CA25F2AE; Fri, 12 Jan 2007 17:08:53 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ETJ03338; Fri, 12 Jan 2007 17:08:49 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 10D6A20501; Fri, 12 Jan 2007 17:08:49 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] DoS attack from misbehaving receivers Date: Fri, 12 Jan 2007 17:05:20 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] DoS attack from misbehaving receivers Thread-Index: Acc2QYwgSlCVYNsBTHyXNG8Pq2WfFQAbVmQ8 References: <200701121201.l0CC1tnv002619@kac.cnri.dit.ie> From: "Caitlin Bestler" To: "David Malone" , "Gavin McCullagh" X-WSS-ID: 69B6EEAC3S41140981-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 -----Original Message----- From: dwmalone@cnri.dit.ie on behalf of David Malone Sent: Fri 1/12/2007 4:01 AM To: Gavin McCullagh Cc: Rob Sherwood; Caitlin Bestler; tcpm@ietf.org Subject: Re: [tcpm] DoS attack from misbehaving receivers =20 > We implemented a basic attack of this recently before realising that = others > had been here first. I've thrown up a few quick results here using a > recent linux kernel on sender and receiver: > http://www.hamilton.ie/gavinmc/drop_dupack_attack/ Note, while this was in the lab, we achieved similar results in the wild. Using a clean Linux+Apache install over the Internet, we convinced Apache to send a large file at 80Mbps to a host with a 1Mbps access link. In light of some of the recent discussion on Bugtraq, we probably don't really even need the large file. We'd also arrived at basically the same fix as suggested by Rob. Would it be interesting to see the fix written up as a draft, so technical issues surrounding it can be identified? Certainly, some care is required in the details of the fix to avoid introducing other attacks on TCP. (It could fit naturally as an additional fix section in draft-azcorra-tcpm-tcp-blind-ack-dos?) David. ------------------------ Documenting the attack is definitely a good idea, and I agree that it is essentially a blind ack attack (even though it is a=20 partial blindness, since *some* of the send segments reach the attacker). But I still don't see doing anything non-standard in the TCP stack as a counter-measure. Single flows of over 10 Mbits being sent to a stranger over the wide internet can be easily flagged at many different=20 layers. Keep in mind that *any* form of rate shaping will severely impact this attack because the attacker will no longer be able to predict the timing of tcp sequences. Slightly random rate shaping has no impact on TCP, and could easily be just as effective. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 13 05:59:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5gbW-0007fd-CD; Sat, 13 Jan 2007 05:59:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5gbU-0007fS-Mp for tcpm@ietf.org; Sat, 13 Jan 2007 05:59:16 -0500 Received: from kac.cnri.dit.ie ([147.252.67.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5gbT-00063l-8i for tcpm@ietf.org; Sat, 13 Jan 2007 05:59:16 -0500 Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id l0DAqbI4083078; Sat, 13 Jan 2007 10:52:37 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200701131052.l0DAqbI4083078@kac.cnri.dit.ie> To: Caitlin Bestler Subject: Re: [tcpm] DoS attack from misbehaving receivers In-Reply-To: Your message of "Fri, 12 Jan 2007 17:05:20 PST." <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com> From: David Malone Date: Sat, 13 Jan 2007 10:52:37 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 > Documenting the attack is definitely a good idea, and I agree > that it is essentially a blind ack attack (even though it is a > partial blindness, since *some* of the send segments reach > the attacker). Yes - indeed. This is kind of important, because it means that the defences currently described in draft-azcorra-tcpm-tcp-blind-ack-dos will not be effective. > Single flows of over 10 Mbits being sent to a stranger over > the wide internet can be easily flagged at many different > layers. Sometimes this is not so easy - some people want to ship 10Mbps streams to those that can receive them but do not want send them to people for whom it will cause congestion (for example, people providing mirror services). I guess it could be flagged by the network, but few people want routers to send source quench messages any more ;-) To me it seems natural to address this at the TCP layer because it is essentially an attack on TCP's congestion control mechanism. > Keep in mind that *any* form of rate shaping will severely > impact this attack because the attacker will no longer be able > to predict the timing of tcp sequences. There's no prediction involved in the attack that we were demoing - it is entirely deterministic. We just send an ACK for every packet we get, providing the sequence number is higher than the previous ACK that we sent. David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 13 06:36:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5hBN-00054C-HE; Sat, 13 Jan 2007 06:36:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5hBM-000542-AY for tcpm@ietf.org; Sat, 13 Jan 2007 06:36:20 -0500 Received: from mail.nuim.ie ([149.157.1.19] helo=LARCH.MAY.IE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5hBG-0002nC-Tf for tcpm@ietf.org; Sat, 13 Jan 2007 06:36:20 -0500 Received: from retina-bcl.hamilton.local ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01MBVNUUOMMK00ZQE2@NUIM.IE> for tcpm@ietf.org; Sat, 13 Jan 2007 11:36:29 +0000 (GMT) Received: from gavinmc by retina-bcl.hamilton.local with local (Exim 4.50) id 1H5hB7-0004i0-7e; Sat, 13 Jan 2007 11:36:05 +0000 Date: Sat, 13 Jan 2007 11:36:05 +0000 From: Gavin McCullagh Subject: Re: [tcpm] DoS attack from misbehaving receivers In-reply-to: <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com> To: Caitlin Bestler Message-id: <20070113113605.GA1127@nuim.ie> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.9i References: <200701121201.l0CC1tnv002619@kac.cnri.dit.ie> <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin McCullagh List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, On Fri, 12 Jan 2007, Caitlin Bestler wrote: > But I still don't see doing anything non-standard in the TCP > stack as a counter-measure. Of course, if it were well thought-out enough to be made part of the standard then it ceases to be non-standard :-) > Single flows of over 10 Mbits being sent to a stranger over the wide > internet can be easily flagged at many different layers. I think expecting every potentially large-data TCP application to implement rate-limiting is odd when the danger can only be understood at the transport layer. We'd be expecting every sysadmin to make some guess what their cap should be. Should it be half of their uplink, a tenth, a hundredth? Is it a function also of the number of connections they expect today or even of the number of attackers? What if the attack is not on the sender but on some narrower bottleneck between the sender and the attacker? It's a workaround in some instances but I don't see how it could be a solution to this problem. > Keep in mind that *any* form of rate shaping will severely > impact this attack because the attacker will no longer be able > to predict the timing of tcp sequences. Perhaps I've misunderstood you here, but I don't think this would prevent the attack we have implemented. What the attack does is simply to acknowledge those packets which are received regardless of whether they are in sequence. There's no prediction at all. As the attack progresses, a constant number of acks is sent -- one for each packet received, but the amount of data being acknowledged grows linearly (though some ack division could probably improve on that). http://www.hamilton.ie/gavinmc/drop_dupack_attack/ In a sense "optimistic acking" is not really the best name for this incarnation of the attack. Perhaps better names might be "out of sequence acking", "hole acking" or just plain "dishonest acking" to cover the multitude. > Slightly random rate shaping has no impact on TCP, and could easily be > just as effective. I'm not sure if you mean variation of MSS or of the congestion avoidance increase? Again, I'm often wrong but I don't think that's effective against the above attack. Gavin _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 13 11:19:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5laG-0001rK-0S; Sat, 13 Jan 2007 11:18:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5laE-0001qJ-H7 for tcpm@ietf.org; Sat, 13 Jan 2007 11:18:18 -0500 Received: from circular.cs.umd.edu ([128.8.128.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5laD-0001le-3W for tcpm@ietf.org; Sat, 13 Jan 2007 11:18:18 -0500 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by circular.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l0DGIFh8014979; Sat, 13 Jan 2007 11:18:15 -0500 Received: (from capveg@localhost) by loompa.cs.umd.edu (8.12.10/8.12.5) id l0DGI9Ud007876; Sat, 13 Jan 2007 11:18:09 -0500 (EST) Date: Sat, 13 Jan 2007 11:18:08 -0500 From: Rob Sherwood To: Caitlin Bestler Subject: Re: [tcpm] DoS attack from misbehaving receivers Message-ID: <20070113161808.GX2944@loompa.cs.umd.edu> References: <200701121201.l0CC1tnv002619@kac.cnri.dit.ie> <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 In addition to David and Gavin's comments: On Fri, Jan 12, 2007 at 05:05:20PM -0800, Caitlin Bestler wrote: > Single flows of over 10 Mbits being sent to a stranger over > the wide internet can be easily flagged at many different > layers. There is no requirement in the attack that any one flow would be large (10MB or what have you) or in any way anomalous. As discussed in the paper, the attacker can simply create many small streams instead of few large streams such that no intrusion detection system or rate limiting queue is affected. Because the ACK stream is used to determine when to timeout (ACK clocking, forged TCP timestamps), when to send (incoming ACK frees new segments), and how much to send (the number of new segments freed), the attacker is in complete control of the connection, and can shape traffic nearly arbitrarily. So an intelligent attacker can shape each connection to appear to be a perfectly "normal" connection to any other layer then layer4, for any definition of normal. That is why the fix to this problem must be at the transmission layer. > Keep in mind that *any* form of rate shaping will severely > impact this attack because the attacker will no longer be able > to predict the timing of tcp sequences. I do not believe this to be true. The attack described by David and Gavin ("lazy optack" in my paper) defeats this. Additionally, the standard optack attack defeats this when the attack simply ACKs less often (e.g., 1 ack/500ms) but to more streams for the same total aggregate traffic. This behavior, as described in the paper, is actually required in practice to prevent ACKing ahead of sent data, because non-randomized rate TCP streams naturally have sufficient entropy in the segment generation rate that this is already a concern. - Rob . _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 17 20:25:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7M1P-00039l-9s; Wed, 17 Jan 2007 20:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7M1N-00039f-Re for tcpm@ietf.org; Wed, 17 Jan 2007 20:24:53 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7M1L-0006nB-Ds for tcpm@ietf.org; Wed, 17 Jan 2007 20:24:53 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0I1OfdG011696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Jan 2007 17:24:41 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l0I1OfsJ069360 for tcpm@ietf.org; Wed, 17 Jan 2007 17:24:41 -0800 (PST) (envelope-from faber) Date: Wed, 17 Jan 2007 17:24:41 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20070118012440.GC1540@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) 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="===============1111900067==" Errors-To: tcpm-bounces@ietf.org --===============1111900067== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VywGB/WGlW4DM4P8" Content-Disposition: inline --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. As we mentioned in San Diego, the anti-spoof document is ready for a second last call. We're primarily checking to see that issues brought up in the first WGLC have been addressed. You can find much of that discussion starting here: http://www1.ietf.org/mail-archive/web/tcpm/current/msg01890.html The draft is available from=20 ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt Comments (including positive ones, please) to the list. This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. --=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 --VywGB/WGlW4DM4P8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFrsxXaUz3f+Zf+XsRAhyhAJ9CVf6MJLk/VVSQMQiNvXM3U3CFBgCguFPM BurHBJUC1npkfVV4s0pYBX4= =h/a6 -----END PGP SIGNATURE----- --VywGB/WGlW4DM4P8-- --===============1111900067== 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 --===============1111900067==-- From tcpm-bounces@ietf.org Wed Jan 17 22:11:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Nfv-0004F3-A0; Wed, 17 Jan 2007 22:10:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Nft-0004Eq-Gc for tcpm@ietf.org; Wed, 17 Jan 2007 22:10:49 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Nfs-0001zp-41 for tcpm@ietf.org; Wed, 17 Jan 2007 22:10:49 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id B6C67C211 for ; Wed, 17 Jan 2007 22:10:38 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0I3AbDb004787; Wed, 17 Jan 2007 22:10:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0I3AXxj018852; Wed, 17 Jan 2007 22:10:33 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1]) by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw15uxp1rEfi; Wed, 17 Jan 2007 22:10:33 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0I3ATD2018837; Wed, 17 Jan 2007 22:10:29 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id A4C324FE27; Wed, 17 Jan 2007 22:08:08 -0500 (EST) Date: Wed, 17 Jan 2007 22:08:08 -0500 From: Wesley Eddy To: Ted Faber Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb2007) Message-ID: <20070118030808.GA20966@grc.nasa.gov> References: <20070118012440.GC1540@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070118012440.GC1540@hut.isi.edu> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0540222256==" Errors-To: tcpm-bounces@ietf.org --===============0540222256== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote: > Hi. >=20 > As we mentioned in San Diego, the anti-spoof document is ready for a > second last call. We're primarily checking to see that issues brought > up in the first WGLC have been addressed. You can find much of that > discussion starting here: >=20 > http://www1.ietf.org/mail-archive/web/tcpm/current/msg01890.html >=20 > The draft is available from=20 >=20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt >=20 > Comments (including positive ones, please) to the list. >=20 Consider this a positive comment. I've read both the current document and some previous versions. I think all the issues I noticed in previous versions have been solved, and I think this is ready to publish as an RFC. I found the draft very helpful in understanding the aspects of the problem and the gamut of solution approaches that TCPM has discussed. I hope other WGs that maintain well-established protocols follow this example in documenting problems that are found over time and solution approaches that are proposed. Too often we only see a gamut of solutions published, and no good description of the actual problem or the engineering tradeoffs between the solutions. --=20 Wesley M. Eddy Verizon Federal Network Systems --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFruSXzBuYqbnj3IwRAgZgAJ4qZ+w8BpJ/qxO5EXlaVgOazEIDhwCfXtT5 cyRJBTRU7F7FPGJUa21hEG4= =bnI+ -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- --===============0540222256== 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 --===============0540222256==-- From tcpm-bounces@ietf.org Fri Jan 19 14:54:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7znx-0003rf-89; Fri, 19 Jan 2007 14:53:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7znv-0003rY-NN for tcpm@ietf.org; Fri, 19 Jan 2007 14:53:39 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7znr-0005Os-Ns for tcpm@ietf.org; Fri, 19 Jan 2007 14:53:39 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 08050F0C438 for ; Fri, 19 Jan 2007 16:53:31 -0300 (ART) Received: from fgont.gont.com.ar (46-162-231-201.fibertel.com.ar [201.231.162.46]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l0JJrOFs017608 for ; Fri, 19 Jan 2007 16:53:28 -0300 Message-Id: <7.0.1.0.0.20070119163504.06d561b0@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 19 Jan 2007 16:36:31 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Fri, 19 Jan 2007 16:53:30 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659 Subject: [tcpm] Alfred Hoenes: draft-ietf-tcpm-icmp-attacks-01 (etc.) 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, I received this review of the ICMP attacks draft. >From: Alfred =3D?hp-roman8?B?SM5uZXM=3D?=3D >Subject: draft-ietf-tcpm-icmp-attacks-01 (etc.) >To: fernando@gont.com.ar >Date: Wed, 10 Jan 2007 01:10:02 +0100 (MEZ) >X-Mailer: ELM [$Revision: 1.17.214.3 $] > >Hello, >after studying your I-D, draft-ietf-tcpm-icmp-attacks-01, >I would like to send you e few comments pointing out (mostly) >textual issues I found in that draft (and in a related note >you have posted). > >After reading your exposition, I really wonder why these issues, >and the countermeasures against, have not been discovered already >many years ago -- such clear is the threat, und such logical seem >the remedies! > >Here are the textual issues I found in the draft, documented as: > > >--- > > >I use change bars ('|' in column 1) and occasionally >up/down pointing marker lines ('^^^'/'vvv') to emphasize >the location of textual issues and/or proposed corrections. >All snippits are taken preserving the original identation >and formatting; modified text has been re-adjusted to match >I-D / RFC formatting rules, where appropriate. > > >(1) Section 1: > >In the first paragraph: > > ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > and is used mainly for reporting network error conditions. However, > the current specifications do not recommend any kind of validation >| checks on the received ICMP error messages, thus allowing variety of > attacks against TCP [RFC0793] by means of ICMP, which include blind > connection-reset, blind throughput-reduction, and blind performance- > degrading attacks. All of these attacks can be performed even being > off-path, without the need to sniff the packets that correspond to > the attacked TCP connection. >--- > ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite, > and is used mainly for reporting network error conditions. However, > the current specifications do not recommend any kind of validation >| checks on the received ICMP error messages, thus allowing a variety > of attacks against TCP [RFC0793] by means of ICMP, which include > blind connection-reset, blind throughput-reduction, and blind > performance-degrading attacks. All of these attacks can be performed > even being off-path, without the need to sniff the packets that > correspond to the attacked TCP connection. > >(2) Section 2.2 > >(2a) >In the 4th paragraph, there's the first occurrence of an 'unsatisfied' >reference tag (see marked line below): [Touch-antispoof] >This same tag recurs in the last sentence of Section 4.1, but it does >*not* appear in the References sections. > >I guess (after browsing the I-D index) that it should be: > draft-ietf-tcpm-tcp-antispoof-05 > >Please add the appropriate bibliographic entry to Section 10.2 > >(2b) >In the same paragraph, there's a typo (singular/plural mismatch): > > Generally, the four-tuple required to perform these attacks is not >| known. However, as discussed in [Watson] and [Touch-antispoof], > there are a number of scenarios (notably that of TCP connections > established between two BGP routers), in which an attacker may be > able to know or guess the four-tuple that identifies a TCP > connection. In such a case, if we assume the attacker knows the two > systems involved in the TCP connection to be attacked, both the > client-side and the server-side IP addresses could be known or be > within a reasonable number of possibilities. Furthermore, as most > Internet services use the so-called "well-known" ports, only the >| client port number might need to be guessed. In such a scenario, an > attacker would need to send, in principle, at most 65536 packets to > perform any of the attacks described in this document. However, as > most systems choose the port numbers they use for outgoing > connections from a subset of the whole port number space, the amount > of packets needed to successfully perform any of the attacks > discussed in this document could be further reduced. >--- > Generally, the four-tuple required to perform these attacks is not > known. However, as discussed in [Watson] and [Touch-antispoof], > there are a number of scenarios (notably that of TCP connections > established between two BGP routers), in which an attacker may be > able to know or guess the four-tuple that identifies a TCP > connection. In such a case, if we assume the attacker knows the two > systems involved in the TCP connection to be attacked, both the > client-side and the server-side IP addresses could be known or be > within a reasonable number of possibilities. Furthermore, as most > Internet services use the so-called "well-known" ports, only the >| client port number might needs to be guessed. In such a scenario, an > attacker would need to send, in principle, at most 65536 packets to > perform any of the attacks described in this document. However, as > most systems choose the port numbers they use for outgoing > connections from a subset of the whole port number space, the amount > of packets needed to successfully perform any of the attacks > discussed in this document could be further reduced. > >(3) Section 2.3 > >In the first paragraph, there's a typo (missing "of"), and a sentence >with two verbs. I guess the "receives" should be deleted in favour of >the "is": > >| Section 5.2 of [RFC4301] describes the processing inbound IP Traffic > in the case of "unprotected-to-protected". In the case of ICMP, when > an unprotected ICMP error message is received, it is matched to the > corresponding security association by means of the SPI (Security > Parameters Index) included in the payload of the ICMP error message. > Then, local policy is applied to determine whether to accept or > reject the message and, if accepted, what action to take as a result. > For example, if an ICMP unreachable message is received, the > implementation must decide whether to act on it, reject it, or act on > it with constraints. Section 8 ("Path MTU/DF processing") discusses > the processing of unauthenticated ICMP "fragmentation needed and DF > bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" (type 2, code >| 0) messages when an IPsec implementation receives is configured to > process (vs. ignore) such messages. >--- >| Section 5.2 of [RFC4301] describes the processing of inbound IP > Traffic in the case of "unprotected-to-protected". In the case of > ICMP, when an unprotected ICMP error message is received, it is > matched to the corresponding security association by means of the SPI > (Security Parameters Index) included in the payload of the ICMP error > message. Then, local policy is applied to determine whether to > accept or reject the message and, if accepted, what action to take as > a result. For example, if an ICMP unreachable message is received, > the implementation must decide whether to act on it, reject it, or > act on it with constraints. Section 8 ("Path MTU/DF processing") > discusses the processing of unauthenticated ICMP "fragmentation > needed and DF bit set" (type 3, code 3) and ICMPv6 "Packet Too Big" >| (type 2, code 0) messages when an IPsec implementation is configured > to process (vs. ignore) such messages. > >(4) Section 5.2 > >I did not understand the last sentence in that (single) paragraph >there, until I finally arrived at guesssing that the word "advice" >perhaps should be deleted. > > [...]. Given the > hostile environments in which TCP currently operates in, and that >| advice ICMP provides an attack vector that is easier to exploit than > others (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we > believe that the improvements in TCP's resistance to these attacks > justify not taking the advice provided by the "SHOULDs" in [RFC1122]. >--- > [...]. Given the > hostile environments in which TCP currently operates in, and that >| ICMP provides an attack vector that is easier to exploit than others > (such as those discussed in [I-D.ietf-tcpm-tcpsecure]), we believe > that the improvements in TCP's resistance to these attacks justify > not taking the advice provided by the "SHOULDs" in [RFC1122]. > >(5) Section 5.2.1 > >(5a) >In the first paragraph, the wording should be improved: > > An analysis of the circumstances in which ICMP messages that indicate >| hard errors may be received can shed some light to eliminate the > impact of ICMP-based blind connection-reset attacks. >--- > An analysis of the circumstances in which ICMP messages that indicate >| hard errors may be received can shed some light on how to eliminate > the impact of ICMP-based blind connection-reset attacks. > >(5b) >In the discussion of the > > ICMPv6 type 1 (Destination Unreachable), code 1 (communication with > destination administratively prohibited) > >there is a sentence that did not make sense to me; maybe it does not >even say what you wanted to say : > > [...] However, there is no reason to think that in > the same way this error condition appeared, it will not get solved > in the near term. [...] > >I guess it was intended to state something like: > > In real life, this error condition will appear > very rarely; if it persists, it will be handled correctly after the > ensuing ACK timeout. > >(5b) >In the paragraph after the five ICMP message type explanations (this is >the 5th-to-last paragraph of the section), there are two sentences with >two verbs each: "is" + "is" , and "are" + "indicate" , respectively: > > Therefore, when following the reasoning explained above, TCPs in > synchronized states would treat all of the above messages as > indicating "soft errors", rather than "hard errors", and thus would >| not abort the corresponding connection upon receipt of them. This is > policy is based on the premise that TCP should be as robust as > possible. Reaction to these messages when they are meant for > connections in non-synchronized states could still remain as adviced > by [RFC1122], as we consider the attack window for connections in the > non-synchronized states is very small, and error messages received in >| these states are more likely indicate that the connection was opened > improperly [RFC0816]. Additionally, for the sake of robustness and > security, those implementations following the reasoning explained in > this section would not extrapolate ICMP errors across TCP > connections. >--- > Therefore, when following the reasoning explained above, TCPs in > synchronized states would treat all of the above messages as > indicating "soft errors", rather than "hard errors", and thus would >| not abort the corresponding connection upon receipt of them. This > policy is based on the premise that TCP should be as robust as > possible. Reaction to these messages when they are meant for > connections in non-synchronized states could still remain as adviced > by [RFC1122], as we consider the attack window for connections in the > non-synchronized states is very small, and error messages received in >| these states more likely indicate that the connection was opened > improperly [RFC0816]. Additionally, for the sake of robustness and > security, those implementations following the reasoning explained in > this section would not extrapolate ICMP errors across TCP > connections. > >(5c) >In the subsequent paragraph, the above 'magic' sentence recurs in >slightly modified form: > > In case the received message were legitimate, it would mean that the > error condition appeared during the life of the corresponding >| connection. However, in many scenarios there is no reason to think >| that in the same way this error condition appeared, it will not get >| solved in the near term. [...] > >"there is no reason to think that ... it will not get solved ..." >just contains too many negations. This sentence might be replaced >in a similar way as proposed above. > >(5d) >Stepping ahead, in the next paragraph (3rd-to-last in the Section), >the wording should preferrably be improved: > >| One scenario in which a host would benefit from treating the so- > called ICMP "hard errors" as "soft errors" would be that in which the > packets that correspond to a given TCP connection are routed along > multiple different paths. [...] >--- >| Another scenario in which a host would benefit from treating the so- > called ICMP "hard errors" as "soft errors" would be that in which the > packets that correspond to a given TCP connection are routed along > multiple different paths. [...] > >(5e) >The next paragraph deals with ignored error messages and out-of-band >signalling of error conditions. Therefore, "received error messages" >should better be replaced by just "error conditions" : > > It is interesting to note that, as ICMP error messages are > unreliable, transport protocols should not depend on them for correct > functioning. In the event one of these messages were legitimate, the > corresponding connection would eventually time out. Also, >| applications may still be notified asynchronously about the received >| error messages, and thus may still abort their connections on their > own if they consider it appropriate. >--- > It is interesting to note that, as ICMP error messages are > unreliable, transport protocols should not depend on them for correct > functioning. In the event one of these messages were legitimate, the > corresponding connection would eventually time out. Also, >| applications may still be notified asynchronously about the error >| conditions, and thus may still abort their connections on their own > if they consider it appropriate. > >[ In place of "error conditions", you might prefer "error condition", > "errors", or "error" . ] > >(6) Section 5.2.3 > >(6a) >As in (5e) above (including the note), in the first paragraph: > > [...]. It should also be noted that applications may >| still be notified asynchronously about the received error messages, > and thus may still abort their connections on their own if they > consider it appropriate. >--- > [...]. It should also be noted that applications may >| still be notified asynchronously about the error conditions, and thus > may still abort their connections on their own if they consider it > appropriate. > >(6b) >And again, in the second paragraph: > > [...]. Additionally, applications may still be notified >| asynchronously about the received error messages, and thus may still > abort their connections on their own if they consider it appropriate. >--- > [...]. Additionally, applications may still be notified >| asynchronously about the error conditions, and thus may still > abort their connections on their own if they consider it appropriate. > >(7) Section 6.1 > >At the end of the (single) paragraph, add the missing article, "an": > >| [...]. The throughput achieved during attack might be a > little higher if a larger initial congestion window is in use > [RFC3390]. >--- >| [...]. The throughput achieved during an attack might be > a little higher if a larger initial congestion window is in use > [RFC3390]. > >(8) Section 7.1 > >I propose a textual enhancement in the 5th paragraph. >IMHO, the referred to "IRQ ... rate" problem is only one face of the >whole story. Below, I substitute "protocol processing time" for that >(you might also add it, as "IRQ ... rate and protocol processing time"). > > [...]. On >| virtually all systems this will lead to an increase in the IRQ >| (Interrrupt ReQuest) rate, thus increasing processor utilization, and > degrading the overall system performance. >--- > [...]. On >| virtually all systems this will lead to an increase in the protocol >| processing time, thus increasing processor utilization, and degrading > the overall system performance. > >(9) Section 7.2 > >(9a) >In the classification performed: > > To achieve both goals, we can divide the traditional PMTUD mechanism > into two stages: Initial Path-MTU Discovery, and Path-MTU Update. > >the latter apparently is intended to deal with PMTU reduction only, >as can be seen from the subsequent discussion. > >IMHO, that has one serious drawback: it does not cover the "probing >for PMTU increase" described in the third paragraph of Section 3 of >RFC 1191, intended to discover effective PMTU introduced by routing >changes. I'm not sure whether this procedure is handled gracefully >by your algorithm -- but I might err here; I just do not have enough >spare time to delve into performing 'mental simulation' for that >scenario now. Please check. > >In any case, I would appreciate an extended discussion clearly >covering this third case, throughout Section 7.2, and perhaps also >an addition to Appendix A showing the behaviour during PMTU probing. > >(9b) >In the 17th paragraph of Section 7.2, perhaps "everytime" should be >replaced by "every time", according to the context. > >(10) References > >(10a) missing entry -- see (2a) above > >(10b) >There's a typo in your own URI [Ouch!] : > > [ICMP-Filtering] > Gont, F., "Filtering of ICMP error messages", http:// > www.gont.com.ar/papers/filtering-icmp-error-messages.pdf. >--- > [ICMP-Filtering] > Gont, F., "Filtering of ICMP error messages", http:// > www.gont.com.ar/papers/filtering-of-icmp-error-messages.pdf. > ^^^ >BTW: >... And in that memo, I found two small typos as well: > >(F1) First bullet on page 1: > "on of" --> "one of" > >(F2) First subordinate bullet of first bullet on page 2: > "intermmediate" --> "intermediate" > >(11) Appendix B > >(11a) >Repeated "far" <--> "for" ; missing punctuation > > maxsizeacked > Variable holding the largest packet size (data, plus headers) that >| has so for been acked far this connection, as explained in >| Section 7.2 >--- > maxsizeacked > Variable holding the largest packet size (data, plus headers) that >| has so far been acked for this connection, as explained in >| Section 7.2. > > maxsizesent > Variable holding the largest packet size (data, plus headers) that >| has so for been sent far this connection, as explained in >| Section 7.2 >--- > maxsizesent > Variable holding the largest packet size (data, plus headers) that >| has so far been sent for this connection, as explained in >| Section 7.2. > > nsegrto > Variable holding the number of times this segment has timed out, >| as explained in Section 7.2 >--- > nsegrto > Variable holding the number of times this segment has timed out, >| as explained in Section 7.2. > > packet_size >| Variable holding the size of the IP datagram being sent >--- > packet_size >| Variable holding the size of the IP datagram being sent. > >(11b) >In the pseudocode for > > EVENT: Segment is received > >correct > if (pending_mesage) >--- > if (pending_message) > >(11c) >The presentation of the pseudocode for > > EVENT: ICMP "Packet Too Big" message is received > >suffers from the deep nesting and varying use of braces. >[Note: That's perfectly o.k. from a syntax point of view (in 'C').] >I propose to streamline the presentation to enhance the readability, >by making it more compact and better show the structure of a single >case switch (exactly one of the code blocks is to be executed in >any case): > > if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >=3D SND.NXT){ > drop_message(); >| } >| >| else { >| if (claimedmtu >=3D maxsizesent || claimedmtu >=3D= current_mtu) > drop_message(); >| >| else { >| if (claimedmtu > maxsizeacked){ > adjust_mtu(); > current_mtu =3D claimedmtu; > maxsizesent =3D MINIMUM_MTU; >| } >| >| else { > pending_message =3D 1; > save_message(); >| } >| } > } >--- >| if (claimedtcpseq < SND.UNA || claimed_TCP_SEQ >=3D SND.NXT) { >| drop_message(); >| } else if (claimedmtu >=3D maxsizesent || >| claimedmtu >=3D current_mtu) { >| drop_message(); >| } else if (claimedmtu > maxsizeacked) { >| adjust_mtu(); >| current_mtu =3D claimedmtu; >| maxsizesent =3D MINIMUM_MTU; >| } else { >| pending_message =3D 1; >| save_message(); >| } > >[ This time, I also have tagged the lines that only had their > indentation changed, because that's the visual clue intended; I have > removed the redundant braces of type else { if } , > but added (arguably redundant) braces around the second instance of > drop_message(); just for symmetry; the line break after '||' is > introduced only to accomodate for the line length restriction. ] > >(12) Appendix E > >(12a) >Apparently there is something wrong with E.1 and E.2 : > >E.1. Changes from draft-gont-tcpm-icmp-attacks-05 <---+ >E.2. Changes from draft-ietf-tcpm-icmp-attacks-00 <---+ >E.3. Changes from draft-gont-tcpm-icmp-attacks-04 >E.4. Changes from draft-gont-tcpm-icmp-attacks-03 >E.5. Changes from draft-gont-tcpm-icmp-attacks-02 >E.6. Changes from draft-gont-tcpm-icmp-attacks-01 >E.7. Changes from draft-gont-tcpm-icmp-attacks-00 > >Shouldn't the sequence of the subsections correspond to the history, >with the draft-ietf-*-00 being the latest, listed first? > >I do not know whether just the headlines are exchanged, or the full >sub-sections are misoredered. Please check. > >(12b) typo in current E.2 : > >| o Added an specific section on IPsec (Section 2.3) >--- >| o Added a specific section on IPsec (Section 2.3) > >(12b) garbage in E.6 : > >| o Added Section on Acknowledgement number checking"/> >--- >| o Added Section on Acknowledgement number checking > > >Best regards, > Alfred H=CEnes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ -- 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 Wed Jan 24 14:49:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9o6f-0000r3-Ey; Wed, 24 Jan 2007 14:48:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9o6d-0000pU-JQ; Wed, 24 Jan 2007 14:48:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9o1y-0001Vh-MV; Wed, 24 Jan 2007 14:43:40 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 11:43:38 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0OJhcim026812; Wed, 24 Jan 2007 11:43:38 -0800 Received: from dwingwxp (rtp-vpn3-272.cisco.com [10.82.217.18]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0OJhVho004424; Wed, 24 Jan 2007 11:43:32 -0800 (PST) From: "Dan Wing" To: , Date: Wed, 24 Jan 2007 11:43:26 -0800 Message-ID: <015201c73fef$f0fc7900$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acc/7+pIYyPyXe++QkyaABxXjX3fXA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=845; t=1169667818; x=1170531818; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=20draft-ietf-behave-tcp-04=20starts=20now |Sender:=20; bh=uwMh9klO1ZkA7wz3W0XfgMv4QZ0CyNsYOzx1wnWI66M=; b=AUvU22KAKNOkqr7xKyqZNUgHCB2hVWUQeo1OFO3fDmhZ7MWvtn6ZkHaKLmQA7XIEBnTue3X9 C8RLwC1Xo/wq7Fskq9aep23Q1a/VDLFA7jgdKCIAk5axh1PcVFlego2z; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: baford@mit.edu, "'Kaushik Biswas \(kbiswas\)'" , 'Pyda Srisuresh' , "'Senthil Sivakumar \(ssenthil\)'" Subject: [tcpm] WGLC draft-ietf-behave-tcp-04 starts now 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 BEHAVE, TCPM: We are starting a two-week working group last call in the BEHAVE working group for a TCP-related document, draft-ietf-behave-tcp-04, which describes how to NAT TCP traffic. This document is expected to become a BCP. http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-04.txt Abstract: This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Please send comments to the authors (CC'd) or behave@ietf.org. WGLC on this document ends on Wednesday, 7-Feb-2007. -Dan Wing chair, BEHAVE working group _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 25 18:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEM5-0003iR-9v; Thu, 25 Jan 2007 18:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAELy-0003hd-IS; Thu, 25 Jan 2007 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAELy-0006wi-AI; Thu, 25 Jan 2007 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 46D7832A2E; Thu, 25 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HAELy-0001mt-5A; Thu, 25 Jan 2007 18:50: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: Thu, 25 Jan 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-soft-errors-03.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-03.txt Pages : 13 Date : 2007-1-25 This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, this document describes a non-standard, but widely implemented modification to TCP's reaction to ICMP "soft errors" that can help overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-03.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-03.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-03.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-1-25154424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-soft-errors-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-soft-errors-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-25154424.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Fri Jan 26 12:49:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVBD-0004bF-E7; Fri, 26 Jan 2007 12:48:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVBC-0004bA-0V for tcpm@ietf.org; Fri, 26 Jan 2007 12:48:02 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVBA-0001i2-IB for tcpm@ietf.org; Fri, 26 Jan 2007 12:48:01 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l0QHlgxI008991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jan 2007 09:47:42 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id l0QHlgw6045926 for tcpm@ietf.org; Fri, 26 Jan 2007 09:47:42 -0800 (PST) (envelope-from faber) Date: Fri, 26 Jan 2007 09:47:42 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007) Message-ID: <20070126174742.GF44355@hut.isi.edu> References: <20070118012440.GC1540@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20070118012440.GC1540@hut.isi.edu> User-Agent: Mutt/1.4.2.2i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============0743071972==" Errors-To: tcpm-bounces@ietf.org --===============0743071972== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KJY2Ze80yH5MUxol" Content-Disposition: inline --KJY2Ze80yH5MUxol Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote: > Hi. >=20 > As we mentioned in San Diego, the anti-spoof document is ready for a > second last call. We're primarily checking to see that issues brought > up in the first WGLC have been addressed. You can find much of that > discussion starting here: >=20 > http://www1.ietf.org/mail-archive/web/tcpm/current/msg01890.html >=20 > The draft is available from=20 >=20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt >=20 > Comments (including positive ones, please) to the list. >=20 > This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. Just a reminder: this WGLC has one week left. I've only seen one message about the draft. Passing a WGLC requires some reaction from the group. If you're interested in seeing this work done and believe that this document represents a reasonable consensus, please speak up. And, of course, if you see problems with the draft, also speak up. --=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 --KJY2Ze80yH5MUxol Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFuj69aUz3f+Zf+XsRAjH8AJ47Uosju75bFzbOAGClFs7sLJiJGACg9fUq 3e2nMvTn0xShomChlNhHRvo= =C22y -----END PGP SIGNATURE----- --KJY2Ze80yH5MUxol-- --===============0743071972== 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 --===============0743071972==-- From tcpm-bounces@ietf.org Fri Jan 26 13:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVsm-0003uI-Ua; Fri, 26 Jan 2007 13:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVsl-0003tO-26 for tcpm@ietf.org; Fri, 26 Jan 2007 13:33:03 -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 1HAVsi-0000FE-Fi for tcpm@ietf.org; Fri, 26 Jan 2007 13:33:03 -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 l0QIWoAL023057 for ; Fri, 26 Jan 2007 10:32:52 -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); Fri, 26 Jan 2007 10:32:50 -0800 Received: from [192.168.117.73] ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 10:32:50 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: TCP Maintenance and Minor Extensions WG From: David Borman Date: Fri, 26 Jan 2007 12:33:29 -0600 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Jan 2007 18:32:50.0571 (UTC) FILETIME=[626055B0:01C74178] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [tcpm] RFC 1323: Timestamps option 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 One of the topics that has been discussed in the past for the revision of RFC 1323 is to relax the requirement on when to send the Timestamps option. I'd like to come to some resolution on this issue. Current: The Timestamps option is negotiated during the initial SYN exchange. If both sides support it, then every packet in the connection has to have the Timestamps option. Option #1 --------- The proposed change is to relax the requirement that Timestamps have to be negotiated in the initial SYN, and instead allow them to be enabled later on in the connection. At the time 1323 was originally written, there was a big concern for legacy TCP stacks that didn't handle unknown options in the middle of the connection, but were able to properly ignore unknown options during the SYN exchange. But that was a long time ago, and unknown options in the middle of a TCP connection *shouldn't* be as big of an issue anymore. The rules for enabling Timestamps mid-stream would be: 1) If you receive a Timestamps option mid-stream, you can enable Timestamps. From then on, every packet sent will need to contain a Timestamps option. 2) If you want to enable Timestamps mid-stream, you can only do so on a data packet. You record the sequence number of that data packet, and include the Timestamps option on every packet from then on, until you receive an ACK for that sequence number. If at any time you receive a packet with the Timestamps option, then they are enabled for the rest of the connection. If you do not receive a packet with a Timestamps option by the time you get the ACK for that initial sequence number, then the other side has not enabled Timestamps and you must stop sending Timestamps for the duration of the connection. The restriction on only being able to initiate Timestamps on a data packet is that they are the only packets that are delivered reliably, so determining whether or not the other side supports them is deterministic by getting the ACK for that data. Option #2 --------- This is similar to Option #1, but not quite the same. In this case, the Timestamps would be negotiated in the initial SYN as before, but then no additional packets would have Timestamps options. At any point during the connection, either side can enable the use of Timestamps just by starting to send them. Since we already know that both sides support them, once you start sending them you never stop. And if you every receive one, you are then required to also send them for the duration of the connection. The question then is, how do you negotiate Timestamps without turning them on? My suggestion would be to send a Timestamps option with the special format TSval=0,TSecr=0. If you receive this in a SYN, then the request is to negotiate knowledge of the Timestamps option. The returning SYN,ACK would also need to contain TSval=0,TSecr=0 to complete the negotiation. If you are connecting to a site that doesn't support this feature but does support Timestamps, it would respond with TSval=xxx,TSecr=0. At that point, Timestamps are now enabled. The downside of this is that now the originator has started their Timestamps values at 0, and must continue from there with their timestamps; they can't just suddenly jump to some arbitrary value because that could break PAWs. Option #3 --------- Do nothing, and leave Timestamps alone as they are currently defined. You negotiate them in the SYN, and then include them in every packet from then on. One of the issues with Timestamps is that the TSecr value is defined to be valid anytime the ACK bit is set. This works well with the initial SYN negotiation, but when you enable Timestamps midstream, the initiator has to send a Timestamps option with an invalid TSecr value, but the ACK bit will be set. That's the case for both of the previous options. So why should we change things? My recollection was that the primary motivation was to conserve option space, to avoid having to put in the extra 12 bytes of TCP options on every packet until we get to the point where the sequence space might wrap, and then turn them on so that we can get PAWS to protect the rest of the connection. But I'm not sure I buy that argument. One of the things that you lose by deferring enabling Timestamps is that you don't get the RTT measurements that Timestamps provide. Without Timestamps, using the typical BSD algorithm of timing one segment and waiting for an ACK, and adding in the Karn algorithm that you have to invalidate any measurements if you had to retransmit in that window, means that at best, you'll get one measurement per RTT. At worst, you can get in a state where you never get a valid RTT measurement. When you use the Timestamps option, the worst case is that you'll only get one measurement per RTT, and the best case is that you'll get multiple valid samples, My viewpoint ------------ Right now, I'm inclined to leave the Timestamps option alone; you negotiate it during the SYN exchange, and then include it on every packet. I'm willing to be convinced otherwise, but now I've placed a stake in the ground, and the mailing list will have to decide if there is sufficient reason to change the behavior. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 14:10:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWSn-0006Rq-4w; Fri, 26 Jan 2007 14:10:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWSl-0006Ri-H9 for tcpm@ietf.org; Fri, 26 Jan 2007 14:10:15 -0500 Received: from smtpout.mac.com ([17.250.248.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWSj-0005fF-48 for tcpm@ietf.org; Fri, 26 Jan 2007 14:10:15 -0500 Received: from mac.com (smtpin06-en2 [10.13.10.151]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id l0QJA4K1026813; Fri, 26 Jan 2007 11:10:08 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-226-78.dsl.snfc21.sbcglobal.net [70.231.226.78]) (authenticated bits=0) by mac.com (Xserve/smtpin06/MantshX 4.0) with ESMTP id l0QJA0bm022398; Fri, 26 Jan 2007 11:10:01 -0800 (PST) In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sally Floyd Subject: Re: [tcpm] RFC 1323: Timestamps option Date: Fri, 26 Jan 2007 11:09:59 -0800 To: David Borman X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: TCP Maintenance and Minor Extensions WG 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 - I don't have any feedback about *when* to negotiate timestamps, but I do have some feedback about how the RTO should be estimated when timestamps are used. Just as something to include in a revision of RFC 1323... Regards, - Sally http://www.icir.org/floyd/ Here is some old email of mine on this: > To: mallman@icir.org > cc: "Ethan Blanton" , > "Aaron Falk" , "Ted Faber" , > touch@isi.edu, "Scott Bradner" > Bcc: > From: Sally Floyd > Subject: Re: Mark Allman: would this fly? > Date: Tue, 09 Aug 2005 13:45:18 -0700 > Sender: floyd@cougar.icir.org > > Mark - > > >> It is worth noting that if timestamps are being used, with the > >> currently-specified time constant for estimating the average RTT and > >> variance, then the first thing that needs to be done is to change > the > >> time constant so that the average RTT and the variance aren't being > >> estimated over a small fraction of a window of data (as is possible > >> when timestamps are used with current parameters). (Unless this has > >> already been fixed in recent standards, and I just missed it...) > > > >I don't think this has been fixed. And, I don't see this potential > i-d > >as the place to fix it. I wanted this to be an alternative response > to > >spurious timeouts, not some general RTO change. Does that make sense? > > It makes sense. Except that if in fact the average and variance are > being estimated over a small fraction of a window size, because > the TCP connection is using timestamps and has a moderate-to-large > congestion window, then the estimated variance might be very small > (because it is measured over RTTs calculated essentially from the > most recent N packets, for N < cwnd, and the burstiness for rtts for > the most recent fraction of a cwnd might be quite small). > > So in that situation, increasing the multiple of the variance might > have almost no effect on the RTO, because the variance might be > unrealistically small when calculated only over this small time > scale. And changing the weight for estimating the rtt average and > variance to make sure that the average RTT and variance are estimated > from RTTs calculated over a period of several rtts, might make your > technique much more powerful, by making the calculated variance > much more interesting and useful. Worth noting, at any rate. IMHO. > > - Sally _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 14:23:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWf9-00052l-MZ; Fri, 26 Jan 2007 14:23:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWf8-00051P-Di for tcpm@ietf.org; Fri, 26 Jan 2007 14:23:02 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWf6-0007Wc-QW for tcpm@ietf.org; Fri, 26 Jan 2007 14:23:02 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id A97B3C317 for ; Fri, 26 Jan 2007 14:22:57 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0QJMv4U019184; Fri, 26 Jan 2007 14:22:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0QJMun4026985; Fri, 26 Jan 2007 14:22:56 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id bLNRLtMFRBt8; Fri, 26 Jan 2007 14:22:56 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l0QJMtgJ026981;Fri, 26 Jan 2007 14:22:55 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 380314FE51; Fri, 26 Jan 2007 14:20:23 -0500 (EST) Date: Fri, 26 Jan 2007 14:20:23 -0500 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <20070126192022.GB12387@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: ah@tr-sys.de Subject: [tcpm] [ah@tr-sys.de: draft-ietf-tcpm-syn-flood-01] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This note on the TCP SYN flooding draft is forwarded with permission from its author. All of the suggested changes look right to me, and will show up in the next update of the draft. ----- Forwarded message from Alfred H=F6nes ----- From: Alfred H=F6nes Subject: draft-ietf-tcpm-syn-flood-01 To: weddy@grc.nasa.gov Date: Thu, 25 Jan 2007 10:15:56 +0100 (MEZ) Hello, after studying the Internet-Draft authored by you, draft-ietf-tcpm-syn-flood-01 , I'd like to submit a few comments, mostly addressing textual flaws I found in that memo. Generally, the presentation of the topic is very welcomed, it's over-due! Also, technical coverage seems to be complete and reasonable. Therefore, no specific objections! The items below address the remaining nits I found in the draft; they are presented in textual order, with one exception, at the end. To give more context, sometimes I quote larger blocks of text literally and show the replacement proposed using the shorthand notation: --- I use change bars ('|' in column 1) and occasionally up/down pointing marker lines ('^^^'/'vvv') to emphasize the location of textual issues and/or proposed corrections. Modified text has been re-adjusted to match RFC formatting rules, where appropriate. I also try to accomodate published RFC-Ed policy on style and punctuation etc. in my proposals. (1) Section 1, last paragraph: improper wording This majority of this document consists of three sections. [...] --- The majority of this document consists of three sections. [...] (2) Section 2.2, first paragraph: punctuation As described in RFC 793, a TCP implementation may allow the LISTEN | state to be entered with either all, some. or none of the pair of IP addresses and port numbers specified by the application. [...] --- ^ As described in RFC 793, a TCP implementation may allow the LISTEN | state to be entered with either all, some, or none of the pair of IP addresses and port numbers specified by the application. [...] (3) Section 2.2, 4th paragraph: word omission (?) [...]. In other systems that implement less complex TCP algorithms and options, the overhead may be less, although typically exceeds 280 bytes [SKK+97]. --- [...]. In other systems that implement less complex TCP algorithms and options, the overhead | may be less, although it typically exceeds 280 bytes [SKK+97]. (4) Section 3.7: two typos | Firewall-baed tactics may also be used to defend end-hosts from SYN flooding attacks. The basic concept is to offload the connection | establishment proceedures onto a firewall that screens connection attempts until they are completed and then proxies them back to protected end hosts. [...] --- | Firewall-based tactics may also be used to defend end-hosts from SYN flooding attacks. The basic concept is to offload the connection | establishment procedures onto a firewall that screens connection attempts until they are completed and then proxies them back to protected end hosts. [...] (5) Section 4, 2nd paragraph: typo Among end host modifications, the SYN cache and SYN cookie approaches | seem to be the only viable techniques discoverd. Increasing the backlog and reducing the SYN-RECEIVED timer are measurably problematic. [...] --- Among end host modifications, the SYN cache and SYN cookie approaches | seem to be the only viable techniques discovered. Increasing the backlog and reducing the SYN-RECEIVED timer are measurably problematic. [...] (6) Section 4, 4th paragraph: grammar In 1997, NetBSD incorporated a modified version of Borman's code. Two notable differences from the original code stem from the decision | to use of the cache by default (for all connections). This implied the need to perform retransmissions for SYN-ACKs, and to use larger structures to keep more complete data. [...] --- In 1997, NetBSD incorporated a modified version of Borman's code. Two notable differences from the original code stem from the decision | to use the cache by default (for all connections). This implied the need to perform retransmissions for SYN-ACKs, and to use larger structures to keep more complete data. [...] (7) Appendix A, 4th paragraph: grammar/typo vvvvvvvvvvvvvvvvvvv | With SYN cookies enabled, a host will be able to maintain responsive even when under a SYN flooding attack. [...] --- | With SYN cookies enabled, a host will be able to remain responsive even when under a SYN flooding attack. [...] (Or use: "maintain responsiveness" -- I prefer the shorter form above.) (8) Appendix A, 6th paragraph: word omission v | The best description of the exact SYN cookie algorithms is in part of an email from Bernstein, that is archived on the web site (notice it does not set the top five bits from the counter modulo 32, as the previous description did, but instead uses 29 bits from the second MD5 operation and 3 bits for the index into the MSS table; establishing the secret values is also not discussed): --- vvv | The best description of the exact SYN cookie algorithms is in a part of an email from Bernstein, that is archived on the web site (notice it does not set the top five bits from the counter modulo 32, as the previous description did, but instead uses 29 bits from the second MD5 operation and 3 bits for the index into the MSS table; establishing the secret values is also not discussed): And last, but not least: (9) Section 6 - Acknowledgements IMHO, the seminal work of D.J. Bernstein deserves a note in Section 6, in particular for its 'contribution' in Appendix A. Best regards, Alfred H=F6nes. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- End forwarded message ----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 14:42:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWxz-0007Px-Q0; Fri, 26 Jan 2007 14:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWxy-0007Pg-G5 for tcpm@ietf.org; Fri, 26 Jan 2007 14:42:30 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWxw-00029b-3e for tcpm@ietf.org; Fri, 26 Jan 2007 14:42:30 -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 l0QJgQ9C011424; Fri, 26 Jan 2007 11:42:27 -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 14997729E84; Fri, 26 Jan 2007 14:42:15 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D300616E703; Fri, 26 Jan 2007 14:42:17 -0500 (EST) To: David Borman From: Mark Allman Subject: Re: [tcpm] RFC 1323: Timestamps option In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Long May You Run MIME-Version: 1.0 Date: Fri, 26 Jan 2007 14:42:17 -0500 Message-Id: <20070126194217.D300616E703@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: TCP Maintenance and Minor Extensions WG 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="===============0561205673==" Errors-To: tcpm-bounces@ietf.org --===============0561205673== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline [obviously, without co-chair hat] Hi Dave- I am not going to vote yet. I want to try to understand what you write a little more ... > One of the things that you lose by deferring enabling Timestamps is > that you don't get the RTT measurements that Timestamps provide. > Without Timestamps, using the typical BSD algorithm of timing one > segment and waiting for an ACK, and adding in the Karn algorithm that > you have to invalidate any measurements if you had to retransmit in > that window, means that at best, you'll get one measurement per RTT. > At worst, you can get in a state where you never get a valid RTT > measurement. When you use the Timestamps option, the worst case is > that you'll only get one measurement per RTT, and the best case is > that you'll get multiple valid samples, So, + I agree that getting into a state whereby you never get an RTT measurement is Not Good. (Although, one could think of ways to avoid this and we might also decide this is pathological.) + Why is the "best case" that you'll get multiple samples per RTT? It seems to me that the underlying assumption is that "more is better", but I am not sure it is. We have done some analysis that suggests more samples are not better. I don't want to say our analysis is the last word here, but I'd be interested in hearing arguments for taking more samples [using the current RTO estimator] per RTT being a clear win. I think this is an important point in choosing a path. I.e., if multiple RTT measurements matter then that might suggest a different approach than if multiple RTTs buy you little/nothing. Ref: Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. Proceedings of the ACM SIGCOMM Technical Symposium, Cambridge, MA, September 1999. http://www.icir.org/mallman/papers/estimation.ps allman -- Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFulmZWyrrWs4yIs4RAoTPAJsHv98sOa6UQb0CK/qPH5ebQQxKTgCgmU/T Eke8avJJLNZ7TLzri6V1Gdw= =O51g -----END PGP SIGNATURE----- --=_bOundary-- --===============0561205673== 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 --===============0561205673==-- From tcpm-bounces@ietf.org Fri Jan 26 14:43:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWyl-0007dE-Et; Fri, 26 Jan 2007 14:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWyk-0007d6-CO for tcpm@ietf.org; Fri, 26 Jan 2007 14:43:18 -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 1HAWyi-0002Go-QD for tcpm@ietf.org; Fri, 26 Jan 2007 14:43:18 -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 l0QJh6bh008026; Fri, 26 Jan 2007 11:43:06 -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); Fri, 26 Jan 2007 11:43:06 -0800 Received: from [192.168.117.73] ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:43:06 -0800 In-Reply-To: References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] RFC 1323: Timestamps option Date: Fri, 26 Jan 2007 13:43:47 -0600 To: Sally Floyd X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Jan 2007 19:43:06.0464 (UTC) FILETIME=[333E8E00:01C74182] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Sally, Yes, thanks. That is one of the other open issue with 1323. Over the next week or so I'm planning on sending out individual emails for each of the other issues, so that they can be discussed individually, rather than trying to discuss them all in one big email thread. But since you brought it up, let's begin this thread now. :-) For the RFC, at a minimum we need to add a description of the problem, and say that implementors should take into account the more frequent timestamp values. I don't think we should trying to tell them exactly how to address the issue, but it'd be nice to have a reasonably example that could be easily implemented and achieve the desired effect. So, my idea is to use a two-tier approach. As without Timestamps, you record the sequence number to begin measuring the RTT. Until you get the ACK for that sequence number, you take all the measurements from the Timestamps options and average them together. Once the ACK for the sequence number returns, you take the averaged value and use that in the traditional RTO calculations, and reset the sequence number and averaged value. There are probably better algorithms, but this one is simple and should be fairly easy to implement, and would produce better results than the situation today where all the Timestamps are fed into the RTO calculation without adjusting for the increased frequency of the measurements. -David Borman On Jan 26, 2007, at 1:09 PM, Sally Floyd wrote: > David - > > I don't have any feedback about *when* to negotiate timestamps, but > I do have some feedback > about how the RTO should be estimated when timestamps are used. > Just as something > to include in a revision of RFC 1323... > > Regards, > - Sally > http://www.icir.org/floyd/ > > Here is some old email of mine on this: > >> To: mallman@icir.org >> cc: "Ethan Blanton" , >> "Aaron Falk" , "Ted Faber" , >> touch@isi.edu, "Scott Bradner" >> Bcc: >> From: Sally Floyd >> Subject: Re: Mark Allman: would this fly? >> Date: Tue, 09 Aug 2005 13:45:18 -0700 >> Sender: floyd@cougar.icir.org >> >> Mark - >> >> >> It is worth noting that if timestamps are being used, with the >> >> currently-specified time constant for estimating the average >> RTT and >> >> variance, then the first thing that needs to be done is to >> change the >> >> time constant so that the average RTT and the variance aren't >> being >> >> estimated over a small fraction of a window of data (as is >> possible >> >> when timestamps are used with current parameters). (Unless >> this has >> >> already been fixed in recent standards, and I just missed it...) >> > >> >I don't think this has been fixed. And, I don't see this >> potential i-d >> >as the place to fix it. I wanted this to be an alternative >> response to >> >spurious timeouts, not some general RTO change. Does that make >> sense? >> >> It makes sense. Except that if in fact the average and variance are >> being estimated over a small fraction of a window size, because >> the TCP connection is using timestamps and has a moderate-to-large >> congestion window, then the estimated variance might be very small >> (because it is measured over RTTs calculated essentially from the >> most recent N packets, for N < cwnd, and the burstiness for rtts for >> the most recent fraction of a cwnd might be quite small). >> >> So in that situation, increasing the multiple of the variance might >> have almost no effect on the RTO, because the variance might be >> unrealistically small when calculated only over this small time >> scale. And changing the weight for estimating the rtt average and >> variance to make sure that the average RTT and variance are estimated >> from RTTs calculated over a period of several rtts, might make your >> technique much more powerful, by making the calculated variance >> much more interesting and useful. Worth noting, at any rate. IMHO. >> >> - Sally > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 14:49:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAX4d-0001AN-RK; Fri, 26 Jan 2007 14:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAX4c-0001AG-GU for tcpm@ietf.org; Fri, 26 Jan 2007 14:49:22 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAX4Y-0003Lt-1u for tcpm@ietf.org; Fri, 26 Jan 2007 14:49:22 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.58.233]) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l0QJnHpS018591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jan 2007 14:49:17 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.13.1) with ESMTP id l0QJnHMM000773; Fri, 26 Jan 2007 14:49:17 -0500 Date: Fri, 26 Jan 2007 14:49:17 -0500 (EST) From: Matt Mathis To: David Borman Subject: Re: [tcpm] RFC 1323: Timestamps option In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Message-ID: References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: TCP Maintenance and Minor Extensions WG 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, 26 Jan 2007, David Borman wrote: > One of the topics that has been discussed in the past for the > revision of RFC 1323 is to relax the requirement on when to send the > Timestamps option. I'd like to come to some resolution on this issue. > > Current: > The Timestamps option is negotiated during the initial SYN exchange. > If both sides support it, then every packet in the connection has to > have the Timestamps option. ... snip ... > > My viewpoint > ------------ > Right now, I'm inclined to leave the Timestamps option alone; you > negotiate it during the SYN exchange, and then include it on every > packet. I'm willing to be convinced otherwise, but now I've placed a > stake in the ground, and the mailing list will have to decide if > there is sufficient reason to change the behavior. The real problem is a zero configuration issue: for the 100 million or so US home users on DSL (or worse, compressing modems), timestamps offer little gain and often substantial penalty. For the 10 Million(?) US university users, timestamps are necessary for good performance. Who do you think the manufacturers cater to? The simple answer is the home user, but many current systems use some sort of heuristic (e.g. is the interface faster than 100 Mb/s?). The current situation forces us to try to educate 9.99 million non-network savvy users how to inspect and tweak their kernels. I want ZERO config from at least 9.6 kbs to 9 Gbps. Some form of late timestamp negotiation is required before this can become the default. (BTW Japan and Europe, with true high speed to the home might change the equation quite a bit. This path leads to some ugly market positions.) Thanks, --MM-- P.S. The default WSCALE for MS Vista and mainline Linux is now 8 and 7 respectively for large memory systems, so the harder part of the zero config problem has already been solved. These correspond to 16 and 8 MByte TCP buffers. Roll out is going to take a while, but that will give people a chance to notice how the traffic might affect the network. QoS anyone? Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 14:56:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXBl-0005lP-75; Fri, 26 Jan 2007 14:56:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXBj-0005lC-Ho for tcpm@ietf.org; Fri, 26 Jan 2007 14:56:43 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXBh-0004cw-U8 for tcpm@ietf.org; Fri, 26 Jan 2007 14:56:43 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id CF50FF0C553; Fri, 26 Jan 2007 16:56:33 -0300 (ART) Received: from fgont.gont.com.ar (157-184-231-201.fibertel.com.ar [201.231.184.157]) (authenticated bits=0) by venus.xmundo.net (8.12.11.20060308/8.12.11) with ESMTP id l0QJuUvk006190; Fri, 26 Jan 2007 16:56:31 -0300 Message-Id: <200701261956.l0QJuUvk006190@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Jan 2007 16:56:14 -0300 To: David Borman , TCP Maintenance and Minor Extensions WG From: Fernando Gont Subject: Re: [tcpm] RFC 1323: Timestamps option In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> 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-2.0.2 (venus.xmundo.net [201.216.232.56]); Fri, 26 Jan 2007 16:56:32 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi David, I'm inclined for option #3, too. Some comments inline.... >Option #2 >--------- [....] >The question then is, how do you negotiate Timestamps without turning >them on? My suggestion would be to send a Timestamps option with the >special format TSval=0,TSecr=0. If you receive this in a SYN, then >the request is to negotiate knowledge of the Timestamps option. The >returning SYN,ACK would also need to contain TSval=0,TSecr=0 to >complete the negotiation. If you are connecting to a site that >doesn't support this feature but does support Timestamps, it would >respond with TSval=xxx,TSecr=0. At that point, Timestamps are now >enabled. The downside of this is that now the originator has started >their Timestamps values at 0, and must continue from there with their >timestamps; they can't just suddenly jump to some arbitrary value >because that could break PAWs. IIRC, there are some implementations that randomize the TCP sequence number, but use monotonically increasing timestamp generator. Those implementations would cause, the BSD hack of allowing the establishment of a new connection if the ISN of the new incarnation of the conenction is larger than the last seq number seen on the old connection to fail fail. IIRC, Linux also takes into account the Timestamp. Thus, if you randomize the ISN, but use a monotonically increasing timestamp generator, the hack would still succeed. However, option #2 above would break this. [....] >So why should we change things? My recollection was that the primary >motivation was to conserve option space, to avoid having to put in >the extra 12 bytes of TCP options on every packet until we get to the >point where the sequence space might wrap, and then turn them on so >that we can get PAWS to protect the rest of the connection. I assume this means that one would turn timestamps on when starting a bulk transfer on the connection (?). If so I'm not sure the space we'd be saving would be worth the additional complexity: For most application protocols usually employed for bulk transfers, the bulk transfer is preceded by only a few packets (to establish the TCP connection and send the application request). So option space would be saved in only a few segments. Am I missing something? Also, in order to enable timestamps midstream, I guess applications should perform a call to setsockopt() or the like? If so, this require specification of the corresponding socket option, would require applications to be modified, and we would also requier us to agree on "what the option should default to", etc. So, unless some strong reason is raised for going with option #1 or option #2, I would stick with option #3. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 15:05:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXJm-0002lP-JY; Fri, 26 Jan 2007 15:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXJl-0002lI-UF for tcpm@ietf.org; Fri, 26 Jan 2007 15:05:01 -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 1HAXJj-00066k-Gv for tcpm@ietf.org; Fri, 26 Jan 2007 15:05:01 -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 l0QK4ruK012031; Fri, 26 Jan 2007 12:04:53 -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); Fri, 26 Jan 2007 12:04:53 -0800 Received: from [192.168.117.73] ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:04:53 -0800 In-Reply-To: <20070126194217.D300616E703@lawyers.icir.org> References: <20070126194217.D300616E703@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] RFC 1323: Timestamps option Date: Fri, 26 Jan 2007 14:05:34 -0600 To: mallman@icir.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Jan 2007 20:04:53.0442 (UTC) FILETIME=[3E439220:01C74185] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: TCP Maintenance and Minor Extensions WG 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 You've probably already seen my reply to Sally, but I'll clarify a few things: On Jan 26, 2007, at 1:42 PM, Mark Allman wrote: > + Why is the "best case" that you'll get multiple samples per > RTT? It > seems to me that the underlying assumption is that "more is > better", > but I am not sure it is. We have done some analysis that suggests > more samples are not better. I don't want to say our analysis is > the last word here, but I'd be interested in hearing arguments for > taking more samples [using the current RTO estimator] per RTT > being > a clear win. > > I think this is an important point in choosing a path. I.e., if > multiple RTT measurements matter then that might suggest a > different > approach than if multiple RTTs buy you little/nothing. Perhaps "best case" was the wrong term. Being guaranteed at least one good RTT measurement per RTT is a good thing. The current RTO estimator is based on getting one sample per RTT, no matter how much data flows during that time. As you know, when you start using all the samples from multiple Timestamps options, if you just feed them into the current RTO estimator it can seriously skew the results, especially if you are getting lots of samples per RTT. In my reply to Sally, I suggested taking the average of all the Timestamps received during one RTT, and feeding that into the RTO estimator. An alternative would be to take the largest sample received during the RTT interval, and feed that into the estimator. That'd be even easier to implement. Do you have any thoughts as to which would be better? Another alternative would be to only use the sample from the Timestamps option in the ACK for the sequence number that is being timed, i.e. back to one sample per RTT. But that is still a win over the old method, because with Timestamps, we know that the measurement will always be accurate, even if there was a retransmission during the RTT. But I totally agree, just feeding in the more frequent samples from the Timestamps into the RTO estimator is not a good thing. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 16:09:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYJu-0006dI-Sl; Fri, 26 Jan 2007 16:09:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYJu-0006dC-Bu for tcpm@ietf.org; Fri, 26 Jan 2007 16:09:14 -0500 Received: from [2001:770:68:ff::1] (helo=kac.cnri.dit.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYJr-0007kx-Sd for tcpm@ietf.org; Fri, 26 Jan 2007 16:09:14 -0500 Received: from kac.cnri.dit.ie (localhost.cnri.dit.ie [127.0.0.1]) by kac.cnri.dit.ie (8.13.4/8.13.4) with ESMTP id l0QL90a0027831; Fri, 26 Jan 2007 21:09:02 GMT (envelope-from dwmalone@kac.cnri.dit.ie) Message-Id: <200701262109.l0QL90a0027831@kac.cnri.dit.ie> To: David Borman Subject: Re: [tcpm] RFC 1323: Timestamps option In-Reply-To: Your message of "Fri, 26 Jan 2007 12:33:29 CST." <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> From: David Malone Date: Fri, 26 Jan 2007 21:09:00 +0000 X-Spam-Score: -2.8 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > The rules for enabling Timestamps mid-stream would be: > 1) If you receive a Timestamps option mid-stream, you can enable > Timestamps. From then on, every packet sent will need to contain a > Timestamps option. Based on some of the behaviour noted in: http://www.caida.org/publications/papers/2005/fingerprinting/ It seems some implementations have already effectively chosen Option #1. David. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 26 20:42:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcZ6-0004xU-Sl; Fri, 26 Jan 2007 20:41:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcZ5-0004xO-JH for tcpm@ietf.org; Fri, 26 Jan 2007 20:41:11 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAcYy-0000eC-Rj for tcpm@ietf.org; Fri, 26 Jan 2007 20:41:11 -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 l0R1f326023918; Fri, 26 Jan 2007 17:41:03 -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 CD5A972BCDC; Fri, 26 Jan 2007 20:40:51 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E88AF16E90F; Fri, 26 Jan 2007 20:40:54 -0500 (EST) To: David Borman From: Mark Allman Subject: Re: [tcpm] RFC 1323: Timestamps option In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Long May You Run MIME-Version: 1.0 Date: Fri, 26 Jan 2007 20:40:54 -0500 Message-Id: <20070127014054.E88AF16E90F@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: TCP Maintenance and Minor Extensions WG 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="===============1797200908==" Errors-To: tcpm-bounces@ietf.org --===============1797200908== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > You've probably already seen my reply to Sally, but I'll clarify a > few things: Yes - I just read it (although, I am a bit behind on the thread, so apologies if some of the stuff below has been said). But, I think it is orthogonal to my concern. Likely, I am not stating things well. Sally's observation (and, she is not the only one to make it over the years) is that the current TCP RTO algorithm keeps history in terms of the *number* of samples taken. So, if you take two RTT samples per RTT as opposed to one then you are keeping half as much history in *time units*. I think we all agree with this and that it should be addressed **when a TCP connection is taking more than one RTT sample per RTT**. Exactly how we address it is a discussion we can have (averaging samples into one per RTT that is fed to the estimator, taking the max sample per RTT, adjusting the EWMA gains based on the cwnd, etc.). This problem manifests itself *when* we take multiple samples per RTT. What I am asking about is *whether* we need multiple samples per RTT. It seems to me that your notes assume somehow that more than one sample per RTT is useful. Why? Or, > Being guaranteed at least one good RTT measurement per RTT is a good > thing. Why? (I don't mean to be flip. Surely one good RTT sample per RTT is a fine goal. The "why?" is in response to the "guaranteed" part of your statement.) Clearly we want an evolution of the RTO to take into account changing RTTs and the variance in the RTT. So, we don't want to use a static number and we do not want to take a single sample and then stop (although, actually, this latter does not perform too bad). Let me try to put this a different way... what is the problem with the non-TS one sample / RTT sampling technique? You have noted a couple of things: + That we might not be able to get *any* RTT sample. + That Karn's algorithm means that during some RTTs we will not get a sample. + (Are there others?) The first of these is a clear problem that using the TS option from the beginning can solve (although, a small tweak to retransmit SYNs with timestamps even if the original did not have a TS may well fix this). I do wonder how much I should care about this case. It seems like it will be exceedingly rare to get into this situation and further even if we do I am not sure I care about performance (if that means including a 12-byte blob on every packet sent for this express reason). The second case above is for sure true. But, the question is does it matter at all? In other words, what is the impact on the RTO of getting a sample during these RTTs as opposed to not? I ask these questions to test the assumptions. My own thinking goes like this .... Timestamps are essentially a general disambiguation mechanism. There is a clear need for some form of disambiguation when the sequence space wraps too quickly. That mechanism does not have to be timestamps, but they work fine. However, such a disambiguation scheme is not needed when the sequence space cannot wrap too quickly. RFC 1323 also laid out a couple reasons for using a disambiguation mechanism for RTT timing. One of those is because the ambiguity leads to no RTT samples in some situations (i.e., when we retransmit). The other item is the [what I would consider] conjecture that more RTT samples help the RTO. In the time since RFC 1323 was published I think there is some evidence that says that the need for disambiguation for RTT sampling is thin. Maybe I am biased by my own work. Our work is one data point. What I am really looking for is other work / evidence / experience that makes the case that we need disambiguation for RTT sampling in anything but corner cases and then what do we gain from this disambiguation? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFuq2mWyrrWs4yIs4RAhshAJ9ALbrExuwX0HWtm28XRhHDDvv1gQCdGq/7 K6F+yG9EvJ66dCMqvjrcc5w= =0X3W -----END PGP SIGNATURE----- --=_bOundary-- --===============1797200908== 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 --===============1797200908==-- From tcpm-bounces@ietf.org Fri Jan 26 20:48:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcfd-0007wK-8F; Fri, 26 Jan 2007 20:47:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAcfc-0007w3-99 for tcpm@ietf.org; Fri, 26 Jan 2007 20:47:56 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAcfa-0001j4-UD for tcpm@ietf.org; Fri, 26 Jan 2007 20:47:56 -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 l0R1loD8024101; Fri, 26 Jan 2007 17:47:50 -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 CBFDF72BD41; Fri, 26 Jan 2007 20:47:38 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C815016E94F; Fri, 26 Jan 2007 20:47:41 -0500 (EST) To: Fernando Gont From: Mark Allman Subject: Re: [tcpm] RFC 1323: Timestamps option In-Reply-To: <200701261956.l0QJuUvk006190@venus.xmundo.net> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Long May You Run MIME-Version: 1.0 Date: Fri, 26 Jan 2007 20:47:41 -0500 Message-Id: <20070127014741.C815016E94F@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: TCP Maintenance and Minor Extensions WG , David Borman 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="===============2052358480==" Errors-To: tcpm-bounces@ietf.org --===============2052358480== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > I assume this means that one would turn timestamps on when starting a > bulk transfer on the connection (?). > > If so I'm not sure the space we'd be saving would be worth the > additional complexity: For most application protocols usually employed > for bulk transfers, the bulk transfer is preceded by only a few > packets (to establish the TCP connection and send the application > request). So option space would be saved in only a few segments. > > Am I missing something? > > Also, in order to enable timestamps midstream, I guess applications > should perform a call to setsockopt() or the like? If so, this require > specification of the corresponding socket option, would require > applications to be modified, and we would also requier us to agree on > "what the option should default to", etc. My view is that the application would not have to be involved. The app is not involved in whether to use timestamps or not right now. (Setting the socket buffer quite large could be seen as a proxy of this, I suppose.) In any case, I don't think you need to worry about knowing a file is big or not. In order to need TS for PAWS you have to send 4GB of data (i.e., wrap). It should be easy enough to turn TS on after 3GB or something. (It really isn't the amount of data being sent, it is the data rate that PAWS is protecting against and so you could come up with a better test than simply testing the number of bytes sent---my point is that without actually wrapping we don't have to worry about TS for PAWS.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFuq89WyrrWs4yIs4RAp35AKCM2lj0LRQLKT/uv4/c4CSF90irWwCghewW eTsLi/+1LCgmmPdmvn8sROQ= =+1dW -----END PGP SIGNATURE----- --=_bOundary-- --===============2052358480== 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 --===============2052358480==-- From tcpm-bounces@ietf.org Sat Jan 27 07:23:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAmZ9-0001wl-C5; Sat, 27 Jan 2007 07:21:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAmZ7-0001we-Ux for tcpm@ietf.org; Sat, 27 Jan 2007 07:21:53 -0500 Received: from starburst.demon.co.uk ([80.176.229.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAmZ6-0000q3-F6 for tcpm@ietf.org; Sat, 27 Jan 2007 07:21:53 -0500 Received: (from richard@localhost) by starburst.demon.co.uk (8.11.6/8.11.6) id l0RCLmQ25484; Sat, 27 Jan 2007 12:21:48 GMT From: Richard Wendland Message-Id: <200701271221.l0RCLmQ25484@starburst.demon.co.uk> Subject: Re: [tcpm] RFC 1323: Timestamps option To: david.borman@windriver.com (David Borman) Date: Sat, 27 Jan 2007 12:21:47 +0000 (GMT) In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> from "David Borman" at Jan 26, 2007 12:33:29 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: richard@codeburst.co.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A difficulty with the suggested enabling mechanism for Option #2 is that a major TCP stack already (mis)behaves in a similar way for current TCP connections. > Option #2 > --------- ... > The question then is, how do you negotiate Timestamps without turning > them on? My suggestion would be to send a Timestamps option with the > special format TSval=0,TSecr=0. If you receive this in a SYN, then > the request is to negotiate knowledge of the Timestamps option. The > returning SYN,ACK would also need to contain TSval=0,TSecr=0 to > complete the negotiation. The Windows TCP stack currently replies SYN,ACK TSval=0,TSecr=0 to a regular SYN TSval=xxx,TSecr=0. So if you send SYN TSval=0,TSecr=0, and get back SYN,ACK TSval=0,TSecr=0 you may be talking to a TCP stack that understands the new enabling semantics, or a Windows TCP stack that does not. You could argue this does not really matter, as the Windows TCP stack will go on using Timestamps (I presume), immediately enabling it on the fly under the new semantics, so in the end all is fairly well (except Windows TCP may be sent a few segments with no Timestamps that it does not expect, until on the fly enabling is completed). However I don't think this confusing situation is desirable. I think Windows TCP behaves in this way because it does not create a full TCP state block until after SYN,ACK processing, so has nowhere to record the initial TSvals. If we are updating RFC1323, I wonder if this Windows behaviour should be explicitly allowed, since in practice we have to allow for it now, and it has some merit. Trying to find legitimacy for the Windows TCP behaviour, it could be said that 3.2 of RFC1323 wasn't entirely clear in this regard. It says "When TSecr is not valid, its value must be zero." - I can conceive of this being understood (out of context) as meaning: if you do not have a valid TSecr available for some reason, then send a zero; an interpretation that would permit the Windows TCP behaviour, and make the suggested enabling mechanism ambiguous. Richard -- Richard Wendland richard@codeburst.co.uk _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 27 11:11:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAq80-0006wC-Rt; Sat, 27 Jan 2007 11:10:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAq7z-0006vA-Fj for tcpm@ietf.org; Sat, 27 Jan 2007 11:10:07 -0500 Received: from whisker.bluecoat.com ([216.52.23.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAq7y-0004CF-4B for tcpm@ietf.org; Sat, 27 Jan 2007 11:10:07 -0500 Received: from bcs-mail2.internal.cacheflow.com (bcs-mail2.internal.cacheflow.com [10.2.2.59]) by whisker.bluecoat.com (8.13.8/8.13.8) with ESMTP id l0RGA5s5028559 for ; Sat, 27 Jan 2007 08:10:05 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7422D.9835D213" Date: Sat, 27 Jan 2007 08:09:59 -0800 Message-ID: <305C539CA2F86249BF51CDCE8996AFF41CD82F@bcs-mail2.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: <305C539CA2F86249BF51CDCE8996AFF41CD82F@bcs-mail2.internal.cacheflow.com> Thread-Topic: RFC 1323: Timestamps option Thread-Index: AcdBtFAhtdPDC+HbT/iEHwlRubDA4AAdt9Q7 References: From: "Mahdavi, Jamshid" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [tcpm] RE: RFC 1323: Timestamps option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7422D.9835D213 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to echo some of the comments from Matt and Mark, I've always felt = that the overhead of 12 bytes per packet (and ACK) was pretty unbearable = and usually recommend for turning off timestamps if that is possible in = an application. Clearly, we need some solution for PAWS, and I think the comments about = turning on timestamps based on rate or volume of data sent in those = cases make good sense, so I'd be in favor of that. For the cases where you don't need timestamps for PAWS, why not simply = allow a host to transmit a timestamp option whenever it wants to measure = the RTT? Then hosts would have the freedom to use timestamps at = whatever rate they feel is best. Having read some of the comments about = frequency of measurements, it occurs to me that it might actually be = better to do one measurement per fixed unit of time (say, once per = second) rather than once per packet or once per RTT. I don't think = there would be any reason to think that variability of network delay = would be correlated to RTT; it seems much more likely to be correlated = to fixed constants in the network (like routing protocol update = intervals) or fixed constants in the real world (like business hours). Of course, from my point of view the advantage to this is that you'd be = adding 24 bytes per second (or whatever the chosen interval is) to the = data transmitted rather than 18 bytes per packet (taking into account = delayed ACK) which is more than 1% additional overhead for fairly = nebulous benefit. I realize this suggestion would probably require a more significant = change to the operation of the timestamp option, but I think it would be = worthwhile. --J ------_=_NextPart_001_01C7422D.9835D213 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgEQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAIAAAAFJFOiBSRkMgMTMyMzogVGlt ZXN0YW1wcyBvcHRpb24A7wkBBYADAA4AAADXBwEAGwAIAAkAOwAGAEwBASCAAwAOAAAA1wcBABsA CAAJADsABgBMAQEJgAEAIQAAADE2NkY2RjMwMDJBREQxNDU4MjZGMUFGRTY1MjRCMjE0ABQHAQOQ BgD0CwAAOQAAAAMAJgAAAAAAAwA2AAAAAABAADkAE9I1mC1CxwEeAD0AAQAAAAUAAABSRTogAAAA AAIBRwABAAAANgAAAGM9VVM7YT0gO3A9Q0FDSEVGTE9XO2w9QkNTLU1BSUwyLTA3MDEyNzE2MDk1 OVotMTAyMjg0AAAAHgBJAAEAAAAdAAAAdGNwbSBEaWdlc3QsIFZvbCAzMywgSXNzdWUgNwAAAABA AE4AgMI3OrRBxwEeAFoAAQAAABYAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAACAVsAAQAAAEkA AAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAU01UUAB0Y3Bt LXJlcXVlc3RAaWV0Zi5vcmcAAAAAAgFcAAEAAAAbAAAAU01UUDpUQ1BNLVJFUVVFU1RASUVURi5P UkcAAB4AXQABAAAAFgAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwAAAAIBXgABAAAASQAAAAAAAACB Kx+kvqMQGZ1uAN0BD1QCAAAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwBTTVRQAHRjcG0tcmVxdWVz dEBpZXRmLm9yZwAAAAACAV8AAQAAABsAAABTTVRQOlRDUE0tUkVRVUVTVEBJRVRGLk9SRwAAHgBm AAEAAAAFAAAAU01UUAAAAAAeAGcAAQAAABYAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAAeAGgA AQAAAAUAAABTTVRQAAAAAB4AaQABAAAAFgAAAHRjcG0tcmVxdWVzdEBpZXRmLm9yZwAAAB4AcAAB AAAAHAAAAFJGQyAxMzIzOiBUaW1lc3RhbXBzIG9wdGlvbgACAXEAAQAAABsAAAABx0G0UCG108ML 4dtP+IQfCVG5sMDgAB231DsAHgB0AAEAAAAOAAAAdGNwbUBpZXRmLm9yZwAAAB4AGgwBAAAAEQAA AE1haGRhdmksIEphbXNoaWQAAAAAHgAdDgEAAAAcAAAAUkZDIDEzMjM6IFRpbWVzdGFtcHMgb3B0 aW9uAAIBCRABAAAA5wQAAOMEAACvBwAATFpGdSfI9e4DAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/ CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjv Cfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMKgIhKdXMFQHRvIAWQCmgdsHMDcGUgb2btHZBo HlAFoG0HgAIwBCCrA1IF0GECQCAAcGQfsYByaywgSSd2HlCRB0B3YXkfUWVsHYGvE+Ahoh5RINBy HrBhIDBjHnEOICBieQ6wBCBwkxKBCrBjaxQgICggEuBBQ0spICEgI4EYIEECQHkgdW5iIqByXQGg bCDhICEdYHUHQGy/JYAYIB7kIDACEAXAdAhweQMAbmceYR6BB3IBkG2+cAQgBpAhtAQAI5BvBBDe aSYSC4AgASAAcAtQDeC1H9BpAiAuHPQc9EMmINcKwCbgIJB3HlBuCeAgMB8eIx4gCkArciejUEFX tlMgkCASSR6RC4BrHpy/AaAIYB2BKAYDoCi5YiUAvy1hLkEl8A6wHmAFwHYt8fUeRGQf0GEeEB8h KpIeoD8qIB7BMnEEIADAJBAgZ/5vBHA0UhQQIJAeICChIDDzJcAqkmZhM3AFwB5zH9DdK7tGJ8Ie sjVTdx6wGCDcIHkIYDQAAiAnBUAtQ88ouS54OgAlgG5vBUAAkPcpICbhJsFvB+A0QDTxHYPmdCXw AIBtaR/xKKgeYP8FMC4yOgEtQCJhKVAFQCEgfx8yHaEHgCUACHAeUB6iUsBUVD8gIFRAYT4D+znh CGBsIDAT4CDRHqIDUP8tUR+RHaEdYEIBKMgh4ToA/zMBQKIy8x6hJYAhcCGAKdLrJcAdcC5CoEg3 kCgyGCAvIrEeLzBoRGFxClBuYz8lgB5xQaUfEyCQPvFvYz5jCHBBVSmFBUA+4Gdo/R/xYyfwJsM3 ISXAAkASgT8doTqgMXFJQEuZI5Nmab54LWEloExyKJQkQHMhMPsgkAIgY0lAI6IUEAWgICD/JNAy 8ToRIbIDoFK3I+U3sv9SxkJhSCEvUDqkL3c6MUN0/zchAHAm8iUAMYI+cS+FIeH2dgrABzBiAxA+ 8EtDLUD+dENwIHA0ACGAITBX2AWhvxggC2AOsDsxHbBCYTtA0u8UEEvwNYEa0Gg1kAWwSUD/KzAk ECbhHaFcP1EkU2Eo8e8fMjSzLSJbFChewicAMMG/KDIlMDzwTKAG8CWQcDQR5yqCT0FaAGxzJNAF sWB/v2GESMEDIFshQ6FiZGIdYF8LgAeQBCAd8EzRKSu7T98egAWgTNE2gR9zbSWAKhD/ZEFJUkhw B9EeoiKwWgACMPxhZ0IBWTMpQUFRIdI6Ycs29CKwZCgyMjQjOVNE/yRABbFGNx6jNPIDoGRGKdF/ JNBZI0lANBM+llzSU8ox7jgjPyRAAZBrKDJkQR2w/wDQaZE0gVtzLWEkpC+AXkH3KeFec3PUJW3T K3JmsSJX+yeyN4BpLMEtMWegF7AdYD83ES1AUSA4TC9QZpJpevdCAinhJqBnbCAdcEATQ4P/Y0Ey YAJgJvJK8HqAIOFeZP0AkGcDAFEgK1A0gRPRKED/bDVJQSOhK2NJVj9OIJBnoP8FQC9WQOJX9lsh HqB3gSYgUSu7LS1KK8p9h+AAHgA1EAEAAABKAAAAPDMwNUM1MzlDQTJGODYyNDlCRjUxQ0RDRTg5 OTZBRkY0MUNEODJGQGJjcy1tYWlsMi5pbnRlcm5hbC5jYWNoZWZsb3cuY29tPgAAAB4AORABAAAA JgAAADxFMUhBY1o3LTAwMDR4Yy00MkBtZWdhdHJvbi5pZXRmLm9yZz4AAAAeAEcQAQAAAA8AAABt ZXNzYWdlL3JmYzgyMgAACwDyEAEAAAAfAPMQAQAAAFAAAABSAEUAJQAzAEEAIABSAEYAQwAgADEA MwAyADMAJQAzAEEAIABUAGkAbQBlAHMAdABhAG0AcABzACAAbwBwAHQAaQBvAG4ALgBFAE0ATAAA AAsA9hAAAAAAQAAHMBX+cS8rQscBQAAIMMG9QZgtQscBAwDeP69vAAADAPE/CQQAAB4A+D8BAAAA EQAAAE1haGRhdmksIEphbXNoaWQAAAAAAgH5PwEAAABUAAAAAAAAANynQMjAQhAatLkIACsv4YIB AAAAAAAAAC9PPUNBQ0hFRkxPVy9PVT1DRi1CQVkvQ049UkVDSVBJRU5UUy9DTj1KQU1TSElELk1B SERBVkkAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAA ANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1A AAAAAAMAHkAAAAAAHgAwQAEAAAAQAAAASkFNU0hJRC5NQUhEQVZJAB4AMUABAAAAEAAAAEpBTVNI SUQuTUFIREFWSQAeADJAAQAAABYAAAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAAeADNAAQAAABYA AAB0Y3BtLXJlcXVlc3RAaWV0Zi5vcmcAAAAeADhAAQAAABAAAABKQU1TSElELk1BSERBVkkAHgA5 QAEAAAACAAAALgAAAAMAdkD/////CwApAAAAAAALACMAAAAAAAMABhBJXo22AwAHEDQFAAADABAQ AAAAAAMAERAAAAAAHgAIEAEAAABlAAAASlVTVFRPRUNIT1NPTUVPRlRIRUNPTU1FTlRTRlJPTU1B VFRBTkRNQVJLLElWRUFMV0FZU0ZFTFRUSEFUVEhFT1ZFUkhFQURPRjEyQllURVNQRVJQQUNLRVQo QU5EQUNLKVdBUwAAAAACAX8AAQAAAEoAAAA8MzA1QzUzOUNBMkY4NjI0OUJGNTFDRENFODk5NkFG RjQxQ0Q4MkZAYmNzLW1haWwyLmludGVybmFsLmNhY2hlZmxvdy5jb20+AAAA7C4= ------_=_NextPart_001_01C7422D.9835D213 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_001_01C7422D.9835D213-- From tcpm-bounces@ietf.org Mon Jan 29 00:09:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOku-0004Mg-EV; Mon, 29 Jan 2007 00:08:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBOkt-0004Mb-8S for tcpm@ietf.org; Mon, 29 Jan 2007 00:08:35 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBOkp-0007iO-UQ for tcpm@ietf.org; Mon, 29 Jan 2007 00:08:35 -0500 Received: from jurassic.eng.sun.com ([129.146.228.50]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0T58VHA021678; Sun, 28 Jan 2007 22:08:31 -0700 (MST) Received: from [192.9.61.50] (punchin-kcpoon.SFBay.Sun.COM [192.9.61.50]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0T58P0O113295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jan 2007 21:08:26 -0800 (PST) Message-ID: <45BD8148.8040504@sun.com> Date: Mon, 29 Jan 2007 13:08:24 +0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Thunderbird 1.5.0.9 (X11/20061229) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] RFC 1323: Timestamps option References: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> In-Reply-To: <018977E8-C9F4-42E2-A877-95330F65E7D3@windriver.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: TCP Maintenance and Minor Extensions WG 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: > Option #3 > --------- > Do nothing, and leave Timestamps alone as they are currently defined. > You negotiate them in the SYN, and then include them in every packet > from then on. As an implementor, I'd vote for Option #3. If the current behavior is not broken, don't fix it. Modifying it after so many years of deployment may cause many troubles. IMHO, the benefit of modifying the handling, which is saving 12 bytes, is minor when compared to the effort of diagnosing why a connection is not working. If we want to fix the overhead and other issues, such as auto-tuning, I'd rather to have a new option or other methods than modifying the current handling. I'd like to have several clarifications on timestamps handling. 1. I think it is not stated explicitly that once timestamps option is enabled, it should always be used for a connection. I have encountered TCP stack which stops sending timestamps option in the middle of a connection. Could this be made explicitly in the update? I also suggest putting a note on how to handle such behavior. For example, once one side stops sending the option, the peer will treat it as if the option is never negotiated and also stops using it. 2. As described in CERT VU#637934, there are some inconsistencies in RFC 1323 and the not "published" RFC 1323bis. This creates some "variants" of algorithms. Since this update will obsolete both documents, please check the CERT report on the issues and clarify it on the update. 3. It is stated that RST should not have a timestamps option. I think this is really not needed. And it only causes extra check in the code not to do that. For example, an app does an abortive close, the code needs to remove the timetstamps option from the connection to send the RST. I don't think it causes any harm if the RST has the option. -- K. Poon. kacheong.poon@sun.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 29 08:25:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWUt-0005dJ-0p; Mon, 29 Jan 2007 08:24:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWUs-0005dE-8P for tcpm@ietf.org; Mon, 29 Jan 2007 08:24:34 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBWUm-0002f3-Ea for tcpm@ietf.org; Mon, 29 Jan 2007 08:24:34 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0TDLQOQ008821 for ; Mon, 29 Jan 2007 15:21:44 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 15:24:19 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 15:24:18 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070118012440.GC1540@hut.isi.edu> References: <20070118012440.GC1540@hut.isi.edu> Message-Id: <77BF57F4-215F-4015-971B-36335B975951@nokia.com> From: Lars Eggert Date: Mon, 29 Jan 2007 15:24:17 +0200 To: tcpm@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 13:24:18.0933 (UTC) FILETIME=[C7D1CA50:01C743A8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [tcpm] AD review of draft-ietf-tcpm-tcp-antispoof-05.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: , Content-Type: multipart/mixed; boundary="===============0572409739==" Errors-To: tcpm-bounces@ietf.org --===============0572409739== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-643813011; protocol="application/pkcs7-signature" --Apple-Mail-18-643813011 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-18, at 3:24, ext Ted Faber wrote: > This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. I did my AD review during WGLC to speed up things a bit. Overall, this is a very solid document that is ready for publication. There are some minor boilerplate and spelling/grammar issues. Since I know Joe uses Word, turn on spelling and grammar checks :-) If there are more substantial comments that would require a revision now, fix these nits, too, otherwise they can wait until AUTH48. > At 1 Mbps, 57,000 (40 > byte) RSTs would take over 50 minutes to transmit, and, as noted > earlier, most current connections are fairly brief by comparison. 57000*8*40 = 18,240,000 bits need 18.24 seconds with 1Mbps Lars --Apple-Mail-18-643813011 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkxMzI0MThaMCMGCSqGSIb3DQEJBDEWBBTx9R295K00AH90 Ys35zrqI8A7N4DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAPRhm8lC+0Jtawq9Ck+pEL2FUTVe9z+zPJIk/d1ECJOnpM0+5jtWF 1x6FcXY/zRqRhBE5noLissmOtYbF8IiF183Wb2CLHqdTo0iw95p+/RMt+rbaXJ3s0NOXDRPMc0dr TFN93fdH3CO+rq7ROD1JCA2L9fVIIaTx0Llmy9M5iRGbs3iH7xVLr/2Z+QuOP4JRwozuMdDzjz6V E5KlhsjLVV3vp9xeiBLL2NVwfgDVaJaWWP2SAqaqN8d68iH/WnEFgMhpgpacxYE72Guk8TuCjX6c cCgX8RJCX4hxc9v+7IvLjb3GrzheAUz6l8jvuvlb+ZHHCO9gbR+uMnXSkHGJyQAAAAAAAA== --Apple-Mail-18-643813011-- --===============0572409739== 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 --===============0572409739==-- From tcpm-bounces@ietf.org Mon Jan 29 10:56:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYr9-0008Mq-Cc; Mon, 29 Jan 2007 10:55:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYr7-0008KF-PX for tcpm@ietf.org; Mon, 29 Jan 2007 10:55:41 -0500 Received: from mail.nuim.ie ([149.157.1.19] helo=LARCH.MAY.IE) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYqg-0005fn-7e for tcpm@ietf.org; Mon, 29 Jan 2007 10:55:41 -0500 Received: from retina-bcl.hamilton.local ([149.157.192.252]) by NUIM.IE (PMDF V6.2-X17 #30789) with ESMTPA id <01MCI9KKHBI8013D71@NUIM.IE> for tcpm@ietf.org; Mon, 29 Jan 2007 15:55:33 +0000 (GMT) Received: from gavinmc by retina-bcl.hamilton.local with local (Exim 4.50) id 1HBYqY-0001Ah-Sw for tcpm@ietf.org; Mon, 29 Jan 2007 15:55:06 +0000 Date: Mon, 29 Jan 2007 15:55:06 +0000 From: Gavin McCullagh Subject: Re: [tcpm] RFC 1323: Timestamps option In-reply-to: To: tcpm@ietf.org Message-id: <20070129155506.GG27467@nuim.ie> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20070126194217.D300616E703@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin McCullagh List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, On Fri, 26 Jan 2007, David Borman wrote: > But I totally agree, just feeding in the more frequent samples from > the Timestamps into the RTO estimator is not a good thing. Indeed. Naturally, it is possible to adjust the RTO estimation to be able to deal with receiving estimates more often, or even irregularly. Quite a few OSes (eg Darwin, I think?) use a RTO timer (and time stamps) that ticks every half a second, and so effectively rounds up to the nearest 500ms. I guess this shows that it doesn't matter too much what you do, as long as you give a reasonable overestimate. It is conceivable that people might want to use timestamps for things other than RTO estimation. Some of the high-speed TCP variants want more RTT samples (we're playing with one that expects an RTT sample per ACK at the moment). I don't think any of the suggested new behaviours would cause problems with these uses, but it may be worth keeping in mind while updating RFC 1323. As an example of a more exotic use of the time stamp option, the most recent version of FreeBSD's syncookies stashes information in the timestamp: http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011651.html Gavin _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 29 11:16:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZBQ-00024j-RC; Mon, 29 Jan 2007 11:16:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZBP-00024c-44 for tcpm@ietf.org; Mon, 29 Jan 2007 11:16:39 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZBB-0000Up-E1 for tcpm@ietf.org; Mon, 29 Jan 2007 11:16:39 -0500 Received: from [127.0.0.1] (111.sub-75-214-105.myvzw.com [75.214.105.111]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0TGG6GI010843; Mon, 29 Jan 2007 08:16:09 -0800 (PST) Message-ID: <45BE1DC5.6020101@isi.edu> Date: Mon, 29 Jan 2007 08:16:05 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] AD review of draft-ietf-tcpm-tcp-antispoof-05.txt References: <20070118012440.GC1540@hut.isi.edu> <77BF57F4-215F-4015-971B-36335B975951@nokia.com> In-Reply-To: <77BF57F4-215F-4015-971B-36335B975951@nokia.com> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0662925063==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0662925063== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig268EFD6CD89CA53E48DF669A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig268EFD6CD89CA53E48DF669A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, I received some detailed corrections from Alfred Hoenes, noting the issues below, as well as the suggestion to include a sentence on NATs. Would it be more useful to make these corrections before or after the WG sends the document on? (and can they be done without yet another WGLC?) Joe Lars Eggert wrote: > On 2007-1-18, at 3:24, ext Ted Faber wrote: >> This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now. >=20 > I did my AD review during WGLC to speed up things a bit. >=20 > Overall, this is a very solid document that is ready for publication. >=20 > There are some minor boilerplate and spelling/grammar issues. Since I > know Joe uses Word, turn on spelling and grammar checks :-) If there ar= e > more substantial comments that would require a revision now, fix these > nits, too, otherwise they can wait until AUTH48. >=20 >> At 1 Mbps, 57,000 (40 >> byte) RSTs would take over 50 minutes to transmit, and, as noted >> earlier, most current connections are fairly brief by comparison. >=20 > 57000*8*40 =3D 18,240,000 bits need 18.24 seconds with 1Mbps >=20 > Lars >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig268EFD6CD89CA53E48DF669A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFvh3FE5f5cImnZrsRAlGqAKCN6MnIp4xvvannUwNpuwrNWZUBNQCeMzfo JijOEjSS72dhRa9CaYYIsiI= =KSu/ -----END PGP SIGNATURE----- --------------enig268EFD6CD89CA53E48DF669A-- --===============0662925063== 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 --===============0662925063==-- From tcpm-bounces@ietf.org Mon Jan 29 11:27:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZLI-0005ct-Ur; Mon, 29 Jan 2007 11:26:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZLH-0005co-VO for tcpm@ietf.org; Mon, 29 Jan 2007 11:26:51 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZLG-00025m-Hv for tcpm@ietf.org; Mon, 29 Jan 2007 11:26:51 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0TGNdS3009805; Mon, 29 Jan 2007 18:24:06 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 18:26:44 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Jan 2007 18:26:31 +0200 In-Reply-To: <45BE1DC5.6020101@isi.edu> References: <20070118012440.GC1540@hut.isi.edu> <77BF57F4-215F-4015-971B-36335B975951@nokia.com> <45BE1DC5.6020101@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <387AE5FA-4AB5-4EF8-BF2C-E74315856705@nokia.com> From: Lars Eggert Subject: Re: [tcpm] AD review of draft-ietf-tcpm-tcp-antispoof-05.txt Date: Mon, 29 Jan 2007 18:26:42 +0200 To: "ext Joe Touch" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jan 2007 16:26:31.0644 (UTC) FILETIME=[3C3919C0:01C743C2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2065685140==" Errors-To: tcpm-bounces@ietf.org --===============2065685140== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-29-654758012; protocol="application/pkcs7-signature" --Apple-Mail-29-654758012 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-29, at 18:16, ext Joe Touch wrote: > Would it be more useful to make these corrections before or after > the WG > sends the document on? (and can they be done without yet another > WGLC?) I'd be better to fix these before the document goes to the IESG. Editorial fixes don't require another WGLC. Lars --Apple-Mail-29-654758012 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjkxNjI2NDNaMCMGCSqGSIb3DQEJBDEWBBSNGX2vxgiNudx6 OJ3xtoqYD6lU1jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAY+557TgdH9qgPbC1pwlG5uydsmno8rxISbxTBPla4Eu1KSnTNVG5 nvDyFsyHBehZOJ+ygHq4Tsvr6wMoBC9ox5jvWrzRy1xOc9Axe664H+oFBVZHEUe2G6WFKrvLc/OW 7rLL/yqgsbjMC+NOHJo0Ft6MBlasotQFwVI9i22MB6iOBfRusaACrYHTiKp4mIi0ysix21deCPwh DFgEOBf0IomBssXPtIz8xDLlRJ4BrVfBrSdBrEMy9EI0rbS7D0ExLJuuwpJ7ey9+2e2c9T2Acihu NElaOehO/aGYh5T4spcK3TUNr8e/1pEA2YQoetwT0hDiAfe2hJ6OmuHbW3AAJgAAAAAAAA== --Apple-Mail-29-654758012-- --===============2065685140== 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 --===============2065685140==-- From tcpm-bounces@ietf.org Wed Jan 31 10:15:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHA9-0002Ue-SK; Wed, 31 Jan 2007 10:14:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHA9-0002UZ-8m for tcpm@ietf.org; Wed, 31 Jan 2007 10:14:17 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHA3-0005GG-MU for tcpm@ietf.org; Wed, 31 Jan 2007 10:14:17 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57] michael.welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l0VFE3kM011347 for ; Wed, 31 Jan 2007 16:14:03 +0100 From: Michael Welzl To: tcpm@ietf.org Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Jan 2007 16:13:43 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: () -4.4 ALL_TRUSTED,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [tcpm] Separate header checksums and WiFi 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 Dear all, A long time ago, at the San Diego IETF meeting in August 2004, I presented an idea called "Corruption Notification Options" (a proposal which is some sort of a refined specification of the TCP HACK idea) to this group. The group's feedback was that this is useless, as errors occur in such a clustered fashion that you wouldn't see any packets with an intact header but erroneous payload (which is the only situation where the scheme would yield any benefit). I think that it was Gorry Fairhurst who said this. I figured that the only convincing way to prove him wrong is to actually do a real-life test. I did, and proved him right :) that is, disabling checksums for parts of packets doesn't yield much of a benefit in WiFi networks, where it seems that frames are delivered in an all-or-nothing fashion. Doing this test requires patching the device driver (to disable the link layer CRC), and above all, finding a good student - all of this took quite some time, but now it's over, and the documentation can be found at: http://www.welzl.at/research/projects/corruption/ (bottom of the page) I learned my lesson, and thought I'd share it with you - but this result only concerns WiFi. I'll keep this as a low-priority "background" project and may take a closer look at other link layers one day... in any case, that topic still interests me, and I can't believe that it wouldn't be possible to get a benefit out of such a scheme. I'm sending this note to TCPM, TSVWG and DCCP because there are similar mechanisms there (DCCP: the Data Checksum option; SCTP: http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt although I just noticed that this is apparently not a WG item... still, it's SCTP related). This note also goes to ICCRG, because I think that this should be the place for related discussions (in fact Lachlan Andrew will give us a related talk at our upcoming meeting: http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda ) Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 31 10:59:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHrd-0003Eu-HD; Wed, 31 Jan 2007 10:59:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHrc-0003EJ-5E for tcpm@ietf.org; Wed, 31 Jan 2007 10:59:12 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHrZ-0002HD-Lw for tcpm@ietf.org; Wed, 31 Jan 2007 10:59:12 -0500 Received: from [127.0.0.1] ([67.122.65.220]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0VFwmQA028273; Wed, 31 Jan 2007 07:58:49 -0800 (PST) Message-ID: <45C0BCB7.8090301@isi.edu> Date: Wed, 31 Jan 2007 07:58:47 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Michael Welzl Subject: Re: [tcpm] Separate header checksums and WiFi References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> In-Reply-To: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1547907990==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1547907990== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0EB9D8C9F993B339E5590598" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0EB9D8C9F993B339E5590598 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: > Dear all, >=20 > A long time ago, at the San Diego IETF meeting in August 2004, > I presented an idea called "Corruption Notification Options" > (a proposal which is some sort of a refined specification of > the TCP HACK idea) to this group. >=20 > The group's feedback was that this is useless, as errors > occur in such a clustered fashion that you wouldn't see > any packets with an intact header but erroneous payload > (which is the only situation where the scheme would > yield any benefit). I think that it was Gorry Fairhurst > who said this. There was a separate issue - you need to *know* the header is intact. For TCP, there's no separate header checksum to provide that information. I.e., this might be possible with UDP-lite, but isn't with UDP or TCP. This might not affect the SCTP or DCCP variants, depending on what their checksums cover. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig0EB9D8C9F993B339E5590598 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwLy3E5f5cImnZrsRAuP5AKC9eXFPlbo+CC8J8iAfwh8swtmMUQCgp5VD 9bUJfyJNzAJsSOhYqm8MNDI= =lQeJ -----END PGP SIGNATURE----- --------------enig0EB9D8C9F993B339E5590598-- --===============1547907990== 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 --===============1547907990==-- From tcpm-bounces@ietf.org Wed Jan 31 11:13:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI4q-0004UT-Ru; Wed, 31 Jan 2007 11:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI4B-0003Ld-QE for tcpm@ietf.org; Wed, 31 Jan 2007 11:12:11 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCI0O-0005JW-LA for tcpm@ietf.org; Wed, 31 Jan 2007 11:08:19 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57] michael.welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l0VG8Fqw023274; Wed, 31 Jan 2007 17:08:15 +0100 Subject: Re: [tcpm] Separate header checksums and WiFi From: Michael Welzl To: Joe Touch In-Reply-To: <45C0BCB7.8090301@isi.edu> References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <45C0BCB7.8090301@isi.edu> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1170259675.4805.647.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Jan 2007 17:07:55 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: () -4.4 ALL_TRUSTED,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, 2007-01-31 at 16:58, Joe Touch wrote: > Michael Welzl wrote: > > Dear all, > > > > A long time ago, at the San Diego IETF meeting in August 2004, > > I presented an idea called "Corruption Notification Options" > > (a proposal which is some sort of a refined specification of > > the TCP HACK idea) to this group. > > > > The group's feedback was that this is useless, as errors > > occur in such a clustered fashion that you wouldn't see > > any packets with an intact header but erroneous payload > > (which is the only situation where the scheme would > > yield any benefit). I think that it was Gorry Fairhurst > > who said this. > > There was a separate issue - you need to *know* the header is intact. > For TCP, there's no separate header checksum to provide that Well, that's what my proposal added :) > information. I.e., this might be possible with UDP-lite, but isn't with > UDP or TCP. This might not affect the SCTP or DCCP variants, depending > on what their checksums cover. It will affect the DCCP Data Checksum, which is just the same as my TCP proposal. The SCTP proposal is a little different. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 31 11:50:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIew-0000yH-5H; Wed, 31 Jan 2007 11:50:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIeu-0000yC-LB for tcpm@ietf.org; Wed, 31 Jan 2007 11:50:08 -0500 Received: from gateway.insightbb.com ([74.128.0.19] helo=asav02.insightbb.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCIet-0003RU-5I for tcpm@ietf.org; Wed, 31 Jan 2007 11:50:08 -0500 Received: from 74-140-122-125.dhcp.insightbb.com (HELO elb.elitists.net) ([74.140.122.125]) by asav02.insightbb.com with ESMTP; 31 Jan 2007 11:43:24 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJZWwEVKjHp9/2dsb2JhbACeWAEBAQE Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id F1D3D2BE21 for ; Wed, 31 Jan 2007 11:43:23 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 9D519281FC; Wed, 31 Jan 2007 11:43:23 -0500 (EST) Date: Wed, 31 Jan 2007 11:43:23 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] Separate header checksums and WiFi Message-ID: <20070131164323.GD16985@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> MIME-Version: 1.0 In-Reply-To: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.12-2006-07-14 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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="===============2072094566==" Errors-To: tcpm-bounces@ietf.org --===============2072094566== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8w3uRX/HFJGApMzv" Content-Disposition: inline --8w3uRX/HFJGApMzv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Michael Welzl spake unto us the following wisdom: > I figured that the only convincing way to prove him > wrong is to actually do a real-life test. I did, and > proved him right :) that is, disabling checksums for > parts of packets doesn't yield much of a benefit in > WiFi networks, where it seems that frames are delivered > in an all-or-nothing fashion. I have to applaud this move. All too often we only talk about the things we did that *worked*, and the same questions about things that any number of people would tell you doesn't work come up over and over. For this particular topic, there is now a citation, so the next guy won't have to go try it himself. Thank you. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --8w3uRX/HFJGApMzv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFwMcrr9kA9Ig8HBQRAgiSAKDGcEajP2lai/fkMc3f5eBh/LvQ/wCgg8D7 rpRrc8Aj28/TCjFvIDN77F0= =UL+T -----END PGP SIGNATURE----- --8w3uRX/HFJGApMzv-- --===============2072094566== 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 --===============2072094566==-- From tcpm-bounces@ietf.org Wed Jan 31 11:56:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIkY-0004jy-22; Wed, 31 Jan 2007 11:55:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIkW-0004hk-G9 for tcpm@ietf.org; Wed, 31 Jan 2007 11:55:56 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCIkT-0004Rv-2L for tcpm@ietf.org; Wed, 31 Jan 2007 11:55:56 -0500 Received: from [127.0.0.1] ([67.122.65.220]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0VGsJiY015014; Wed, 31 Jan 2007 08:54:19 -0800 (PST) Message-ID: <45C0C9B8.8070109@isi.edu> Date: Wed, 31 Jan 2007 08:54:16 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Michael Welzl Subject: Re: [tcpm] Separate header checksums and WiFi References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <45C0BCB7.8090301@isi.edu> <1170259675.4805.647.camel@lap10-c703.uibk.ac.at> In-Reply-To: <1170259675.4805.647.camel@lap10-c703.uibk.ac.at> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1543586530==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1543586530== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig925C5DF15BD99B56172D4F6C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig925C5DF15BD99B56172D4F6C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Welzl wrote: > On Wed, 2007-01-31 at 16:58, Joe Touch wrote: =2E.. >> There was a separate issue - you need to *know* the header is intact. >> For TCP, there's no separate header checksum to provide that >=20 > Well, that's what my proposal added :) Did your experiment measure that aspect? That's the key question - how many packets have recoverable headers... Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig925C5DF15BD99B56172D4F6C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwMm5E5f5cImnZrsRAiIuAKChiA8sHC1N19w/pjd4jeM4/MDqtQCeIW9w cG7WIA/FA1tRczjJ11Gafbk= =+/QJ -----END PGP SIGNATURE----- --------------enig925C5DF15BD99B56172D4F6C-- --===============1543586530== 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 --===============1543586530==-- From tcpm-bounces@ietf.org Wed Jan 31 12:14:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ1h-0005YB-E9; Wed, 31 Jan 2007 12:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ1f-0005Xt-Gv for tcpm@ietf.org; Wed, 31 Jan 2007 12:13:39 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJ1b-0002mH-1T for tcpm@ietf.org; Wed, 31 Jan 2007 12:13:39 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57] michael.welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l0VHDXt2032262; Wed, 31 Jan 2007 18:13:33 +0100 Subject: Re: [tcpm] Separate header checksums and WiFi From: Michael Welzl To: Joe Touch In-Reply-To: <45C0C9B8.8070109@isi.edu> References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <45C0BCB7.8090301@isi.edu> <1170259675.4805.647.camel@lap10-c703.uibk.ac.at> <45C0C9B8.8070109@isi.edu> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1170263593.4805.677.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Jan 2007 18:13:13 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: () -4.4 ALL_TRUSTED,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mattia.rossi@uibk.ac.at, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, 2007-01-31 at 17:54, Joe Touch wrote: > Michael Welzl wrote: > > On Wed, 2007-01-31 at 16:58, Joe Touch wrote: > ... > >> There was a separate issue - you need to *know* the header is intact. > >> For TCP, there's no separate header checksum to provide that > > > > Well, that's what my proposal added :) > > Did your experiment measure that aspect? That's the key question - how > many packets have recoverable headers... Yes! It's a sad, sad story (well, for me it was :) ). See the tables on pages 62ff of http://www.welzl.at/research/projects/corruption/index.html To give you an example, in the measurement on page 61, we had approx. 479k received packets, of which 178 were received with errors and 14 had an intact header checksum. That's the approximate order of magnitude... tens or hundreds, if not less, out of hundreds of thousands. By the way, I'd like to point out that all the credit for this measurement goes to the master student who did it, Mattia Rossi - he really put a lot of effort into this. BTW, he's now in Australia (Perth), taking a break, and soon looking for a job there AFAIK; his email address is (hopefully still working?) mattia.rossi@uibk.ac.at and I'm cc'ing him. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 31 12:14:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ2n-0005p3-0x; Wed, 31 Jan 2007 12:14:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ2m-0005oO-5N for tcpm@ietf.org; Wed, 31 Jan 2007 12:14:48 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJ2i-00039b-MH for tcpm@ietf.org; Wed, 31 Jan 2007 12:14:48 -0500 Received: from [127.0.0.1] ([67.122.65.220]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l0VHEYBr020405; Wed, 31 Jan 2007 09:14:35 -0800 (PST) Message-ID: <45C0CE79.4040303@isi.edu> Date: Wed, 31 Jan 2007 09:14:33 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] Separate header checksums and WiFi References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <20070131164323.GD16985@elb.elitists.net> In-Reply-To: <20070131164323.GD16985@elb.elitists.net> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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="===============0390897575==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0390897575== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA167BB3C4948A28C3C0C862" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA167BB3C4948A28C3C0C862 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Beyond what Ethan is suggesting, this is useful to write up more fully and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes, are critical to the community as a whole. Joe Ethan Blanton wrote: > Michael Welzl spake unto us the following wisdom: >> I figured that the only convincing way to prove him >> wrong is to actually do a real-life test. I did, and >> proved him right :) that is, disabling checksums for >> parts of packets doesn't yield much of a benefit in >> WiFi networks, where it seems that frames are delivered >> in an all-or-nothing fashion. >=20 > I have to applaud this move. All too often we only talk about the > things we did that *worked*, and the same questions about things that > any number of people would tell you doesn't work come up over and > over. For this particular topic, there is now a citation, so the next > guy won't have to go try it himself. Thank you. >=20 > Ethan >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigDA167BB3C4948A28C3C0C862 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwM55E5f5cImnZrsRAipKAKDlGt4TBJKQV5KNXk9OupJDcpeFbwCghbu0 fpYdd1EibggBJfw+5zKmUjI= =DdtD -----END PGP SIGNATURE----- --------------enigDA167BB3C4948A28C3C0C862-- --===============0390897575== 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 --===============0390897575==-- From tcpm-bounces@ietf.org Wed Jan 31 12:17:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ5K-0006lu-6p; Wed, 31 Jan 2007 12:17:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJ5J-0006lo-JO for tcpm@ietf.org; Wed, 31 Jan 2007 12:17:25 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJ5H-0003uk-22 for tcpm@ietf.org; Wed, 31 Jan 2007 12:17:25 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57] michael.welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l0VHHL7E032731; Wed, 31 Jan 2007 18:17:21 +0100 Subject: Re: [tcpm] Separate header checksums and WiFi From: Michael Welzl To: Joe Touch In-Reply-To: <45C0CE79.4040303@isi.edu> References: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at> <20070131164323.GD16985@elb.elitists.net> <45C0CE79.4040303@isi.edu> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1170263821.4805.684.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 31 Jan 2007 18:17:01 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: () -4.4 ALL_TRUSTED,RCV_SMTP_UIBK X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on 138.232.1.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 I agree, and am happy to contribute what I have!!!!! (which is: the results, but not the time) On Wed, 2007-01-31 at 18:14, Joe Touch wrote: > Beyond what Ethan is suggesting, this is useful to write up more fully > and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes, > are critical to the community as a whole. > > Joe > > Ethan Blanton wrote: > > Michael Welzl spake unto us the following wisdom: > >> I figured that the only convincing way to prove him > >> wrong is to actually do a real-life test. I did, and > >> proved him right :) that is, disabling checksums for > >> parts of packets doesn't yield much of a benefit in > >> WiFi networks, where it seems that frames are delivered > >> in an all-or-nothing fashion. > > > > I have to applaud this move. All too often we only talk about the > > things we did that *worked*, and the same questions about things that > > any number of people would tell you doesn't work come up over and > > over. For this particular topic, there is now a citation, so the next > > guy won't have to go try it himself. Thank you. > > > > Ethan > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm -- Michael Welzl University of Innsbruck _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm