From tcpm-bounces@ietf.org Mon Nov 06 17:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQQ-0003fu-VI; Mon, 06 Nov 2006 17:58:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDQN-0003WG-4T for tcpm@ietf.org; Mon, 06 Nov 2006 17:58:39 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhDKI-0000mu-SZ for tcpm@ietf.org; Mon, 06 Nov 2006 17:52:25 -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 kA6Mq4Wq012932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Nov 2006 14:52:04 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kA6Mq44f002794 for tcpm@ietf.org; Mon, 6 Nov 2006 14:52:04 -0800 (PST) (envelope-from faber) Date: Mon, 6 Nov 2006 14:52:04 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20061106225204.GB1263@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: b19722fc8d3865b147c75ae2495625f2 Subject: [tcpm] Presentations 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="===============1026840215==" Errors-To: tcpm-bounces@ietf.org --===============1026840215== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DBIVS5p969aUjpLe" Content-Disposition: inline --DBIVS5p969aUjpLe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Those of you presenting in San Diego, please send me your presentation materials. I will have a laptop there with the slides you send me, but it'll be a FreeBSD box running openoffice. It might work, but you should also make backup plans. Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --DBIVS5p969aUjpLe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFT7yUaUz3f+Zf+XsRAlKFAJ4kYIPd8My2hDD2IN9SUIIBkWjmYACeNhTa 2GlcouTo8w1Ba5sA+8sKKCw= =zQjO -----END PGP SIGNATURE----- --DBIVS5p969aUjpLe-- --===============1026840215== 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 --===============1026840215==-- From tcpm-bounces@ietf.org Thu Nov 09 18:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJez-00037Y-96; Thu, 09 Nov 2006 18:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJek-00030S-NR; Thu, 09 Nov 2006 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJek-0007TV-7F; Thu, 09 Nov 2006 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 301AC328BD; Thu, 9 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJek-0004M2-2U; Thu, 09 Nov 2006 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, 09 Nov 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : R. Stewart, M. Dalal Filename : draft-ietf-tcpm-tcpsecure-06.txt Pages : 26 Date : 2006-11-9 A recent study indicates that some types of TCP connections have an increased vulnerability to spoofed packet injection attacks than previously believed [SITW]. TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Note: Both [SITW] and [I-D.ietf-tcpm-tcp-antispoof] provide charts which can give the reader an idea as to the time it takes to penetrate an unprotected system. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by carefully crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document requires small modifications to the way TCP handles inbound segments that can reduce the probability of such an attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcpsecure-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-9154440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-9154440.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 Thu Nov 09 22:03:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMfG-0002iW-8y; Thu, 09 Nov 2006 22:02:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMfF-0002iN-NW; Thu, 09 Nov 2006 22:02:45 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiMf9-0004Pl-Qq; Thu, 09 Nov 2006 22:02:45 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 6F99CF0C3F9; Fri, 10 Nov 2006 00:01:52 -0300 (ART) Received: from fgont.gont.com.ar ([170.210.17.150]) (authenticated bits=0) by venus.xmundo.net (8.12.11/8.12.11) with ESMTP id kAA31hXj022642; Fri, 10 Nov 2006 00:01:47 -0300 Message-Id: <7.0.1.0.0.20061109184946.088d2f38@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 09 Nov 2006 19:01:30 -0800 To: tsvwg@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Fri, 10 Nov 2006 00:01:51 -0300 (ART) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org Subject: [tcpm] Port Randomization draft 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, We have submitted a new draft on port number randomization. It's based on a document by M. Larsen that had been published in 2004. This document helps quite a lot in the case of the blind attacks that have been discussed in the TCPM WG. The document is pretty general, and its proposal can be applied to any transport protocol. The document is available at http://www.gont.com.ar/drafts/port-randomization/draft-larsen-tsvwg-port-randomization-00.txt , and you can find it in other fancy formats at: http://www.gont.com.ar/drafts/port-randomization/index.html . It will soon be available at the usual places. Here's the abstract: ---- cut here ---- Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or corrupted data. These attacks rely on the attacker's ability to guess or know the four- tuple (Source Address, Destination Address, Source port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a simple and efficient method for random selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods, the described port number randomization algorithms provide improved security/obfuscation with very little effort and without any key management overhead. ---- cut here ---- We would highly appreciate any comments/suggestions you may have. Thanks! P.S.: While this message is being cross-posted to the tcpm wg mailing-list, we would like the discussion to happen in the tsvwg, as we think all protocols (and not just TCP) can benefit from the proposal in this draft. 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 Sun Nov 12 12:52:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjJTz-0007EF-1B; Sun, 12 Nov 2006 12:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjJTx-0007BV-5J for tcpm@ietf.org; Sun, 12 Nov 2006 12:51:01 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjJSF-0002k8-95 for tcpm@ietf.org; Sun, 12 Nov 2006 12:49:16 -0500 Received: from [127.0.0.1] (cbshost-12-107-17-5.sbcox.net [12.107.17.5]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kACHmwh9009651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Nov 2006 09:48:58 -0800 (PST) Message-ID: <45575E88.4090406@isi.edu> Date: Sun, 12 Nov 2006 09:48:56 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tcpm@ietf.org 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: 50a516d93fd399dc60588708fd9a3002 Subject: [tcpm] clarification of Steve Bellovin's attack discussion 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="===============1220280594==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1220280594== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigED769C5B3F200629EEFFDB8E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigED769C5B3F200629EEFFDB8E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, At the meeting in San Diego last week, Steve Bellovin presented a case in favor of updating TCP/MD5. As part of that discussion, there was a brief reference to an attack which happened recently at Columbia Univ, in which a machine was compromised and used to attack other machines on their network. I believe Steve was asked whether an updated TCP/MD5 would have protected some aspects of that attack (not the compromising of the machine per se, but the subsequent opportunity for attack). I believe he replied "yes". (please correct me if this is not the case on either point= ) However, the slides (here) suggest that the attack inside the network was ARP-level, and the compromising of the machine at the FTP level: Steve: could you address whether - and specifically how - transport security would be useful in this case? While I remain in favor updating transport security for completeness (if it can be done orthogonally), it'd be very useful to understand where it might be of potential benefit. Joe --------------enigED769C5B3F200629EEFFDB8E 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 iD8DBQFFV16IE5f5cImnZrsRAq9GAKCPNlggB9HiEyr9OsCq2t7L6PG/xACdGJXC VT0llDT6HNB7p83iw8VgTuc= =6XsU -----END PGP SIGNATURE----- --------------enigED769C5B3F200629EEFFDB8E-- --===============1220280594== 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 --===============1220280594==-- From tcpm-bounces@ietf.org Mon Nov 13 14:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh1u-00011q-Ft; Mon, 13 Nov 2006 13:59:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh1t-00011U-Ej for tcpm@ietf.org; Mon, 13 Nov 2006 13:59:37 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjh1r-0006Zk-1i for tcpm@ietf.org; Mon, 13 Nov 2006 13:59:37 -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 kADIx7ve011154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Nov 2006 10:59:07 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kADIx7k3001511; Mon, 13 Nov 2006 10:59:07 -0800 (PST) (envelope-from faber) Date: Mon, 13 Nov 2006 10:59:07 -0800 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] clarification of Steve Bellovin's attack discussion Message-ID: <20061113185907.GA1139@hut.isi.edu> References: <45575E88.4090406@isi.edu> Mime-Version: 1.0 In-Reply-To: <45575E88.4090406@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: 0a7aa2e6e558383d84476dc338324fab 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="===============1421732352==" Errors-To: tcpm-bounces@ietf.org --===============1421732352== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2006 at 09:48:56AM -0800, Joe Touch wrote: > However, the slides (here) suggest that the attack inside the network > was ARP-level, and the compromising of the machine at the FTP level: > >=20 > Steve: could you address whether - and specifically how - transport > security would be useful in this case? While I'm certainly curious about how that attack proceeded and what one could do to prevent others like it, I believe that this was a non-motivating example for the MD5 update. He brought it up at the mike, not as a driver for the proposed work. My recollection was that he asserted that the MD5 would have, at best, affected the initial intrusion, and he didn't seem too sure about that. :-) I didn't think that this was a deciding factor in the hum, but people's opinions were swayed significantly by this example, then I'm more interested in delving into the details. I'd love to hear from people who think that delving is important. > While I remain in favor updating transport security for completeness (if > it can be done orthogonally), it'd be very useful to understand where it > might be of potential benefit. I think it's pretty clear where this is of importance. Any attack based on tweaking the TCP header or where the loose semantics between IPSec (later 3) and TCP (layer 4) are key. You gave a nice example of the latter with your FIN example at the meeting. --=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 --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWMB7aUz3f+Zf+XsRAtcBAJ9joFaWAf40OBQidz4EJyzds3Lt7QCeIbt2 +K+Ij549ur1tcUYiLr4Wxi0= =1+u5 -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- --===============1421732352== 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 --===============1421732352==-- From tcpm-bounces@ietf.org Mon Nov 13 14:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh7P-0008ED-Cc; Mon, 13 Nov 2006 14:05:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjh7N-0008Cd-7Z for tcpm@ietf.org; Mon, 13 Nov 2006 14:05:17 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjh7K-0007M8-T3 for tcpm@ietf.org; Mon, 13 Nov 2006 14:05:17 -0500 Received: from [127.0.0.1] (priras01.isi.edu [128.9.176.219]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kADJ4psl002855; Mon, 13 Nov 2006 11:04:53 -0800 (PST) Message-ID: <4558C1D0.6080904@isi.edu> Date: Mon, 13 Nov 2006 11:04:48 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] clarification of Steve Bellovin's attack discussion References: <45575E88.4090406@isi.edu> <20061113185907.GA1139@hut.isi.edu> In-Reply-To: <20061113185907.GA1139@hut.isi.edu> X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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="===============0364644449==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0364644449== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE155AE70F38439CE21668E1F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE155AE70F38439CE21668E1F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: =2E.. >> While I remain in favor updating transport security for completeness (= if >> it can be done orthogonally), it'd be very useful to understand where = it >> might be of potential benefit. >=20 > I think it's pretty clear where this is of importance. Any attack base= d > on tweaking the TCP header or where the loose semantics between IPSec > (later 3) and TCP (layer 4) are key. You gave a nice example of the > latter with your FIN example at the meeting. The general benefit of a transport solution is one thing (which I agree).= The widespread need or utility of such a solution is another (which I'm not clear on at all). Joe --------------enigE155AE70F38439CE21668E1F 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 iD8DBQFFWMHQE5f5cImnZrsRArI6AJ9IVDBHgDhGcFIs0QOeG9uzKApudgCfVtv/ w5s7GVNpO1guG8y2SKHaeiQ= =D+mL -----END PGP SIGNATURE----- --------------enigE155AE70F38439CE21668E1F-- --===============0364644449== 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 --===============0364644449==-- From tcpm-bounces@ietf.org Mon Nov 13 14:23:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhOF-0001Ws-Vn; Mon, 13 Nov 2006 14:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhOE-0001Wl-RX for tcpm@ietf.org; Mon, 13 Nov 2006 14:22:42 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjhN4-0000o1-Te for tcpm@ietf.org; Mon, 13 Nov 2006 14:21:32 -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 kADJLITt020450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Nov 2006 11:21:18 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kADJLIk9062779; Mon, 13 Nov 2006 11:21:18 -0800 (PST) (envelope-from faber) Date: Mon, 13 Nov 2006 11:21:18 -0800 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] clarification of Steve Bellovin's attack discussion Message-ID: <20061113192118.GB1139@hut.isi.edu> References: <45575E88.4090406@isi.edu> <20061113185907.GA1139@hut.isi.edu> <4558C1D0.6080904@isi.edu> Mime-Version: 1.0 In-Reply-To: <4558C1D0.6080904@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0296109080==" Errors-To: tcpm-bounces@ietf.org --===============0296109080== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0eh6TmSyL6TZE2Uz" Content-Disposition: inline --0eh6TmSyL6TZE2Uz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 11:04:48AM -0800, Joe Touch wrote: > The general benefit of a transport solution is one thing (which I agree). >=20 > The widespread need or utility of such a solution is another (which I'm > not clear on at all). Fair enough. I really don't know how one could assess that objectively. My sense of the room on Thursday was that overall the work was interesting and important enough that the WG decided to proceed. --=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 --0eh6TmSyL6TZE2Uz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWMWuaUz3f+Zf+XsRAoydAJsEx2RbXemESI9Qa4lt2evTNXBgxgCgwG0J eOGGYy8C8F0B87v6c52yHxg= =dVRx -----END PGP SIGNATURE----- --0eh6TmSyL6TZE2Uz-- --===============0296109080== 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 --===============0296109080==-- From tcpm-bounces@ietf.org Mon Nov 13 14:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhhB-00061J-BO; Mon, 13 Nov 2006 14:42:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjhh8-00060N-MC; Mon, 13 Nov 2006 14:42:14 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjhh8-0004hn-Ki; Mon, 13 Nov 2006 14:42:14 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gjhh7-0003vu-Cm; Mon, 13 Nov 2006 14:42:14 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 20C6E1759A; Mon, 13 Nov 2006 19:41:43 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gjhgc-0000Tk-Mi; Mon, 13 Nov 2006 14:41:42 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 13 Nov 2006 14:41:42 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: [tcpm] Last Call: 'TCP Extended Statistics MIB' to Proposed Standard (draft-ietf-tsvwg-tcp-mib-extension) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the Transport Area Working Group to consider the following document: - 'TCP Extended Statistics MIB ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-27. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-mib-extension-12.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 14 15:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5Eq-0008Ui-W8; Tue, 14 Nov 2006 15:50:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5Em-0008U2-3U; Tue, 14 Nov 2006 15:50:32 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk5Em-0002aR-1E; Tue, 14 Nov 2006 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gk5El-0005Ih-NH; Tue, 14 Nov 2006 15:50:31 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A09B62AC66; Tue, 14 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gk5EH-0004C9-DW; Tue, 14 Nov 2006 15:50:01 -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: Tue, 14 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-tcpsecure-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : R. Stewart, et al. Filename : draft-ietf-tcpm-tcpsecure-06.txt Pages : 26 Date : 2006-11-9 A recent study indicates that some types of TCP connections have an increased vulnerability to spoofed packet injection attacks than previously believed [SITW]. TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Note: Both [SITW] and [I-D.ietf-tcpm-tcp-antispoof] provide charts which can give the reader an idea as to the time it takes to penetrate an unprotected system. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by carefully crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document requires small modifications to the way TCP handles inbound segments that can reduce the probability of such an attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcpsecure-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-14104937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcpsecure-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-14104937.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Nov 15 08:01:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkKNd-0008Py-0i; Wed, 15 Nov 2006 08:00:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkKNb-0008Pg-MH for tcpm@ietf.org; Wed, 15 Nov 2006 08:00:39 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkKNa-0007ex-9M for tcpm@ietf.org; Wed, 15 Nov 2006 08:00:39 -0500 Received: (qmail 17483 invoked from network); 15 Nov 2006 12:52:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 12:52:52 -0000 Message-ID: <455B0F67.4000003@freebsd.org> Date: Wed, 15 Nov 2006 14:00:23 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] Proposing ACKNOW bit in TCP header 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 propose to include an ACKNOW bit into the TCP header instructing the recipient to immediately, without any delay whatsoever, acknowledge the received segment. The bit location is the 9th bit in the TCP flags. This bit is to be included in TCP SYN segments to indicate the support for it. Only if the SYN-ACK response has the bit set as well the session is allowed to make use of the ACKNOW feature. Rationale: During the slow start and congestion recovery phases the sender is dependent on immediate feedback to quickly make optimal use of all network resources again. The presence of delayed ACKs add unnecessary delays and introduces uncertainty to the recovery progress and the discovery of the true network conditions. On the other hand delayed ACKs serve an important function on fast networks with high PPS rates to improve efficiency and to coalesce the acknowledging of multiple segments at once. It is extremely difficult for the receiver to guess itself when to switch from delayed ACKs to immediate ACKs as it has only insufficient hints the current state the sender operates in. The ACKNOW flag solves this in a simple and elegant way by allowing the sender to explicitly request an immediate ACK to its segments when it is appropriate for the congestion control recovery mechanism to do so. As a second benefit a receiver on a ACKNOW flag enabled session may increase the delayed ACK from every other packet (as currently required) to a higher number, lets say every eighth. The exact value is to be determined based on the estimated delay*bandwidth product and the send/ receive socket buffer sizes. The use of the ACKNOW bit allows significant faster recovery times in the presence of difficult network conditions. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 10:18:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkMW5-0005KW-NB; Wed, 15 Nov 2006 10:17:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkMW4-0005IP-Ov for tcpm@ietf.org; Wed, 15 Nov 2006 10:17:32 -0500 Received: from smtpsrv0.isis.unc.edu ([152.2.1.139] helo=smtp.unc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkMW3-0001tF-91 for tcpm@ietf.org; Wed, 15 Nov 2006 10:17:32 -0500 Received: from REWASKAR1CS (rewaskar1-cs.cs.unc.edu [152.2.133.122]) by smtp.unc.edu (8.13.4/8.13.4) with ESMTP id kAFFGQZ0001399; Wed, 15 Nov 2006 10:16:32 -0500 (EST) From: "Sushant Rewaskar" To: "'Andre Oppermann'" , Subject: RE: [tcpm] Proposing ACKNOW bit in TCP header Date: Wed, 15 Nov 2006 10:16:25 -0500 Organization: UNC Chapel Hill Message-ID: <00ca01c708c9$055edc20$7a850298@cs.unc.edu> 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.2962 In-Reply-To: <455B0F67.4000003@freebsd.org> Thread-Index: AccItzcc/Dt+ZV2BTpK6EEobsnui5wADywlw X-Scanned-By: ITS Messaging Systems (outgoing) on 152.2.1.139 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rewaskar@cs.unc.edu List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, Adding a new interpretation to bits in TCP header would be one way of doing it. I briefly thought about this problem and here is another way you can do it without changing the header fields (which lots of people are dead against). Also, by 9th bit in the header flags did you mean the PUSH bit?, If yes, what about the implications of overwriting the default meaning associated with it? Anyway, here is an alternate solution. We are assuming that the sender know when it "needs" the "quick ack" mode and tells the receiver accordingly. The rationale was that with delayed acks the window does not open to twice the current window but to just 1 and half time the current window. Anyway, my point is that if sender knows that acks are delayed why not interpret them differently. Everything you get an ack in the "special state" (when you need immediate acks) increase your window by two and not one MSS. (the only different is that in this method loss of one ack will be more harmful then in the earlier method, but then you can take care of that as well, depend on how much code and processing you want to add to the sender.) Of course, I am just presenting an alternate method. The benefits of doing something like this have still to be argued. (Hopefully with do that soon) Take care, Sushant Rewaskar ----------------------------- UNC Chapel Hill www.cs.unc.edu/~rewaskar -----Original Message----- From: Andre Oppermann [mailto:andre@freebsd.org] Sent: Wednesday, November 15, 2006 8:00 AM To: tcpm@ietf.org Subject: [tcpm] Proposing ACKNOW bit in TCP header I propose to include an ACKNOW bit into the TCP header instructing the recipient to immediately, without any delay whatsoever, acknowledge the received segment. The bit location is the 9th bit in the TCP flags. This bit is to be included in TCP SYN segments to indicate the support for it. Only if the SYN-ACK response has the bit set as well the session is allowed to make use of the ACKNOW feature. Rationale: During the slow start and congestion recovery phases the sender is dependent on immediate feedback to quickly make optimal use of all network resources again. The presence of delayed ACKs add unnecessary delays and introduces uncertainty to the recovery progress and the discovery of the true network conditions. On the other hand delayed ACKs serve an important function on fast networks with high PPS rates to improve efficiency and to coalesce the acknowledging of multiple segments at once. It is extremely difficult for the receiver to guess itself when to switch from delayed ACKs to immediate ACKs as it has only insufficient hints the current state the sender operates in. The ACKNOW flag solves this in a simple and elegant way by allowing the sender to explicitly request an immediate ACK to its segments when it is appropriate for the congestion control recovery mechanism to do so. As a second benefit a receiver on a ACKNOW flag enabled session may increase the delayed ACK from every other packet (as currently required) to a higher number, lets say every eighth. The exact value is to be determined based on the estimated delay*bandwidth product and the send/ receive socket buffer sizes. The use of the ACKNOW bit allows significant faster recovery times in the presence of difficult network conditions. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 10:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkMpV-000459-O4; Wed, 15 Nov 2006 10:37:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkMpU-00044r-O1 for tcpm@ietf.org; Wed, 15 Nov 2006 10:37:36 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkMpS-0005Ls-7K for tcpm@ietf.org; Wed, 15 Nov 2006 10:37:36 -0500 Received: (qmail 20737 invoked from network); 15 Nov 2006 15:30:01 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 15:30:01 -0000 Message-ID: <455B343C.7040100@freebsd.org> Date: Wed, 15 Nov 2006 16:37:32 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: rewaskar@cs.unc.edu Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <00ca01c708c9$055edc20$7a850298@cs.unc.edu> In-Reply-To: <00ca01c708c9$055edc20$7a850298@cs.unc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Sushant, I counted the bits from the other side, it's the unused bit next to CWR. Extending the semantics of the PUSH bit would be possible but be quite hackish IMHO. Your alternative is not an option. The sender has no knowledge if delayed ACK is enabled on the receiver at all. Upping the window in double steps would be too aggressive and violate the TCP spec and spirit. Neither is it a solution to the congestion recovery case which is very important as well. Occupying bits in the TCP header wasn't too difficult for ECN and ECN has only enjoyed moderate uptake. ACKNOW is much simpler and has much more immediate and tangible benefits than ECN. -- Andre Sushant Rewaskar wrote: > Hi, > Adding a new interpretation to bits in TCP header would be one way of doing > it. I briefly thought about this problem and here is another way you can do > it without changing the header fields (which lots of people are dead > against). > > Also, by 9th bit in the header flags did you mean the PUSH bit?, If yes, > what about the implications of overwriting the default meaning associated > with it? > > Anyway, here is an alternate solution. We are assuming that the sender know > when it "needs" the "quick ack" mode and tells the receiver accordingly. The > rationale was that with delayed acks the window does not open to twice the > current window but to just 1 and half time the current window. Anyway, my > point is that if sender knows that acks are delayed why not interpret them > differently. Everything you get an ack in the "special state" (when you need > immediate acks) increase your window by two and not one MSS. (the only > different is that in this method loss of one ack will be more harmful then > in the earlier method, but then you can take care of that as well, depend on > how much code and processing you want to add to the sender.) > > Of course, I am just presenting an alternate method. The benefits of doing > something like this have still to be argued. (Hopefully with do that soon) > > Take care, > Sushant Rewaskar > ----------------------------- > UNC Chapel Hill > www.cs.unc.edu/~rewaskar > > -----Original Message----- > From: Andre Oppermann [mailto:andre@freebsd.org] > Sent: Wednesday, November 15, 2006 8:00 AM > To: tcpm@ietf.org > Subject: [tcpm] Proposing ACKNOW bit in TCP header > > I propose to include an ACKNOW bit into the TCP header instructing the > recipient to immediately, without any delay whatsoever, acknowledge > the received segment. The bit location is the 9th bit in the TCP flags. > This bit is to be included in TCP SYN segments to indicate the support > for it. Only if the SYN-ACK response has the bit set as well the session > is allowed to make use of the ACKNOW feature. > > Rationale: > > During the slow start and congestion recovery phases the sender is > dependent on immediate feedback to quickly make optimal use of all > network resources again. The presence of delayed ACKs add unnecessary > delays and introduces uncertainty to the recovery progress and the > discovery of the true network conditions. On the other hand delayed > ACKs serve an important function on fast networks with high PPS rates > to improve efficiency and to coalesce the acknowledging of multiple > segments at once. It is extremely difficult for the receiver to guess > itself when to switch from delayed ACKs to immediate ACKs as it has > only insufficient hints the current state the sender operates in. > > The ACKNOW flag solves this in a simple and elegant way by allowing the > sender to explicitly request an immediate ACK to its segments when it is > appropriate for the congestion control recovery mechanism to do so. > As a second benefit a receiver on a ACKNOW flag enabled session may > increase the delayed ACK from every other packet (as currently required) > to a higher number, lets say every eighth. The exact value is to be > determined based on the estimated delay*bandwidth product and the send/ > receive socket buffer sizes. > > The use of the ACKNOW bit allows significant faster recovery times in > the presence of difficult network conditions. > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 11:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNOo-0001xi-Ff; Wed, 15 Nov 2006 11:14:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNOn-0001xZ-94 for tcpm@ietf.org; Wed, 15 Nov 2006 11:14:05 -0500 Received: from smtpsrv0.isis.unc.edu ([152.2.1.139] helo=smtp.unc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNOl-0002Tj-Uo for tcpm@ietf.org; Wed, 15 Nov 2006 11:14:05 -0500 Received: from REWASKAR1CS (rewaskar1-cs.cs.unc.edu [152.2.133.122]) by smtp.unc.edu (8.13.4/8.13.4) with ESMTP id kAFGDg7l003370; Wed, 15 Nov 2006 11:13:46 -0500 (EST) From: "Sushant Rewaskar" To: "'Andre Oppermann'" , Subject: RE: [tcpm] Proposing ACKNOW bit in TCP header Date: Wed, 15 Nov 2006 11:13:42 -0500 Organization: UNC Chapel Hill Message-ID: <00f201c708d1$05247190$7a850298@cs.unc.edu> 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.2962 In-Reply-To: <455B343C.7040100@freebsd.org> Thread-Index: AccIzJ1fweiq7M/zRx6TuUlLQPx3WwAA0o9Q X-Scanned-By: ITS Messaging Systems (outgoing) on 152.2.1.139 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rewaskar@cs.unc.edu List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi Andre, You points are valid. As I said I had not thought it through, I can change my solution to take care of these objections (for e.g. to overcome the sender not knowing when the receiver is using delayed ack we simply do not change the window by a fixed amount but by the number of bytes acked by that ack, this way we also preserve the basic principle of TCP and are not aggressive). But then it may go on for a while and in the end my solution may be more of a hack then an elegant solution. I will probably flesh out more details before I present my new and improved solution. I also did not get what you meant by "it is not a solution to congestion recovery case", are you talking about fast retransmit and recovery? Do you have a draft or some more details about what you are proposing? Take care, Sushant Rewaskar ----------------------------- UNC Chapel Hill www.cs.unc.edu/~rewaskar -----Original Message----- From: Andre Oppermann [mailto:andre@freebsd.org] Sent: Wednesday, November 15, 2006 10:38 AM To: rewaskar@cs.unc.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Sushant, I counted the bits from the other side, it's the unused bit next to CWR. Extending the semantics of the PUSH bit would be possible but be quite hackish IMHO. Your alternative is not an option. The sender has no knowledge if delayed ACK is enabled on the receiver at all. Upping the window in double steps would be too aggressive and violate the TCP spec and spirit. Neither is it a solution to the congestion recovery case which is very important as well. Occupying bits in the TCP header wasn't too difficult for ECN and ECN has only enjoyed moderate uptake. ACKNOW is much simpler and has much more immediate and tangible benefits than ECN. -- Andre Sushant Rewaskar wrote: > Hi, > Adding a new interpretation to bits in TCP header would be one way of doing > it. I briefly thought about this problem and here is another way you can do > it without changing the header fields (which lots of people are dead > against). > > Also, by 9th bit in the header flags did you mean the PUSH bit?, If yes, > what about the implications of overwriting the default meaning associated > with it? > > Anyway, here is an alternate solution. We are assuming that the sender know > when it "needs" the "quick ack" mode and tells the receiver accordingly. The > rationale was that with delayed acks the window does not open to twice the > current window but to just 1 and half time the current window. Anyway, my > point is that if sender knows that acks are delayed why not interpret them > differently. Everything you get an ack in the "special state" (when you need > immediate acks) increase your window by two and not one MSS. (the only > different is that in this method loss of one ack will be more harmful then > in the earlier method, but then you can take care of that as well, depend on > how much code and processing you want to add to the sender.) > > Of course, I am just presenting an alternate method. The benefits of doing > something like this have still to be argued. (Hopefully with do that soon) > > Take care, > Sushant Rewaskar > ----------------------------- > UNC Chapel Hill > www.cs.unc.edu/~rewaskar > > -----Original Message----- > From: Andre Oppermann [mailto:andre@freebsd.org] > Sent: Wednesday, November 15, 2006 8:00 AM > To: tcpm@ietf.org > Subject: [tcpm] Proposing ACKNOW bit in TCP header > > I propose to include an ACKNOW bit into the TCP header instructing the > recipient to immediately, without any delay whatsoever, acknowledge > the received segment. The bit location is the 9th bit in the TCP flags. > This bit is to be included in TCP SYN segments to indicate the support > for it. Only if the SYN-ACK response has the bit set as well the session > is allowed to make use of the ACKNOW feature. > > Rationale: > > During the slow start and congestion recovery phases the sender is > dependent on immediate feedback to quickly make optimal use of all > network resources again. The presence of delayed ACKs add unnecessary > delays and introduces uncertainty to the recovery progress and the > discovery of the true network conditions. On the other hand delayed > ACKs serve an important function on fast networks with high PPS rates > to improve efficiency and to coalesce the acknowledging of multiple > segments at once. It is extremely difficult for the receiver to guess > itself when to switch from delayed ACKs to immediate ACKs as it has > only insufficient hints the current state the sender operates in. > > The ACKNOW flag solves this in a simple and elegant way by allowing the > sender to explicitly request an immediate ACK to its segments when it is > appropriate for the congestion control recovery mechanism to do so. > As a second benefit a receiver on a ACKNOW flag enabled session may > increase the delayed ACK from every other packet (as currently required) > to a higher number, lets say every eighth. The exact value is to be > determined based on the estimated delay*bandwidth product and the send/ > receive socket buffer sizes. > > The use of the ACKNOW bit allows significant faster recovery times in > the presence of difficult network conditions. > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 11:31:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNf5-0008Vb-AP; Wed, 15 Nov 2006 11:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNf4-0008VP-CT for tcpm@ietf.org; Wed, 15 Nov 2006 11:30:54 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNf1-000559-OX for tcpm@ietf.org; Wed, 15 Nov 2006 11:30:54 -0500 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 9D43EC2B0 for ; Wed, 15 Nov 2006 11:30:44 -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 kAFGUhDf023815; Wed, 15 Nov 2006 11:30:43 -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 kAFGUhre028416; Wed, 15 Nov 2006 11:30:43 -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 YfDZvQ2y5lDC; Wed, 15 Nov 2006 11:30:42 -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 kAFGUfjT028400;Wed, 15 Nov 2006 11:30:41 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id BFE724FD8D; Wed, 15 Nov 2006 11:29:43 -0500 (EST) Date: Wed, 15 Nov 2006 11:29:43 -0500 From: Wesley Eddy To: rewaskar@cs.unc.edu Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Message-ID: <20061115162943.GB4496@grc.nasa.gov> References: <455B343C.7040100@freebsd.org> <00f201c708d1$05247190$7a850298@cs.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f201c708d1$05247190$7a850298@cs.unc.edu> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.044 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.1500 0.1500) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: tcpm-bounces@ietf.org On Wed, Nov 15, 2006 at 11:13:42AM -0500, Sushant Rewaskar wrote: > I can change > my solution to take care of these objections (for e.g. to overcome the > sender not knowing when the receiver is using delayed ack we simply do not > change the window by a fixed amount but by the number of bytes acked by that > ack, this way we also preserve the basic principle of TCP and are not > aggressive). This sounds like RFC 3465. -- 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 Wed Nov 15 11:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNur-0007jr-M3; Wed, 15 Nov 2006 11:47:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNup-0007hC-SW for tcpm@ietf.org; Wed, 15 Nov 2006 11:47:11 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNun-0007Ux-GY for tcpm@ietf.org; Wed, 15 Nov 2006 11:47:11 -0500 Received: from [127.0.0.1] (67.sub-75-209-245.myvzw.com [75.209.245.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAFGklAk013136; Wed, 15 Nov 2006 08:46:51 -0800 (PST) Message-ID: <455B4472.3080402@isi.edu> Date: Wed, 15 Nov 2006 08:46:42 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <455B0F67.4000003@freebsd.org> In-Reply-To: <455B0F67.4000003@freebsd.org> 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: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============0981151976==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0981151976== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1CA62DDD42836DBB24DCB56" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1CA62DDD42836DBB24DCB56 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Andre, Andre Oppermann wrote: > I propose to include an ACKNOW bit into the TCP header instructing the > recipient to immediately, without any delay whatsoever, acknowledge > the received segment.=20 This sounds like a fairly substantial change to TCP semantics. TCP has only two kinds of headers that require a direct reply - SYN and FIN. It seems like all other interactions are driven by only data packets, and require the preceding data to have been correctly received to generate a positive ACK. I.e., short of start/end of a connection, TCP is more data driven than header driven. This would require a substantial change to that semantic, which seems like it would require a substantial revision. Forcing the other end to react is also a DOS opportunity. Can anyone speak to whether SCTP handles this better, since this sounds like a signalling issue? > Rationale: > >...It is extremely difficult for the receiver to guess > itself when to switch from delayed ACKs to immediate ACKs as it has > only insufficient hints the current state the sender operates in. Can you clarify this? I thought delayed (compressed 2:1) ACKs were required, period. It's only on the send side that delays are avoided, e.g., depending on NAGLE. > ...As a second benefit a receiver on a ACKNOW flag enabled session may > increase the delayed ACK from every other packet (as currently required= ) > to a higher number, lets say every eighth. The exact value is to be > determined based on the estimated delay*bandwidth product and the send/= > receive socket buffer sizes. This would increase burstiness in the network, which would affect traffic sharing paths through non-RED routers at least. Also, unless ABC is supported (3465), this would affect the fairness of TCP's ACK clocking= =2E > The use of the ACKNOW bit allows significant faster recovery times in > the presence of difficult network conditions. I don't think this should be a goal of a TCP modification, UNLESS the modification can be shown to do no harm in other, equally difficult network conditions. Whether this mod passes that test is not yet clear. Joe --------------enigB1CA62DDD42836DBB24DCB56 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 iD8DBQFFW0RyE5f5cImnZrsRAgtzAJsExTXHKkJa9RqkDqoq4Sy2XVNv/gCgwGt3 pBQQXtELrR7yEYczNCQ6mlY= =R0DK -----END PGP SIGNATURE----- --------------enigB1CA62DDD42836DBB24DCB56-- --===============0981151976== 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 --===============0981151976==-- From tcpm-bounces@ietf.org Wed Nov 15 11:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkO0o-0002bT-DN; Wed, 15 Nov 2006 11:53:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkO0m-0002bD-VC for tcpm@ietf.org; Wed, 15 Nov 2006 11:53:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkO0j-000871-Io for tcpm@ietf.org; Wed, 15 Nov 2006 11:53:20 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 08:53:18 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAFGrGTq015478; Wed, 15 Nov 2006 08:53:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kAFGrGW4024797; Wed, 15 Nov 2006 08:53:16 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 08:53:16 -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] Proposing ACKNOW bit in TCP header Date: Wed, 15 Nov 2006 08:53:15 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58027469DC@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Proposing ACKNOW bit in TCP header Thread-Index: AccItjXDFWzpDUcnQiWZ7JnKonJPtQAHKzOA From: "Anantha Ramaiah \(ananth\)" To: "Andre Oppermann" , X-OriginalArrivalTime: 15 Nov 2006 16:53:16.0496 (UTC) FILETIME=[8BCED500:01C708D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3548; t=1163609596; x=1164473596; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20Proposing=20ACKNOW=20bit=20in=20TCP=20header |Sender:=20; bh=OFdpX6fOqZ4n/k3kPm/h8O1qxXU1xAqHoTzaXNiKMUc=; b=hq9zrBLxzHoGy8dRw8adwAob9p7cQyGau78wcDFNSM5bR87x1lNWtAtpbQPtXBE6AIoWiJkz 5WJgq1hLNAvP7qa5d89m/KPQMnK/BMvBzc/4fjavyQ08AqL4YnKxiBbA; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Andre, Few observations : A) What happens if the sender tries to set the ACKNOW bit for every packet? I assume it is like as if the delayed ACK is completely turned off. I am not sure if this is acceptable. In other words how would you enforce which packet (segment to be precise) needs this special treatment? Or can the receiver chose to ignore the ACKNOW setting? B) The general feeling which I have gathered is that : the bits in the TCP header is a very scarce resource and the case for using need to be strong. See below.. C) Why can't you use TCP option? TCP option is scarce as well, but there have been some interest to extend them, atleast. Typically after complete processing the TCP header is done (which includes the TCP options, if the packet contains TCP options) the ACK gets sent. Some stacks have overloaded the header prediction functionality to include processing of TCP options. (atleast the important ones) Gernerally the TCP header bits are used for control messages (SYN, FIN, RST, ACK, URG) but the one which you are proposing sounds like a more fit in the TCP option space..=20 Anyways just a few thoughts, given the first read. -Anantha=20 > -----Original Message----- > From: Andre Oppermann [mailto:andre@freebsd.org]=20 > Sent: Wednesday, November 15, 2006 5:00 AM > To: tcpm@ietf.org > Subject: [tcpm] Proposing ACKNOW bit in TCP header >=20 > I propose to include an ACKNOW bit into the TCP header=20 > instructing the recipient to immediately, without any delay=20 > whatsoever, acknowledge the received segment. The bit=20 > location is the 9th bit in the TCP flags. > This bit is to be included in TCP SYN segments to indicate=20 > the support for it. Only if the SYN-ACK response has the bit=20 > set as well the session is allowed to make use of the ACKNOW feature. >=20 > Rationale: >=20 > During the slow start and congestion recovery phases the=20 > sender is dependent on immediate feedback to quickly make=20 > optimal use of all network resources again. The presence of=20 > delayed ACKs add unnecessary delays and introduces=20 > uncertainty to the recovery progress and the discovery of the=20 > true network conditions. On the other hand delayed ACKs=20 > serve an important function on fast networks with high PPS=20 > rates to improve efficiency and to coalesce the acknowledging=20 > of multiple segments at once. It is extremely difficult for=20 > the receiver to guess itself when to switch from delayed ACKs=20 > to immediate ACKs as it has only insufficient hints the=20 > current state the sender operates in. >=20 > The ACKNOW flag solves this in a simple and elegant way by=20 > allowing the sender to explicitly request an immediate ACK to=20 > its segments when it is appropriate for the congestion=20 > control recovery mechanism to do so. > As a second benefit a receiver on a ACKNOW flag enabled=20 > session may increase the delayed ACK from every other packet=20 > (as currently required) to a higher number, lets say every=20 > eighth. The exact value is to be determined based on the=20 > estimated delay*bandwidth product and the send/ receive=20 > socket buffer sizes. >=20 > The use of the ACKNOW bit allows significant faster recovery=20 > times in the presence of difficult network conditions. >=20 > -- > Andre >=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 Wed Nov 15 12:47:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOq7-0000fL-EA; Wed, 15 Nov 2006 12:46:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkOq6-0000f5-Js for tcpm@ietf.org; Wed, 15 Nov 2006 12:46:22 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkOq3-00078l-Qc for tcpm@ietf.org; Wed, 15 Nov 2006 12:46:22 -0500 Received: (qmail 22102 invoked from network); 15 Nov 2006 17:38:42 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 17:38:42 -0000 Message-ID: <455B5266.6010500@freebsd.org> Date: Wed, 15 Nov 2006 18:46:14 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <455B0F67.4000003@freebsd.org> <455B4472.3080402@isi.edu> In-Reply-To: <455B4472.3080402@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Joe Touch wrote: > Hi, Andre, > > Andre Oppermann wrote: >> I propose to include an ACKNOW bit into the TCP header instructing the >> recipient to immediately, without any delay whatsoever, acknowledge >> the received segment. > > This sounds like a fairly substantial change to TCP semantics. TCP has > only two kinds of headers that require a direct reply - SYN and FIN. I beg to differ, see below. > It seems like all other interactions are driven by only data packets, > and require the preceding data to have been correctly received to > generate a positive ACK. I.e., short of start/end of a connection, TCP > is more data driven than header driven. This would require a substantial > change to that semantic, which seems like it would require a substantial > revision. I think you're putting a bit too much into ACKNOW. The only thing that happens with ACKNOW flag set is the same as what happens on every other packet anyway, an ACK segment is generated by the receiver. The very same rules as ever apply to the values in it. The only meaning of ACKNOW is *not* to delay the ACK that would eventually happen anyway. Perhaps you were thinking that ACKNOW must ACK the current segment but that is not the case. The normal rules of ACKing only what has been received in sequence and yaddayaddayadda applies (SACK...). > Forcing the other end to react is also a DOS opportunity. How so? The other end would react anyway if it received this and the following segment. > Can anyone speak to whether SCTP handles this better, since this sounds > like a signalling issue? > >> Rationale: >> >> ...It is extremely difficult for the receiver to guess >> itself when to switch from delayed ACKs to immediate ACKs as it has >> only insufficient hints the current state the sender operates in. > > Can you clarify this? I thought delayed (compressed 2:1) ACKs were > required, period. It's only on the send side that delays are avoided, > e.g., depending on NAGLE. Nope. RFC2881 Section 4.2 lists them as SHOULD. It is perfectly legal for an implementation to ACK every packet. On the other hand it is not legal (and not efficient without ACKNOW or some reliable heuristic) to ACK less than every other segment. With ACKNOW it can easily be made legal and also cuts down on the network pps load quite a bit. >> ...As a second benefit a receiver on a ACKNOW flag enabled session may >> increase the delayed ACK from every other packet (as currently required) >> to a higher number, lets say every eighth. The exact value is to be >> determined based on the estimated delay*bandwidth product and the send/ >> receive socket buffer sizes. > > This would increase burstiness in the network, which would affect > traffic sharing paths through non-RED routers at least. Also, unless ABC > is supported (3465), this would affect the fairness of TCP's ACK clocking. Quite the opposite is the effect. With every ACK you have a much smoother curve than to do larger jumps where two segments are ACKed at the same time and may cause even larger jump bursts. >> The use of the ACKNOW bit allows significant faster recovery times in >> the presence of difficult network conditions. > > I don't think this should be a goal of a TCP modification, UNLESS the > modification can be shown to do no harm in other, equally difficult > network conditions. It doesn't. ACKNOW is a hybrid between a (perfectly legal) implementation ACKing every segment and one ACKing only every other. ACKNOW gives the advantages, benefits and efficiency of both worlds without the downsides of each (slower recovery times for delayed ACK vs. higher packet rate for every seg ACK). -- Andre > Whether this mod passes that test is not yet clear. > > Joe > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 12:57:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkP0h-0005i6-Ab; Wed, 15 Nov 2006 12:57:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkP0g-0005hx-0r for tcpm@ietf.org; Wed, 15 Nov 2006 12:57:18 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkP0e-0000Na-6k for tcpm@ietf.org; Wed, 15 Nov 2006 12:57:17 -0500 Received: (qmail 22177 invoked from network); 15 Nov 2006 17:49:43 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 17:49:43 -0000 Message-ID: <455B54FC.3050404@freebsd.org> Date: Wed, 15 Nov 2006 18:57:16 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <0C53DCFB700D144284A584F54711EC58027469DC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58027469DC@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Anantha Ramaiah (ananth) wrote: > Andre, > Few observations : > > A) What happens if the sender tries to set the ACKNOW bit for every > packet? I assume it is like as if the delayed ACK is completely turned > off. I am not sure if this is acceptable. In other words how would you > enforce which packet (segment to be precise) needs this special > treatment? Or can the receiver chose to ignore the ACKNOW setting? Turning delayed ACK off is perfectly legal. Doing/supporting delayed ACK is a SHOULD in RFC2581. With ACKNOW a receiver MUST send an ACK for every segment it received with this flag turned on. A low power/memory system may find this beneficial as it may only be able to hold one outstanding segment in the send buffer. Nanoprobes on wireless networks spring to mind. There is no DoS potential with ACKNOW. The sender may only cause one ACK reply per segment he sends. There is no amplification effect. It's sub-optimal but it's not fatal or dangerous in any way. > B) The general feeling which I have gathered is that : the bits in the > TCP header is a very scarce resource and the case for using need to be > strong. See below.. ACKNOW is a single flag and really suite to be placed in the TCP header. ACKNOW has real tangible benefits which are quickly and easily realized. ECN got not one but two bits in the TCP header with much less to show for. > C) Why can't you use TCP option? TCP option is scarce as well, but there > have been some interest to extend them, atleast. Typically after > complete processing the TCP header is done (which includes the TCP > options, if the packet contains TCP options) the ACK gets sent. Some > stacks have overloaded the header prediction functionality to include > processing of TCP options. (atleast the important ones) Any new TCP option causes much more overhead and waste. It consumes at least two full bytes in the SYN/SYN-ACK and every packet that sets it. That is seven bytes wasted on a quite scarce resource too. > Gernerally the TCP header bits are used for control messages (SYN, FIN, > RST, ACK, URG) but the one which you are proposing sounds like a more > fit in the TCP option space.. -- Andre > Anyways just a few thoughts, given the first read. > > -Anantha > >> -----Original Message----- >> From: Andre Oppermann [mailto:andre@freebsd.org] >> Sent: Wednesday, November 15, 2006 5:00 AM >> To: tcpm@ietf.org >> Subject: [tcpm] Proposing ACKNOW bit in TCP header >> >> I propose to include an ACKNOW bit into the TCP header >> instructing the recipient to immediately, without any delay >> whatsoever, acknowledge the received segment. The bit >> location is the 9th bit in the TCP flags. >> This bit is to be included in TCP SYN segments to indicate >> the support for it. Only if the SYN-ACK response has the bit >> set as well the session is allowed to make use of the ACKNOW feature. >> >> Rationale: >> >> During the slow start and congestion recovery phases the >> sender is dependent on immediate feedback to quickly make >> optimal use of all network resources again. The presence of >> delayed ACKs add unnecessary delays and introduces >> uncertainty to the recovery progress and the discovery of the >> true network conditions. On the other hand delayed ACKs >> serve an important function on fast networks with high PPS >> rates to improve efficiency and to coalesce the acknowledging >> of multiple segments at once. It is extremely difficult for >> the receiver to guess itself when to switch from delayed ACKs >> to immediate ACKs as it has only insufficient hints the >> current state the sender operates in. >> >> The ACKNOW flag solves this in a simple and elegant way by >> allowing the sender to explicitly request an immediate ACK to >> its segments when it is appropriate for the congestion >> control recovery mechanism to do so. >> As a second benefit a receiver on a ACKNOW flag enabled >> session may increase the delayed ACK from every other packet >> (as currently required) to a higher number, lets say every >> eighth. The exact value is to be determined based on the >> estimated delay*bandwidth product and the send/ receive >> socket buffer sizes. >> >> The use of the ACKNOW bit allows significant faster recovery >> times in the presence of difficult network conditions. >> >> -- >> Andre >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm >> > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 13:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkP3z-0006Yw-OC; Wed, 15 Nov 2006 13:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkP3y-0006Yq-5G for tcpm@ietf.org; Wed, 15 Nov 2006 13:00:42 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkP3w-0000rV-OF for tcpm@ietf.org; Wed, 15 Nov 2006 13:00:42 -0500 Received: from [127.0.0.1] (67.sub-75-209-245.myvzw.com [75.209.245.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAFI0BLp003425; Wed, 15 Nov 2006 10:00:18 -0800 (PST) Message-ID: <455B55A7.6070008@isi.edu> Date: Wed, 15 Nov 2006 10:00:07 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <455B0F67.4000003@freebsd.org> <455B4472.3080402@isi.edu> <455B5266.6010500@freebsd.org> In-Reply-To: <455B5266.6010500@freebsd.org> 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: 1.1 (+) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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="===============0402899461==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0402899461== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A4C3946CE98C68C7674F8E5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A4C3946CE98C68C7674F8E5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andre Oppermann wrote: > Joe Touch wrote: >> Hi, Andre, >> >> Andre Oppermann wrote: >>> I propose to include an ACKNOW bit into the TCP header instructing th= e >>> recipient to immediately, without any delay whatsoever, acknowledge >>> the received segment.=20 >> >> This sounds like a fairly substantial change to TCP semantics. TCP has= >> only two kinds of headers that require a direct reply - SYN and FIN. >=20 > I beg to differ, see below. >=20 >> It seems like all other interactions are driven by only data packets, >> and require the preceding data to have been correctly received to >> generate a positive ACK. I.e., short of start/end of a connection, TCP= >> is more data driven than header driven. This would require a substanti= al >> change to that semantic, which seems like it would require a substanti= al >> revision. >=20 > I think you're putting a bit too much into ACKNOW. The only thing that= > happens with ACKNOW flag set is the same as what happens on every other= > packet anyway, an ACK segment is generated by the receiver. The very > same rules as ever apply to the values in it. >=20 > The only meaning of ACKNOW is *not* to delay the ACK that would eventua= lly > happen anyway. >=20 > Perhaps you were thinking that ACKNOW must ACK the current segment > but that is not the case. The normal rules of ACKing only what has > been received in sequence and yaddayaddayadda applies (SACK...). Yes, I was. So this means "ACK this immediately" where "immediately" means only when all the data up to this point has been received? Otherwise, how do you know that the ACK you get back had anything to do with the ACKNOW? >> Forcing the other end to react is also a DOS opportunity. >=20 > How so? The other end would react anyway if it received this and the > following segment. It is only in the case I assumed above. >> Can anyone speak to whether SCTP handles this better, since this sound= s >> like a signalling issue? >> >>> Rationale: >>> >>> ...It is extremely difficult for the receiver to guess >>> itself when to switch from delayed ACKs to immediate ACKs as it has >>> only insufficient hints the current state the sender operates in. >> >> Can you clarify this? I thought delayed (compressed 2:1) ACKs were >> required, period. It's only on the send side that delays are avoided, >> e.g., depending on NAGLE. >=20 > Nope. RFC2881 Section 4.2 lists them as SHOULD. It is perfectly legal= > for an implementation to ACK every packet. On the other hand it is not= > legal (and not efficient without ACKNOW or some reliable heuristic) to > ACK less than every other segment. With ACKNOW it can easily be made > legal and also cuts down on the network pps load quite a bit. Without ABC, it'll slow the CWND algorithms. >>> ...As a second benefit a receiver on a ACKNOW flag enabled session ma= y >>> increase the delayed ACK from every other packet (as currently requir= ed) >>> to a higher number, lets say every eighth. The exact value is to be >>> determined based on the estimated delay*bandwidth product and the sen= d/ >>> receive socket buffer sizes. >> >> This would increase burstiness in the network, which would affect >> traffic sharing paths through non-RED routers at least. Also, unless A= BC >> is supported (3465), this would affect the fairness of TCP's ACK >> clocking. >=20 > Quite the opposite is the effect. With every ACK you have a much smoot= her > curve than to do larger jumps where two segments are ACKed at the same > time and may cause even larger jump bursts. You suggested an ACK every 8th (e.g.); that means that the ACK would cause the window to jump 8 segments, which means the sender would burst them out. >>> The use of the ACKNOW bit allows significant faster recovery times in= >>> the presence of difficult network conditions. >> >> I don't think this should be a goal of a TCP modification, UNLESS the >> modification can be shown to do no harm in other, equally difficult >> network conditions. >=20 > It doesn't. ACKNOW is a hybrid between a (perfectly legal) implementat= ion > ACKing every segment and one ACKing only every other. ACKNOW gives the= > advantages, benefits and efficiency of both worlds without the downside= s > of each (slower recovery times for delayed ACK vs. higher packet rate f= or > every seg ACK). It seems like it requires ABC or you have unpredictable effects on congestion window growth. If you add this to ABC, do you still get a benefit? Joe --------------enig0A4C3946CE98C68C7674F8E5 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 iD8DBQFFW1WnE5f5cImnZrsRAtDdAJ9e+8pQ9L7PDy8bu6s9HjBB8vqDeACfUX2c eJbNw3hwgpmStiKYYTVRRtQ= =HPiQ -----END PGP SIGNATURE----- --------------enig0A4C3946CE98C68C7674F8E5-- --===============0402899461== 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 --===============0402899461==-- From tcpm-bounces@ietf.org Wed Nov 15 13:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPaX-0003nx-NI; Wed, 15 Nov 2006 13:34:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPaW-0003mk-4N for tcpm@ietf.org; Wed, 15 Nov 2006 13:34:20 -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 1GkPaT-0005eg-Ce for tcpm@ietf.org; Wed, 15 Nov 2006 13:34:20 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id kAFIYBLl012903; Wed, 15 Nov 2006 10:34:11 -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); Wed, 15 Nov 2006 10:34:10 -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); Wed, 15 Nov 2006 10:34:10 -0800 In-Reply-To: <455B0F67.4000003@freebsd.org> References: <455B0F67.4000003@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9579CAE9-7611-46C4-A224-739BEB049A25@windriver.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Date: Wed, 15 Nov 2006 12:35:05 -0600 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Nov 2006 18:34:10.0664 (UTC) FILETIME=[A45F8E80:01C708E4] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Andre, On the surface this might seem like a clean and simple idea, but it really isn't. There are other ramifications of such a change, and the statement of what is really desired needs to be explored more deeply. As I read your description for ACKNOW, it's a way for the sending TCP to say "I'm not sending any more data, so send me an ACK now!" I really don't see the need for a separate ACKNOW bit, this same functionality could be implemented using the PUSH bit (which says "I'm not sending any more data, so make all the data I've sent so far available to the application".) Hence, the ACKNOW functionality as you describe could be implemented just by using the PUSH bit. But that doesn't address the issue of whether or not this is a good thing to do. Returning ACKs are not just used to clock out new data and open the congestion window, they are also used for calculating RTT, which is used for deciding when to retransmit unacknowledged segments. If your RTT is too short, you are in danger of retransmitting too soon. So your RTT isn't just how long it takes packets to get to the other side, it also needs to account for any latency, including the time it takes for delayed ACKs to be sent. Every ACKNOW packet is an exception to the normal delayed ACK processing, and will produce a RTT measurement that does not account for latency due to delayed ACK processing. Decreasing the length of delayed ACKs (as suggested, to every 8th packet) could cause harm to the clocking out of new data, based on the ACKs. In steady state, I could see this leading to even burstier traffic, unless the sender is regularly setting the ACKNOW bit, in which case we now have the sender deciding the delayed ACK strategy for the receiver... that seems like a potential source of problems. In general, though, I think that a better approach is to develop a TCP sending strategy that takes into account the presence of delayed ACKS, rather than trying to develop a strategy the circumvents the presence of delayed ACKs. For example, just increasing the initial TCP window (RFC 3390) to two segments can eliminate the latency induced by delayed ACKs at connection start-up. Adding an ACKNOW bit is a solution, not a problem. Discussion at this point should be focused on what the problem is that needs addressing, rather than whether a particular solution to that problem is a good solution. -David Borman On Nov 15, 2006, at 7:00 AM, Andre Oppermann wrote: > I propose to include an ACKNOW bit into the TCP header instructing the > recipient to immediately, without any delay whatsoever, acknowledge > the received segment. The bit location is the 9th bit in the TCP > flags. > This bit is to be included in TCP SYN segments to indicate the support > for it. Only if the SYN-ACK response has the bit set as well the > session > is allowed to make use of the ACKNOW feature. > > Rationale: > > During the slow start and congestion recovery phases the sender is > dependent on immediate feedback to quickly make optimal use of all > network resources again. The presence of delayed ACKs add unnecessary > delays and introduces uncertainty to the recovery progress and the > discovery of the true network conditions. On the other hand delayed > ACKs serve an important function on fast networks with high PPS rates > to improve efficiency and to coalesce the acknowledging of multiple > segments at once. It is extremely difficult for the receiver to guess > itself when to switch from delayed ACKs to immediate ACKs as it has > only insufficient hints the current state the sender operates in. > > The ACKNOW flag solves this in a simple and elegant way by allowing > the > sender to explicitly request an immediate ACK to its segments when > it is > appropriate for the congestion control recovery mechanism to do so. > As a second benefit a receiver on a ACKNOW flag enabled session may > increase the delayed ACK from every other packet (as currently > required) > to a higher number, lets say every eighth. The exact value is to be > determined based on the estimated delay*bandwidth product and the > send/ > receive socket buffer sizes. > > The use of the ACKNOW bit allows significant faster recovery times in > the presence of difficult network conditions. > > -- > Andre > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 13:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPgV-0007xs-Sg; Wed, 15 Nov 2006 13:40:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPgU-0007xi-HB for tcpm@ietf.org; Wed, 15 Nov 2006 13:40:30 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPgT-0006Qh-15 for tcpm@ietf.org; Wed, 15 Nov 2006 13:40:30 -0500 Received: (qmail 22620 invoked from network); 15 Nov 2006 18:32:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 18:32:55 -0000 Message-ID: <455B5F1B.2030303@freebsd.org> Date: Wed, 15 Nov 2006 19:40:27 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <455B0F67.4000003@freebsd.org> <455B4472.3080402@isi.edu> <455B5266.6010500@freebsd.org> <455B55A7.6070008@isi.edu> In-Reply-To: <455B55A7.6070008@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Joe Touch wrote: > Andre Oppermann wrote: >> Perhaps you were thinking that ACKNOW must ACK the current segment >> but that is not the case. The normal rules of ACKing only what has >> been received in sequence and yaddayaddayadda applies (SACK...). > > Yes, I was. So this means "ACK this immediately" where "immediately" > means only when all the data up to this point has been received? > Otherwise, how do you know that the ACK you get back had anything to do > with the ACKNOW? I don't. And I don't have to. All I'm requesting with the ACKNOW flag is to produce an response *now* instead of potentially waiting for 200- 1000ms until the delayed ACK timer at the receivers end expires. >>> Forcing the other end to react is also a DOS opportunity. >> How so? The other end would react anyway if it received this and the >> following segment. > > It is only in the case I assumed above. > >>> Can anyone speak to whether SCTP handles this better, since this sounds >>> like a signalling issue? >>> >>>> Rationale: >>>> >>>> ...It is extremely difficult for the receiver to guess >>>> itself when to switch from delayed ACKs to immediate ACKs as it has >>>> only insufficient hints the current state the sender operates in. >>> Can you clarify this? I thought delayed (compressed 2:1) ACKs were >>> required, period. It's only on the send side that delays are avoided, >>> e.g., depending on NAGLE. >> Nope. RFC2881 Section 4.2 lists them as SHOULD. It is perfectly legal >> for an implementation to ACK every packet. On the other hand it is not >> legal (and not efficient without ACKNOW or some reliable heuristic) to >> ACK less than every other segment. With ACKNOW it can easily be made >> legal and also cuts down on the network pps load quite a bit. > > Without ABC, it'll slow the CWND algorithms. You mean the congestion avoidance algorithm as defined in RFC2581 3.1? Yes, it would slow it down. OTOH ACKNOW is under the control of the sender and until a steady state plateau is reached it may set ACKNOW on every other segment after the initial slow start phase where it was set on every segment. >>>> ...As a second benefit a receiver on a ACKNOW flag enabled session may >>>> increase the delayed ACK from every other packet (as currently required) >>>> to a higher number, lets say every eighth. The exact value is to be >>>> determined based on the estimated delay*bandwidth product and the send/ >>>> receive socket buffer sizes. >>> This would increase burstiness in the network, which would affect >>> traffic sharing paths through non-RED routers at least. Also, unless ABC >>> is supported (3465), this would affect the fairness of TCP's ACK >>> clocking. >> Quite the opposite is the effect. With every ACK you have a much smoother >> curve than to do larger jumps where two segments are ACKed at the same >> time and may cause even larger jump bursts. > > You suggested an ACK every 8th (e.g.); that means that the ACK would > cause the window to jump 8 segments, which means the sender would burst > them out. Which is not much of a problem. Even RFC2414 allows up to 4 segments to burst into the network in the initial send of a just established connection. Things like TSO (TCP segmentation offload) get very happy with this. As long as it is not every 1/100th segment networks won't break down. Although I agree that this topic should be clearly discussed and specified in any RFC that may come out of the ACKNOW proposal. You have to keep in mind though that the centerpiece of ACKNOW is not to allow further spaced ACKs but to selectively override delayed ACK which causes much pain and inefficiency for fast recovery. >>>> The use of the ACKNOW bit allows significant faster recovery times in >>>> the presence of difficult network conditions. >>> I don't think this should be a goal of a TCP modification, UNLESS the >>> modification can be shown to do no harm in other, equally difficult >>> network conditions. >> It doesn't. ACKNOW is a hybrid between a (perfectly legal) implementation >> ACKing every segment and one ACKing only every other. ACKNOW gives the >> advantages, benefits and efficiency of both worlds without the downsides >> of each (slower recovery times for delayed ACK vs. higher packet rate for >> every seg ACK). > > It seems like it requires ABC or you have unpredictable effects on > congestion window growth. If you add this to ABC, do you still get a > benefit? No, it doesn't require ABC. Yes, with ABC the benefits stay the same. See the formula (1) in RFC2581 Section 3.1. (Leaving the ACK stretching, which is a separate and way less important topic, out of the picture.) -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 14:00:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPyv-0007VZ-Hc; Wed, 15 Nov 2006 13:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPyt-0007VO-7W for tcpm@ietf.org; Wed, 15 Nov 2006 13:59:31 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPyr-000541-Jg for tcpm@ietf.org; Wed, 15 Nov 2006 13:59:31 -0500 Received: (qmail 22859 invoked from network); 15 Nov 2006 18:51:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 18:51:52 -0000 Message-ID: <455B638D.2010400@freebsd.org> Date: Wed, 15 Nov 2006 19:59:25 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <455B0F67.4000003@freebsd.org> <9579CAE9-7611-46C4-A224-739BEB049A25@windriver.com> In-Reply-To: <9579CAE9-7611-46C4-A224-739BEB049A25@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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 David Borman wrote: > Andre, > > On the surface this might seem like a clean and simple idea, but it > really isn't. There are other ramifications of such a change, and the > statement of what is really desired needs to be explored more deeply. > > As I read your description for ACKNOW, it's a way for the sending TCP to > say "I'm not sending any more data, so send me an ACK now!" I really > don't see the need for a separate ACKNOW bit, this same functionality > could be implemented using the PUSH bit (which says "I'm not sending any > more data, so make all the data I've sent so far available to the > application".) Hence, the ACKNOW functionality as you describe could be > implemented just by using the PUSH bit. But that doesn't address the > issue of whether or not this is a good thing to do. Nope. I don't particularly care about a quick ACK when I'm finished with sending. I care about quickly reaching steady state from either connection start (slow start) or a loss recovery when I've got a lot more yet to send. > Returning ACKs are not just used to clock out new data and open the > congestion window, they are also used for calculating RTT, which is used > for deciding when to retransmit unacknowledged segments. If your RTT is > too short, you are in danger of retransmitting too soon. So your RTT > isn't just how long it takes packets to get to the other side, it also > needs to account for any latency, including the time it takes for > delayed ACKs to be sent. Every ACKNOW packet is an exception to the > normal delayed ACK processing, and will produce a RTT measurement that > does not account for latency due to delayed ACK processing. Your RTT can't be too short. It can, and too often is, too long. The definition of RTT is very simple and is the time it takes from leaving the senders socket buffer to arrival in the receivers socket buffer. No artificial ACK delays included. It's a fact that ACKs get delayed by the delayed ACK mechanism and that really screws up fast recovery because delACK can't be turned off reliably. To optimally size my send and receive socket buffers I want to know the real RTT and not some artificial number with +0-500ms variance. > Decreasing the length of delayed ACKs (as suggested, to every 8th > packet) could cause harm to the clocking out of new data, based on the > ACKs. In steady state, I could see this leading to even burstier > traffic, unless the sender is regularly setting the ACKNOW bit, in which > case we now have the sender deciding the delayed ACK strategy for the > receiver... that seems like a potential source of problems. Well, the ACKs clock the sender so it should have some say in there. It may allow for smarter congestion control algorithms. Like I said in other replies the ACK stretching is not the core rationale but a possibly useful side effect given the right care. > In general, though, I think that a better approach is to develop a TCP > sending strategy that takes into account the presence of delayed ACKS, > rather than trying to develop a strategy the circumvents the presence of > delayed ACKs. For example, just increasing the initial TCP window (RFC > 3390) to two segments can eliminate the latency induced by delayed ACKs > at connection start-up. Adding an ACKNOW bit is a solution, not a > problem. Discussion at this point should be focused on what the problem > is that needs addressing, rather than whether a particular solution to > that problem is a good solution. TCPM history is rich with such attempts to algorithmic blind guessing. So far none seems to have worked out really well or it would be widely implemented already. -- Andre > -David Borman > > > On Nov 15, 2006, at 7:00 AM, Andre Oppermann wrote: > >> I propose to include an ACKNOW bit into the TCP header instructing the >> recipient to immediately, without any delay whatsoever, acknowledge >> the received segment. The bit location is the 9th bit in the TCP flags. >> This bit is to be included in TCP SYN segments to indicate the support >> for it. Only if the SYN-ACK response has the bit set as well the session >> is allowed to make use of the ACKNOW feature. >> >> Rationale: >> >> During the slow start and congestion recovery phases the sender is >> dependent on immediate feedback to quickly make optimal use of all >> network resources again. The presence of delayed ACKs add unnecessary >> delays and introduces uncertainty to the recovery progress and the >> discovery of the true network conditions. On the other hand delayed >> ACKs serve an important function on fast networks with high PPS rates >> to improve efficiency and to coalesce the acknowledging of multiple >> segments at once. It is extremely difficult for the receiver to guess >> itself when to switch from delayed ACKs to immediate ACKs as it has >> only insufficient hints the current state the sender operates in. >> >> The ACKNOW flag solves this in a simple and elegant way by allowing the >> sender to explicitly request an immediate ACK to its segments when it is >> appropriate for the congestion control recovery mechanism to do so. >> As a second benefit a receiver on a ACKNOW flag enabled session may >> increase the delayed ACK from every other packet (as currently required) >> to a higher number, lets say every eighth. The exact value is to be >> determined based on the estimated delay*bandwidth product and the send/ >> receive socket buffer sizes. >> >> The use of the ACKNOW bit allows significant faster recovery times in >> the presence of difficult network conditions. >> >> --Andre >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 14:31:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQTS-0003tn-8L; Wed, 15 Nov 2006 14:31:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQTR-0003sD-FG for tcpm@ietf.org; Wed, 15 Nov 2006 14:31:05 -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 1GkQTP-00045O-Vc for tcpm@ietf.org; Wed, 15 Nov 2006 14:31:05 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.3) with ESMTP id kAFJUUt4025999; Wed, 15 Nov 2006 11:30:30 -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); Wed, 15 Nov 2006 11:30:29 -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); Wed, 15 Nov 2006 11:30:29 -0800 In-Reply-To: <455B638D.2010400@freebsd.org> References: <455B0F67.4000003@freebsd.org> <9579CAE9-7611-46C4-A224-739BEB049A25@windriver.com> <455B638D.2010400@freebsd.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] Proposing ACKNOW bit in TCP header Date: Wed, 15 Nov 2006 13:31:24 -0600 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Nov 2006 19:30:29.0806 (UTC) FILETIME=[827FB4E0:01C708EC] X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Nov 15, 2006, at 12:59 PM, Andre Oppermann wrote: > David Borman wrote: ... >> As I read your description for ACKNOW, it's a way for the sending >> TCP to say "I'm not sending any more data, so send me an ACK >> now!" I really don't see the need for a separate ACKNOW bit, this >> same functionality could be implemented using the PUSH bit (which >> says "I'm not sending any more data, so make all the data I've >> sent so far available to the application".) Hence, the ACKNOW >> functionality as you describe could be implemented just by using >> the PUSH bit. But that doesn't address the issue of whether or >> not this is a good thing to do. > > Nope. I don't particularly care about a quick ACK when I'm finished > with sending. I care about quickly reaching steady state from either > connection start (slow start) or a loss recovery when I've got a lot > more yet to send. Hey, I didn't say it was a good or well thought out example. :-) I wasn't thinking of the PUSH bit as only being set when there is no more data to send, it could also set it when you won't send anymore data, even if you do have more data to send. The point is, you have more data to send, you aren't going to send it until you get an ACK from the other side, so you want a quick ACK and the PUSH bit could be used to indicate that instead of adding a new ACKNOW bit. The fact the ACK would also come back quicker when you are finished sending doesn't matter. And I'm not saying that I'd support adding these semantics to the PUSH bit any more than I'd support adding an ACKNOW bit. > >> Returning ACKs are not just used to clock out new data and open >> the congestion window, they are also used for calculating RTT, >> which is used for deciding when to retransmit unacknowledged >> segments. If your RTT is too short, you are in danger of >> retransmitting too soon. So your RTT isn't just how long it takes >> packets to get to the other side, it also needs to account for any >> latency, including the time it takes for delayed ACKs to be sent. >> Every ACKNOW packet is an exception to the normal delayed ACK >> processing, and will produce a RTT measurement that does not >> account for latency due to delayed ACK processing. > > Your RTT can't be too short. It can, and too often is, too long. > The definition of RTT is very simple and is the time it takes from > leaving the senders socket buffer to arrival in the receivers socket > buffer. No artificial ACK delays included. It's a fact that ACKs > get delayed by the delayed ACK mechanism and that really screws up > fast recovery because delACK can't be turned off reliably. To > optimally > size my send and receive socket buffers I want to know the real RTT > and not some artificial number with +0-500ms variance. Umm... no. RTT = Round Trip Time. It's not one way, it's how long it takes to send data and to get back and ACK for that data. And that includes any latency, including delayed ACKs. It's the returning ACK that prevents retransmissions, so decisions on when to retransmit need to take into account the full RTT, including delay in the ACKs, or you may have unnecessary retransmits due to delayed ACKs. ... >> In general, though, I think that a better approach is to develop a >> TCP sending strategy that takes into account the presence of >> delayed ACKS, rather than trying to develop a strategy the >> circumvents the presence of delayed ACKs. For example, just >> increasing the initial TCP window (RFC 3390) to two segments can >> eliminate the latency induced by delayed ACKs at connection start- >> up. Adding an ACKNOW bit is a solution, not a problem. >> Discussion at this point should be focused on what the problem is >> that needs addressing, rather than whether a particular solution >> to that problem is a good solution. > > TCPM history is rich with such attempts to algorithmic blind guessing. > So far none seems to have worked out really well or it would be widely > implemented already. The perhaps the focus should be on the algorithmic delayed ACK strategy, to make it deterministic. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 14:41:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQcw-00089t-EE; Wed, 15 Nov 2006 14:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQcv-00089l-6C for tcpm@ietf.org; Wed, 15 Nov 2006 14:40:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkQct-0006ae-Mg for tcpm@ietf.org; Wed, 15 Nov 2006 14:40:53 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 11:40:51 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAFJep2A025584; Wed, 15 Nov 2006 11:40:51 -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 kAFJepin029019; Wed, 15 Nov 2006 11:40:51 -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); Wed, 15 Nov 2006 11:40:50 -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] Proposing ACKNOW bit in TCP header Date: Wed, 15 Nov 2006 11:38:47 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5802746ACE@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Proposing ACKNOW bit in TCP header Thread-Index: AccI331WHHtCHN23Q3uiyyeraBnejQACj0ow From: "Anantha Ramaiah \(ananth\)" To: "Andre Oppermann" X-OriginalArrivalTime: 15 Nov 2006 19:40:50.0838 (UTC) FILETIME=[F4A9AB60:01C708ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1904; t=1163619651; x=1164483651; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20Proposing=20ACKNOW=20bit=20in=20TCP=20header |Sender:=20; bh=PXjNngGRjHhbKSHmDt1JWYsk247ZKH67MmfO1B9ttfs=; b=LwmR6DM6S+fFybM2baVX+F986+Yu6NPIz2lu27b6vRh1fx7KvR/mwFKDYMlvQ0irnL8mwqRk kRsoouAFM+lFZhsJjpD+stU2r3f39gqJDu6j7D1prKlsDZi4WAF9/gWn; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 > -----Original Message----- > From: Andre Oppermann [mailto:andre@freebsd.org]=20 > Sent: Wednesday, November 15, 2006 9:57 AM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header >=20 > Anantha Ramaiah (ananth) wrote: > > Andre, > > Few observations : > >=20 > > A) What happens if the sender tries to set the ACKNOW bit for every=20 > > packet? I assume it is like as if the delayed ACK is=20 > completely turned=20 > > off. I am not sure if this is acceptable. In other words=20 > how would you=20 > > enforce which packet (segment to be precise) needs this special=20 > > treatment? Or can the receiver chose to ignore the ACKNOW setting? >=20 > Turning delayed ACK off is perfectly legal. Doing/supporting=20 > delayed ACK is a SHOULD in RFC2581. I understand it is a SHOULD. I was thinking in much more simpler terms. Typically the delayed ACK is : - either a system wide knob OR - a per connection TCP property. In both cases with the ACKNOW we would be changing the behaviour by *not* waiting for 200ms. This is something we don't want to encourage through the back door (via ACKNOW).=20 Even if the delayed ACK is turned off, some stacks have the ACK policy of ACK every n segments where n =3D 2 (sometimes 4). The ACKNOW would change this without applications knowledge. While it may seem simple, this would lead to a nightmare in troubleshooting RTT issues and there are applications out there which use TCP probes to calculate end to end delays. IMO your draft needs to spell out this clearly about the ramifications of such a behaviour, since you use a "MUST" clause. Just to clarify : If the receiver has data already to be sent, it MUST piggyback it and shouldn't blindly honor ACKNOW. This is not explicit and I assume you would state this in the draft. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 15:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQyC-0001iU-RS; Wed, 15 Nov 2006 15:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQyA-0001iP-VY for tcpm@ietf.org; Wed, 15 Nov 2006 15:02:50 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkQy7-0002Yd-4f for tcpm@ietf.org; Wed, 15 Nov 2006 15:02:50 -0500 Received: (qmail 23514 invoked from network); 15 Nov 2006 19:55:09 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 19:55:09 -0000 Message-ID: <455B7261.2030109@freebsd.org> Date: Wed, 15 Nov 2006 21:02:41 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <0C53DCFB700D144284A584F54711EC5802746ACE@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5802746ACE@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) 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: , Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: > >> -----Original Message----- >> From: Andre Oppermann [mailto:andre@freebsd.org] >> Sent: Wednesday, November 15, 2006 9:57 AM >> To: Anantha Ramaiah (ananth) >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header >> >> Anantha Ramaiah (ananth) wrote: >>> Andre, >>> Few observations : >>> >>> A) What happens if the sender tries to set the ACKNOW bit for every >>> packet? I assume it is like as if the delayed ACK is >> completely turned >>> off. I am not sure if this is acceptable. In other words >> how would you >>> enforce which packet (segment to be precise) needs this special >>> treatment? Or can the receiver chose to ignore the ACKNOW setting? >> Turning delayed ACK off is perfectly legal. Doing/supporting >> delayed ACK is a SHOULD in RFC2581. > > I understand it is a SHOULD. I was thinking in much more simpler terms. > Typically the delayed ACK is : > - either a system wide knob OR > - a per connection TCP property. > In both cases with the ACKNOW we would be changing the behaviour by > *not* waiting for 200ms. This is something we don't want to encourage > through the back door (via ACKNOW). Why not in those cases where it would provide benefits? Delayed ACK is a tradeoff which at the moment is static. ACKNOW gives the option to take away the negative sides to it. For reference: maximal legal delACK time is 500ms. > Even if the delayed ACK is turned off, some stacks have the ACK policy > of ACK every n segments where n = 2 (sometimes 4). The ACKNOW would > change this without applications knowledge. While it may seem simple, > this would lead to a nightmare in troubleshooting RTT issues and there > are applications out there which use TCP probes to calculate end to end > delays. The idea of TCP is that it should be transparent to the application using it. Any time an application has to fiddle with TCP internals it's a bug. Unfortunately in reality sometimes the application has to make it's intent more clear by setting 'NO_DELAY' or such. These should be the exceptions. Using a TCP probe to measure end to end delays is highly difficult anyway as you never know what you measure; the network delay or the artificial ACK delay and its variance. And TCP never guarantees you that when the write() call returns your data actually appeared on the wire. It may as well sit in the send buffer waiting for clearance. I've tried to accurately measure the real network RTT in the kernel based on TCP ACKs and timestamps and it is not possible unless you have long steady state bulk transfers. Unfortunately by the time reach that plateau it doesn't have that much value anymore. > IMO your draft needs to spell out this clearly about the ramifications > of such a behaviour, since you use a "MUST" clause. Agreed. :-) > Just to clarify : If the receiver has data already to be sent, it MUST > piggyback it and shouldn't blindly honor ACKNOW. This is not explicit > and I assume you would state this in the draft. Indeed. -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 15:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRGr-0000cJ-3A; Wed, 15 Nov 2006 15:22:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRGp-0000cE-Oy for tcpm@ietf.org; Wed, 15 Nov 2006 15:22:07 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRGo-000662-5d for tcpm@ietf.org; Wed, 15 Nov 2006 15:22:07 -0500 Received: (qmail 23718 invoked from network); 15 Nov 2006 20:14:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2006 20:14:32 -0000 Message-ID: <455B76ED.8050005@freebsd.org> Date: Wed, 15 Nov 2006 21:22:05 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <455B0F67.4000003@freebsd.org> <9579CAE9-7611-46C4-A224-739BEB049A25@windriver.com> <455B638D.2010400@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 David Borman wrote: > > On Nov 15, 2006, at 12:59 PM, Andre Oppermann wrote: > >> David Borman wrote: > ... >>> As I read your description for ACKNOW, it's a way for the sending TCP >>> to say "I'm not sending any more data, so send me an ACK now!" I >>> really don't see the need for a separate ACKNOW bit, this same >>> functionality could be implemented using the PUSH bit (which says >>> "I'm not sending any more data, so make all the data I've sent so far >>> available to the application".) Hence, the ACKNOW functionality as >>> you describe could be implemented just by using the PUSH bit. But >>> that doesn't address the issue of whether or not this is a good thing >>> to do. >> >> Nope. I don't particularly care about a quick ACK when I'm finished >> with sending. I care about quickly reaching steady state from either >> connection start (slow start) or a loss recovery when I've got a lot >> more yet to send. > > Hey, I didn't say it was a good or well thought out example. :-) I > wasn't thinking of the PUSH bit as only being set when there is no more > data to send, it could also set it when you won't send anymore data, > even if you do have more data to send. The point is, you have more data > to send, you aren't going to send it until you get an ACK from the other > side, so you want a quick ACK and the PUSH bit could be used to indicate > that instead of adding a new ACKNOW bit. The fact the ACK would also > come back quicker when you are finished sending doesn't matter. And I'm > not saying that I'd support adding these semantics to the PUSH bit any > more than I'd support adding an ACKNOW bit. Redefining the PUSH bit this would seem risky and really dirty as the meaning is really different. And there would be no way for the two endpoints to distinguish if the opponent supports the ACKNOW feature or not. >>> Returning ACKs are not just used to clock out new data and open the >>> congestion window, they are also used for calculating RTT, which is >>> used for deciding when to retransmit unacknowledged segments. If >>> your RTT is too short, you are in danger of retransmitting too soon. >>> So your RTT isn't just how long it takes packets to get to the other >>> side, it also needs to account for any latency, including the time it >>> takes for delayed ACKs to be sent. Every ACKNOW packet is an >>> exception to the normal delayed ACK processing, and will produce a >>> RTT measurement that does not account for latency due to delayed ACK >>> processing. >> >> Your RTT can't be too short. It can, and too often is, too long. >> The definition of RTT is very simple and is the time it takes from >> leaving the senders socket buffer to arrival in the receivers socket >> buffer. No artificial ACK delays included. It's a fact that ACKs >> get delayed by the delayed ACK mechanism and that really screws up >> fast recovery because delACK can't be turned off reliably. To optimally >> size my send and receive socket buffers I want to know the real RTT >> and not some artificial number with +0-500ms variance. > > Umm... no. RTT = Round Trip Time. It's not one way, it's how long it > takes to send data and to get back and ACK for that data. And that > includes any latency, including delayed ACKs. It's the returning ACK > that prevents retransmissions, so decisions on when to retransmit need > to take into account the full RTT, including delay in the ACKs, or you > may have unnecessary retransmits due to delayed ACKs. I stand corrected. I was thinking of what you said regarding full round trip but didn't write it. ;-) The delayed ACK tries to squash a two of flies at once with varying success: a) ACK only every other segment to conserve bandwidth/pps b) to give the chance to piggyback the ACK on a data segment back to the sender Ideally the delayed ACK timer calibrates itself to once RTT + fudge like the retransmission timer instead of being a fixed value. That way it can generate much more timely feedback to the sender. For b) the sender could implement a fairly simply heuristic to determine if this applies at all and a ping-pong protocol is active. Unfortunately this can only come to play after a number of segments have been exchanged and the measurements have converged and settled thus we lose out on the early part of the connection where it matters most. ACKNOW would solve that. > ... >>> In general, though, I think that a better approach is to develop a >>> TCP sending strategy that takes into account the presence of delayed >>> ACKS, rather than trying to develop a strategy the circumvents the >>> presence of delayed ACKs. For example, just increasing the initial >>> TCP window (RFC 3390) to two segments can eliminate the latency >>> induced by delayed ACKs at connection start-up. Adding an ACKNOW bit >>> is a solution, not a problem. Discussion at this point should be >>> focused on what the problem is that needs addressing, rather than >>> whether a particular solution to that problem is a good solution. >> >> TCPM history is rich with such attempts to algorithmic blind guessing. >> So far none seems to have worked out really well or it would be widely >> implemented already. > > The perhaps the focus should be on the algorithmic delayed ACK strategy, > to make it deterministic. Making a black box deterministic is a very fine art. ;-) -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 15 16:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSTO-00088k-Vp; Wed, 15 Nov 2006 16:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSTN-00086b-40 for tcpm@ietf.org; Wed, 15 Nov 2006 16:39:09 -0500 Received: from gateway.insightbb.com ([74.128.0.19] helo=asav07.insightbb.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSTJ-0003fj-Ry for tcpm@ietf.org; Wed, 15 Nov 2006 16:39:09 -0500 Received: from unknown (HELO elb.elitists.net) ([74.140.122.125]) by asav07.insightbb.com with ESMTP; 15 Nov 2006 16:39:05 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALEWW0VKjHp9/2dsb2JhbAA Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 80CEF2BE21 for ; Wed, 15 Nov 2006 16:39:04 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id E519127CC2; Wed, 15 Nov 2006 16:39:03 -0500 (EST) Date: Wed, 15 Nov 2006 16:39:03 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Message-ID: <20061115213903.GG1618@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <455B0F67.4000003@freebsd.org> <455B4472.3080402@isi.edu> <455B5266.6010500@freebsd.org> <455B55A7.6070008@isi.edu> <455B5F1B.2030303@freebsd.org> MIME-Version: 1.0 In-Reply-To: <455B5F1B.2030303@freebsd.org> 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.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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="===============1770238668==" Errors-To: tcpm-bounces@ietf.org --===============1770238668== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UTZ8bGhNySVQ9LYl" Content-Disposition: inline --UTZ8bGhNySVQ9LYl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andre Oppermann spake unto us the following wisdom: > >Yes, I was. So this means "ACK this immediately" where "immediately" > >means only when all the data up to this point has been received? > >Otherwise, how do you know that the ACK you get back had anything to do > >with the ACKNOW? >=20 > I don't. And I don't have to. All I'm requesting with the ACKNOW flag > is to produce an response *now* instead of potentially waiting for 200- > 1000ms until the delayed ACK timer at the receivers end expires. I'm not convinced we're all talking about the same problem here. This kind of delay will *only* happen to the last packet in a flight, because otherwise the next packet to arrive will clock out the ACK. Additionally, 500ms is specified as the *maximum* delay that a receiver can impose. (Both of these are in RFC2581, section 4.2.) In addition, segments being ACKed during loss recovery SHOULD be ACKed immediately (also RFC2581, section 4.2). I think you're solving a completely imaginary problem with ACKNOW. Please show us a real scenario (which is not handled by ABC, RFC3465) where delayed ACKs pose a real performance problem. All of the scenarios I have seen cited are misunderstandings, and don't happen in the real world. 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 --UTZ8bGhNySVQ9LYl 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) iD8DBQFFW4j3r9kA9Ig8HBQRAgshAKC12/crYUhyOyvahKahSjjntBPiwACguwg+ xw1FmXLjELIvGEeShESdjQc= =Spv9 -----END PGP SIGNATURE----- --UTZ8bGhNySVQ9LYl-- --===============1770238668== 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 --===============1770238668==-- From tcpm-bounces@ietf.org Wed Nov 15 23:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkZ9Q-00049D-4D; Wed, 15 Nov 2006 23:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkZ9O-000497-PQ for tcpm@ietf.org; Wed, 15 Nov 2006 23:46:58 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkZ9N-0000lp-9D for tcpm@ietf.org; Wed, 15 Nov 2006 23:46: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 kAG4ke6q019821; Wed, 15 Nov 2006 20:46:41 -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 D0D154A24CC; Wed, 15 Nov 2006 23:47:05 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 02E984BEE49; Wed, 15 Nov 2006 23:44:52 -0500 (EST) To: Andre Oppermann From: Mark Allman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: <455B0F67.4000003@freebsd.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: People Are Strange MIME-Version: 1.0 Date: Wed, 15 Nov 2006 23:44:52 -0500 Message-Id: <20061116044452.02E984BEE49@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tcpm@ietf.org 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="===============1626267744==" Errors-To: tcpm-bounces@ietf.org --===============1626267744== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline I just took a spin through today's thread and am not going to do a point-by-point reply to everything. But, I have thought about these issues a little bit over the years and have a few comments (these are not all in response to Andre's proposal or comments, but to the thread in general): * If the goal is to do slow start more quickly by coaxing the receiver into sending more ACKs then you should compare this with ABC. If you go back and chase the references in the ABC document you will find an old CCR paper that I wrote that plays with something called "delayed ACKs after slow start" and compares that with byte counting (the paper uses simulations and the receiver knew when the sender was in slow start through this wonderful mechanism of a global variable---just a test of feasibility not of mechanism). Indeed, as noted in the thread, getting more ACKs during slow start does make things a bit smoother than the slightly more bursty byte counting approach. However, the conclusion is that this difference is fairly minor and so using the sender-only approach seems reasonable. Of course, if you have some evidence that shows different results and that the burstiness of something like ABC matters then that would be very useful to see (even if not for ACKNOW, but as a comment on whether ABC should be standards-tracked at some point). * Contrary to the claim in the thread, ABC is not over-aggressive and does in fact follow the spirit of congestion control. As noted, delayed ACKs are not strictly required and ABC is never more aggressive than an ACK counting sender would be in the face of a receiver that ACKs every packet. * The other big claim about ACKNOW seems to be that it aids loss recovery. But, I am not sure how. As Ethan noted, RFC 2581 says that receivers SHOULD ACK every segment when there is a gap in the sequence space (i.e., during loss recovery). To expound on this a little... The problem is that the receiver is in a great position to understand when to change to immediately ACK to aid loss recovery and the sender is in a lousy position to drive the process with ACKNOW. When the sender figures out that some segment X has been lost and so initiates loss recovery an entire window of data behind X has already been sent. And, it is precisely this window of data that will generate the duplicate ACKs (and SACKs) to drive loss recovery. So, by the time the sender understands there is loss the segments that would be best to use with ACKNOW are already in transit. However, the receiver knows there is something wrong as soon as the first duplicate ACK is sent and so can switch gears easily to immediate ACKing and have a real impact on the process. * The broader point here is that I think it is a mistake to think that the sender always knows best. We do not need one "best" vantage point, IMO. * ACKing every packet is legal. RFC 2581 says that stacks SHOULD ACK every other packet. I take this to mean that you ought to have a pretty good reason to do something different. So, while it is technically OK to ACK every segment I think it is a discouraged practice, in general. * It may be useful to increase the ACK interval beyond 2. There is some evidence that shows this to be useful to performance in some cases and there is a general notion that the reverse path could stand to be congestion controlled itself. There is also clearly evidence that extending the ACK interval makes things more brittle (e.g., easier to lose a window of ACKs and be stuck doing full restart). Maybe it is a good idea to make this dynamic. I don't know. But, I know that I'd want to see more than hand wavy claims about easy heuristics before I believe it. Further, I have a feeling that if one really wanted to do this it may well take exchanging more than one bit of information. Maybe not. I have no idea. Someone would need to wring this out. * TCP does not care about RTTs. TCP uses RTTs to figure out an *RTO*. That is, TCP just wants to know how long to wait before it should assume loss and retransmit. Clearly, that amount of time should include everything from the propagation delay to the queueing time to the amount of time the receiver twiddles its thumbs waiting to ACK a packet (and, everything in between). That said, delayed ACKs do not have a huge impact on the RTO of a steady-state TCP connection because delayed ACKs are basically not delayed all that long. That is, when sending bunches of packets the time an ACK is delayed is just until the next packet arrives. (And, half the packets are delayed not at all.) Let's not forget that delayed ACKs are usually clocked out by packets not timers. So, I am not sure that I buy Dave Borman's notion that ACKNOW somehow sets us up to measure fundamentally different RTTs that are then thrown into the estimator. My *guess* is this is in general a small effect. (Although, I am sure an example where there was a big effect isn't that hard to cook.) * It would be nice if the easy heuristics and algorithms were tried and the "tangible benefits" were shown. We've all heard (and made!) those sorts of hollow claims before. I don't want to say that this ACKNOW bit is a totally dumb idea. Maybe it isn't. But, from the mail thus far I don't think it sounds like it is really accomplishing much. But, I am game to be proven wrong with some evidence. The devil is in the details. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFFW+zDWyrrWs4yIs4RAk/iAKCPUG6ZXPcqjNEX6w7LDmo3fM6P4wCfQTl4 if8FWMGJLmv5PUbLT0iPoiQ= =N6Bc -----END PGP SIGNATURE----- --=_bOundary-- --===============1626267744== 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 --===============1626267744==-- From tcpm-bounces@ietf.org Thu Nov 16 05:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkekr-0006xp-IE; Thu, 16 Nov 2006 05:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkekp-0006v9-Rd for tcpm@ietf.org; Thu, 16 Nov 2006 05:45:59 -0500 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkedy-000435-IN for tcpm@ietf.org; Thu, 16 Nov 2006 05:38:57 -0500 Received: from [192.168.1.4] (sctp.fh-muenster.de [194.95.73.131]) by ilsa.franken.de (Postfix) with ESMTP id C5254245DF; Thu, 16 Nov 2006 11:38:46 +0100 (CET) (KNF account authenticated via SMTP-AUTH) In-Reply-To: <455B4472.3080402@isi.edu> References: <455B0F67.4000003@freebsd.org> <455B4472.3080402@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41A7E1AA-A68E-4A30-A9AC-F8FF1678E92E@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Date: Thu, 16 Nov 2006 09:35:41 +0100 To: Joe Touch X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Hi Joe, comment in-line. Best regards Michael On Nov 15, 2006, at 17:46 Uhr, Joe Touch wrote: > Hi, Andre, > > Andre Oppermann wrote: >> I propose to include an ACKNOW bit into the TCP header instructing >> the >> recipient to immediately, without any delay whatsoever, acknowledge >> the received segment. > > This sounds like a fairly substantial change to TCP semantics. TCP has > only two kinds of headers that require a direct reply - SYN and FIN. > > It seems like all other interactions are driven by only data packets, > and require the preceding data to have been correctly received to > generate a positive ACK. I.e., short of start/end of a connection, TCP > is more data driven than header driven. This would require a > substantial > change to that semantic, which seems like it would require a > substantial > revision. > > Forcing the other end to react is also a DOS opportunity. > > Can anyone speak to whether SCTP handles this better, since this > sounds > like a signalling issue? SCTP should SACK every other packet containing DATA chunks. However, if the receiver detects gaps/duplicates, he must SACK every packet containing DATA chunks. The sender can only derive from RTT measurements if the receiver delays SACK or not. In networks were small RTTs are necessary (also with reduced RTO.min/RTO.max) it might be better to disable delaying SACKs or to reduce the SACK delay time. However, there is currently no way for the sender to enforce that behaviour on the receiving side. It might be a nice thing because it would decouple the sender and receiver from the RTO.min > SACK.delay constraint. Keep in mind that SCTP has two different ways of measuring the RTT: - based on DATA/SACK which will include the SACK.delay - based on HEARTBEAT/HEARTBEAT-ACK which will not include the ASCK.delay. > >> Rationale: >> >> ...It is extremely difficult for the receiver to guess >> itself when to switch from delayed ACKs to immediate ACKs as it has >> only insufficient hints the current state the sender operates in. > > Can you clarify this? I thought delayed (compressed 2:1) ACKs were > required, period. It's only on the send side that delays are avoided, > e.g., depending on NAGLE. > >> ...As a second benefit a receiver on a ACKNOW flag enabled session >> may >> increase the delayed ACK from every other packet (as currently >> required) >> to a higher number, lets say every eighth. The exact value is to be >> determined based on the estimated delay*bandwidth product and the >> send/ >> receive socket buffer sizes. > > This would increase burstiness in the network, which would affect > traffic sharing paths through non-RED routers at least. Also, > unless ABC > is supported (3465), this would affect the fairness of TCP's ACK > clocking. > >> The use of the ACKNOW bit allows significant faster recovery times in >> the presence of difficult network conditions. > > I don't think this should be a goal of a TCP modification, UNLESS the > modification can be shown to do no harm in other, equally difficult > network conditions. > > Whether this mod passes that test is not yet clear. > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 17 09:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4TH-00031c-CH; Fri, 17 Nov 2006 09:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl4TF-00031X-S7 for tcpm@ietf.org; Fri, 17 Nov 2006 09:13:33 -0500 Received: from c00l3r.networx.ch ([62.48.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl4TD-0001Zc-0F for tcpm@ietf.org; Fri, 17 Nov 2006 09:13:33 -0500 Received: (qmail 48957 invoked from network); 17 Nov 2006 14:05:33 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Nov 2006 14:05:33 -0000 Message-ID: <455DC387.8000108@freebsd.org> Date: Fri, 17 Nov 2006 15:13:27 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <20061116044452.02E984BEE49@lawyers.icir.org> In-Reply-To: <20061116044452.02E984BEE49@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Mark Allman wrote: > I just took a spin through today's thread and am not going to do a > point-by-point reply to everything. But, I have thought about these > issues a little bit over the years and have a few comments (these are > not all in response to Andre's proposal or comments, but to the thread > in general): > > * If the goal is to do slow start more quickly by coaxing the receiver > into sending more ACKs then you should compare this with ABC. If > you go back and chase the references in the ABC document you will > find an old CCR paper that I wrote that plays with something called > "delayed ACKs after slow start" and compares that with byte counting > (the paper uses simulations and the receiver knew when the sender > was in slow start through this wonderful mechanism of a global > variable---just a test of feasibility not of mechanism). Indeed, as > noted in the thread, getting more ACKs during slow start does make > things a bit smoother than the slightly more bursty byte counting > approach. However, the conclusion is that this difference is fairly > minor and so using the sender-only approach seems reasonable. > > Of course, if you have some evidence that shows different results > and that the burstiness of something like ABC matters then that > would be very useful to see (even if not for ACKNOW, but as a > comment on whether ABC should be standards-tracked at some point). > > * Contrary to the claim in the thread, ABC is not over-aggressive and > does in fact follow the spirit of congestion control. As noted, > delayed ACKs are not strictly required and ABC is never more > aggressive than an ACK counting sender would be in the face of a > receiver that ACKs every packet. > > * The other big claim about ACKNOW seems to be that it aids loss > recovery. But, I am not sure how. As Ethan noted, RFC 2581 says > that receivers SHOULD ACK every segment when there is a gap in the > sequence space (i.e., during loss recovery). To expound on this a > little... The problem is that the receiver is in a great position to > understand when to change to immediately ACK to aid loss recovery > and the sender is in a lousy position to drive the process with > ACKNOW. When the sender figures out that some segment X has been > lost and so initiates loss recovery an entire window of data behind > X has already been sent. And, it is precisely this window of data > that will generate the duplicate ACKs (and SACKs) to drive loss > recovery. So, by the time the sender understands there is loss the > segments that would be best to use with ACKNOW are already in > transit. However, the receiver knows there is something wrong as > soon as the first duplicate ACK is sent and so can switch gears > easily to immediate ACKing and have a real impact on the process. > > * The broader point here is that I think it is a mistake to think that > the sender always knows best. We do not need one "best" vantage > point, IMO. > > * ACKing every packet is legal. RFC 2581 says that stacks SHOULD ACK > every other packet. I take this to mean that you ought to have a > pretty good reason to do something different. So, while it is > technically OK to ACK every segment I think it is a discouraged > practice, in general. > > * It may be useful to increase the ACK interval beyond 2. There is > some evidence that shows this to be useful to performance in some > cases and there is a general notion that the reverse path could > stand to be congestion controlled itself. There is also clearly > evidence that extending the ACK interval makes things more brittle > (e.g., easier to lose a window of ACKs and be stuck doing full > restart). Maybe it is a good idea to make this dynamic. I don't > know. But, I know that I'd want to see more than hand wavy claims > about easy heuristics before I believe it. Further, I have a > feeling that if one really wanted to do this it may well take > exchanging more than one bit of information. Maybe not. I have no > idea. Someone would need to wring this out. > > * TCP does not care about RTTs. TCP uses RTTs to figure out an > *RTO*. That is, TCP just wants to know how long to wait before > it should assume loss and retransmit. Clearly, that amount of time > should include everything from the propagation delay to the queueing > time to the amount of time the receiver twiddles its thumbs waiting > to ACK a packet (and, everything in between). > > That said, delayed ACKs do not have a huge impact on the RTO of a > steady-state TCP connection because delayed ACKs are basically not > delayed all that long. That is, when sending bunches of packets the > time an ACK is delayed is just until the next packet arrives. (And, > half the packets are delayed not at all.) Let's not forget that > delayed ACKs are usually clocked out by packets not timers. > > So, I am not sure that I buy Dave Borman's notion that ACKNOW > somehow sets us up to measure fundamentally different RTTs that are > then thrown into the estimator. My *guess* is this is in general a > small effect. (Although, I am sure an example where there was a big > effect isn't that hard to cook.) > > * It would be nice if the easy heuristics and algorithms were tried > and the "tangible benefits" were shown. We've all heard (and made!) > those sorts of hollow claims before. > > I don't want to say that this ACKNOW bit is a totally dumb idea. Maybe > it isn't. But, from the mail thus far I don't think it sounds like it > is really accomplishing much. But, I am game to be proven wrong with > some evidence. The devil is in the details. I will produce conclusive evidence (or counter evidence) and report back here in the next weeks. ;-) -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 17 13:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8Ey-0004hT-4g; Fri, 17 Nov 2006 13:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8Ex-0004hO-3u for tcpm@ietf.org; Fri, 17 Nov 2006 13:15:03 -0500 Received: from nlpi015.sbcis.sbc.com ([207.115.36.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8EX-0005Mh-Cc for tcpm@ietf.org; Fri, 17 Nov 2006 13:15:03 -0500 X-ORBL: [75.24.209.12] Received: from ace (adsl-75-24-209-12.dsl.pltn13.sbcglobal.net [75.24.209.12]) by nlpi015.sbcis.sbc.com (8.13.8 out.dk.spool/8.13.8) with ESMTP id kAHIDsX5011589; Fri, 17 Nov 2006 12:13:55 -0600 Message-Id: <200611171813.kAHIDsX5011589@nlpi015.sbcis.sbc.com> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Jeffrey Hsu" To: mallman@icir.org Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: Message from Mark Allman of "Wed, 15 Nov 2006 23:44:52 EST." <20061116044452.02E984BEE49@lawyers.icir.org> Date: Fri, 17 Nov 2006 10:13:44 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 For those of you who want to experiment on a production system with ABC, DragonFlyBSD, an advanced production-quality version of FreeBSD, has ABC implemented. You can turn it on or off with the net.inet.tcp.abc sysctl variable. SACK, SCTP, Limited Transmit, Eifel Detection, Early Retransmit, and many other options are also available and tunable with run-time sysctl settings. Jeffrey _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 20 16:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGYT-0001g5-Lg; Mon, 20 Nov 2006 16:19:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGYS-0001fr-LV for tcpm@ietf.org; Mon, 20 Nov 2006 16:19:52 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmGYP-0004YT-9w for tcpm@ietf.org; Mon, 20 Nov 2006 16:19:52 -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 kAKLIr3e023989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Nov 2006 13:18:53 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kAKLIrTb002612; Mon, 20 Nov 2006 13:18:53 -0800 (PST) (envelope-from faber) Date: Mon, 20 Nov 2006 13:18:53 -0800 From: Ted Faber To: Andre Oppermann Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Message-ID: <20061120211852.GB1185@hut.isi.edu> References: <20061116044452.02E984BEE49@lawyers.icir.org> <455DC387.8000108@freebsd.org> Mime-Version: 1.0 In-Reply-To: <455DC387.8000108@freebsd.org> 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163255551==" Errors-To: tcpm-bounces@ietf.org --===============0163255551== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 17, 2006 at 03:13:27PM +0100, Andre Oppermann wrote: > Mark Allman wrote: [many things] >=20 > I will produce conclusive evidence (or counter evidence) and report > back here in the next weeks. ;-) If you continue to believe ACKNOW is worth talking about, an internet draft that lays out the case and describes the details would be a great starting point. Let me know, on- or off-list, if there's something I can to to make that easier for you. --=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 --8GpibOaaTibBMecb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFYhu8aUz3f+Zf+XsRAtiZAKC73sJU64YQ7GUnOAYdZ1o3RMuJ0QCfdMLh MjB90HS4U2ZzwDwiOYXF4tA= =VuQB -----END PGP SIGNATURE----- --8GpibOaaTibBMecb-- --===============0163255551== 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 --===============0163255551==-- From tcpm-bounces@ietf.org Tue Nov 21 02:50:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQO6-0005GU-Gl; Tue, 21 Nov 2006 02:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmQO5-0005Ed-Ev for tcpm@ietf.org; Tue, 21 Nov 2006 02:49:49 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmQO4-0004aY-L5 for tcpm@ietf.org; Tue, 21 Nov 2006 02:49:49 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kAL7nE2n011470; Tue, 21 Nov 2006 09:49:15 +0200 Date: Tue, 21 Nov 2006 09:49:14 +0200 (EET) From: Pekka Savola To: Jeffrey Hsu Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: <200611171813.kAHIDsX5011589@nlpi015.sbcis.sbc.com> Message-ID: References: <200611171813.kAHIDsX5011589@nlpi015.sbcis.sbc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2209/Tue Nov 21 00:40:59 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Fri, 17 Nov 2006, Jeffrey Hsu wrote: > For those of you who want to experiment on a production system with ABC, > DragonFlyBSD, an advanced production-quality version of FreeBSD, > has ABC implemented. 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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 21 06:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmU7p-0002pe-PE; Tue, 21 Nov 2006 06:49:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmU7o-0002pV-On for tcpm@ietf.org; Tue, 21 Nov 2006 06:49:16 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmU7m-0008VS-9y for tcpm@ietf.org; Tue, 21 Nov 2006 06:49:16 -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 kALBnCS7004211; Tue, 21 Nov 2006 03:49:12 -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 CAC484D0159; Tue, 21 Nov 2006 06:49:29 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 019624C29A7; Tue, 21 Nov 2006 06:47:24 -0500 (EST) To: Pekka Savola From: Mark Allman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Tue, 21 Nov 2006 06:47:24 -0500 Message-Id: <20061121114724.019624C29A7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Jeffrey Hsu , tcpm@ietf.org 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="===============0026476016==" Errors-To: tcpm-bounces@ietf.org --===============0026476016== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > On Fri, 17 Nov 2006, Jeffrey Hsu wrote: > > For those of you who want to experiment on a production system with ABC, > > DragonFlyBSD, an advanced production-quality version of FreeBSD, > > has ABC implemented. > > 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. Can you say more about this last part? I assume by "earlier behavior" you mean slower cwnd growth? Or, strictly ACK counting? Or, what? I guess I don't quite follow why applications are somehow caring about this or expecting some behavior from TCP in this regard at all. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFFYudMWyrrWs4yIs4RAl9gAJ9+f9S9jsv4cYK9cCiwxrgOKzki6wCeJXdG XChT5kxArH5/dhHyohHhwp8= =6DIe -----END PGP SIGNATURE----- --=_bOundary-- --===============0026476016== 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 --===============0026476016==-- From tcpm-bounces@ietf.org Tue Nov 21 07:38:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmUt4-00026N-7n; Tue, 21 Nov 2006 07:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmUt2-00021F-RK for tcpm@ietf.org; Tue, 21 Nov 2006 07:38:04 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmUsz-00005k-BI for tcpm@ietf.org; Tue, 21 Nov 2006 07:38:04 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kALCbqF4017865; Tue, 21 Nov 2006 14:37:52 +0200 Date: Tue, 21 Nov 2006 14:37:52 +0200 (EET) From: Pekka Savola To: Mark Allman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: <20061121114724.019624C29A7@lawyers.icir.org> Message-ID: References: <20061121114724.019624C29A7@lawyers.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2209/Tue Nov 21 00:40:59 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_05, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Jeffrey Hsu , 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 Tue, 21 Nov 2006, Mark Allman wrote: > > On Fri, 17 Nov 2006, Jeffrey Hsu wrote: > > > For those of you who want to experiment on a production system with ABC, > > > DragonFlyBSD, an advanced production-quality version of FreeBSD, > > > has ABC implemented. > > > > 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. > > Can you say more about this last part? I assume by "earlier behavior" > you mean slower cwnd growth? Or, strictly ACK counting? Or, what? I > guess I don't quite follow why applications are somehow caring about > this or expecting some behavior from TCP in this regard at all. Unfortunately, of late I don't think developers have been very interested in participating in the IETF, so it's difficult to know for sure. These messages might shed some light to the subject. Turning it off: http://www.mail-archive.com/netdev@vger.kernel.org/msg21294.html Why it's not applicable: http://www.mail-archive.com/netdev@vger.kernel.org/msg21257.html Some further info: http://www.mail-archive.com/netdev@vger.kernel.org/msg21204.html http://www.mail-archive.com/netdev@vger.kernel.org/msg21220.html http://www.mail-archive.com/netdev@vger.kernel.org/msg21256.html The start of the thread, and the second thread: http://marc.theaimsgroup.com/?t=115693258400001&r=1&w=2 http://marc.theaimsgroup.com/?t=115738569600001&r=1&w=2 HTH.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 21 07:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmV6Q-00029G-69; Tue, 21 Nov 2006 07:51:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmV6O-000297-NY for tcpm@ietf.org; Tue, 21 Nov 2006 07:51:52 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmV6L-0003GE-Bp for tcpm@ietf.org; Tue, 21 Nov 2006 07:51:52 -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 kALCplmo008513; Tue, 21 Nov 2006 04:51:48 -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 88C4E4D0517; Tue, 21 Nov 2006 07:52:05 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2D3524C2B8E; Tue, 21 Nov 2006 07:50:00 -0500 (EST) To: Pekka Savola From: Mark Allman Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Tue, 21 Nov 2006 07:49:59 -0500 Message-Id: <20061121125000.2D3524C2B8E@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Jeffrey Hsu , tcpm@ietf.org 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="===============1869703804==" Errors-To: tcpm-bounces@ietf.org --===============1869703804== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Unfortunately, of late I don't think developers have been very > interested in participating in the IETF, so it's difficult to know for > sure. Yes. This is unfortunate for a number of reasons. > These messages might shed some light to the subject. I read them. I guess I am still not sure what the concern is. However, I will readily admit that I didn't read the entire threads and sometimes getting the big picture points from the middle of a thread is tough. I guess if we ever want to push ABC onto the standards track there ought to be an action item to chat with these folks. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFFYvX3WyrrWs4yIs4RAuLeAJ9YnWmeCzZ9Bk8xnj9qk5/dE74zTwCfRBHo 0vB3KO45PKQiBcS7dwFz+8U= =Tjgm -----END PGP SIGNATURE----- --=_bOundary-- --===============1869703804== 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 --===============1869703804==-- From tcpm-bounces@ietf.org Tue Nov 21 08:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVUw-00064v-EQ; Tue, 21 Nov 2006 08:17:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmVUu-0005zw-9J for tcpm@ietf.org; Tue, 21 Nov 2006 08:17:12 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmVRt-0000cW-I3 for tcpm@ietf.org; Tue, 21 Nov 2006 08:14:06 -0500 Received: from net-32.nrpn.net (net-32.nrpn.net [192.89.6.32]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 575FF13CF86; Tue, 21 Nov 2006 14:17:23 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by net-32.nrpn.net (Postfix) with ESMTP id EBD4E2986B4; Tue, 21 Nov 2006 15:14:05 +0200 (EET) In-Reply-To: References: <20061121114724.019624C29A7@lawyers.icir.org> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <397D4657-D64E-4ED1-B7BD-F230340DB0B7@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Date: Tue, 21 Nov 2006 15:14:03 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1372879338==" Errors-To: tcpm-bounces@ietf.org --===============1372879338== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-128--1023433135; protocol="application/pkcs7-signature" --Apple-Mail-128--1023433135 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 21, 2006, at 14:37, Pekka Savola wrote: > Unfortunately, of late I don't think developers have been very > interested in participating in the IETF, so it's difficult to know for > sure. For Linux kernel developers, which is a community I'm not tuned into, can you venture a guess as to why this is (lack of travel funds, disinterest with the IETF, etc.)? I agree with Mark that it would be very useful to have stack developers be involved in the process. We had been thinking of ways in which we can encourage such participation. Lars --Apple-Mail-128--1023433135 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTIx MTMxNDA0WjAjBgkqhkiG9w0BCQQxFgQUPJCPQJLNXIMcSv9B4Nq8YkAlZMMwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBABoQF1eCgePOyzynfLDW SearE36OwkVHHVU/nBWSo1v5gAyDQNGdVBW9VXRotlojl10oairgk97o8oMtvnlhrzXJ2SHg/x7o ksugjQpPoAjYMeR65oF8q+gQb81UbY0lDuMyytVBf2Fj39uPDy9Zh/7Is9MIqw6v+5IZcljV3c+3 kmObW2OyZyJFNBJO2cD351uUOfFPDfrj7T4C95x9MFx8uE4vn3/TT5t3SaMtHpW3ghQi5e0WFMX8 +iC2AaVR9LB/vsiR2ENwYYW88sagOVSIOa2qu+5tURrrsC/WcJf0zupq3DniRU2NMVlwzndCZcdK Tn+cmvCT5GBZoQEyrWkAAAAAAAA= --Apple-Mail-128--1023433135-- --===============1372879338== 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 --===============1372879338==-- From tcpm-bounces@ietf.org Tue Nov 21 09:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmX2c-0005jc-1U; Tue, 21 Nov 2006 09:56:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmX2a-0005hv-FL for tcpm@ietf.org; Tue, 21 Nov 2006 09:56:04 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmX2W-0002LC-V7 for tcpm@ietf.org; Tue, 21 Nov 2006 09:56:04 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALEo4Cl025722; Tue, 21 Nov 2006 16:52:44 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 16:51:56 +0200 Received: from siddha.research.nokia.com ([172.21.50.145]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Nov 2006 16:51:55 +0200 Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header From: Pasi Sarolahti To: mallman@icir.org In-Reply-To: <20061121114724.019624C29A7@lawyers.icir.org> References: <20061121114724.019624C29A7@lawyers.icir.org> Organization: Nokia Research Center Date: Tue, 21 Nov 2006 16:51:56 +0200 Message-Id: <1164120716.738.26.camel@siddha.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) X-OriginalArrivalTime: 21 Nov 2006 14:51:55.0049 (UTC) FILETIME=[9634B190:01C70D7C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Jeffrey Hsu , 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="===============0069935673==" Errors-To: tcpm-bounces@ietf.org --===============0069935673== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iN5ymJ+ocbxqlTZ6++f1" --=-iN5ymJ+ocbxqlTZ6++f1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2006-11-21 at 06:47 -0500, ext Mark Allman 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. >=20 > Can you say more about this last part? I assume by "earlier behavior" > you mean slower cwnd growth? Or, strictly ACK counting? Or, what? I > guess I don't quite follow why applications are somehow caring about > this or expecting some behavior from TCP in this regard at all. Linux implements the congestion control based on packet counts, not based on byte counts. So after sending four 1-byte packets Linux sender has used up the initial congestion window (assuming iwnd =3D 4 *packets*). I haven't checked out the code for a long while, but just as a guess, maybe this has caused some confusion with Linux ABC implementation. - Pasi --=-iN5ymJ+ocbxqlTZ6++f1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFYxKMoNa7NH1G2csRAkVyAKDo7X4DA8XdC4H1gYIMa5R7+GRn6wCfdCTP Js3BHvNcV2O6J3UfKgXg1Sg= =ilJw -----END PGP SIGNATURE----- --=-iN5ymJ+ocbxqlTZ6++f1-- --===============0069935673== 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 --===============0069935673==-- From tcpm-bounces@ietf.org Tue Nov 21 10:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXks-0006zS-MH; Tue, 21 Nov 2006 10:41:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXkq-0006z9-IF for tcpm@ietf.org; Tue, 21 Nov 2006 10:41:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXko-0007sf-7m for tcpm@ietf.org; Tue, 21 Nov 2006 10:41:48 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2006 16:41:43 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kALFfgAf028610; Tue, 21 Nov 2006 16:41:42 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kALFfewv008985; Tue, 21 Nov 2006 16:41:42 +0100 (MET) Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4577.cisco.com [10.61.81.224]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA21521; Tue, 21 Nov 2006 15:41:35 GMT Message-Id: <200611211541.PAA21521@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Nov 2006 15:41:04 +0000 To: Pekka Savola From: Lloyd Wood Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header In-Reply-To: References: <200611171813.kAHIDsX5011589@nlpi015.sbcis.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Tuesday 21/11/2006 09:49 +0200, you wrote: >On Fri, 17 Nov 2006, Jeffrey Hsu wrote: >> For those of you who want to experiment on a production system with ABC, >> DragonFlyBSD, an advanced production-quality version of FreeBSD, >> has ABC implemented. > >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 L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 21 11:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYD1-0003Nl-KW; Tue, 21 Nov 2006 11:10:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYD0-0003NV-EV for tcpm@ietf.org; Tue, 21 Nov 2006 11:10:54 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYCx-0004U5-5w for tcpm@ietf.org; Tue, 21 Nov 2006 11:10:54 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id kALGAjS0018535; Tue, 21 Nov 2006 11:10:45 -0500 (EST) Message-ID: <45632504.40308@psc.edu> Date: Tue, 21 Nov 2006 11:10:44 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <20061121125000.2D3524C2B8E@lawyers.icir.org> In-Reply-To: <20061121125000.2D3524C2B8E@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Jeffrey Hsu , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: >> Unfortunately, of late I don't think developers have been very >> interested in participating in the IETF, so it's difficult to know for >> sure. > > Yes. This is unfortunate for a number of reasons. > >> These messages might shed some light to the subject. > > I read them. I guess I am still not sure what the concern is. However, > I will readily admit that I didn't read the entire threads and sometimes > getting the big picture points from the middle of a thread is tough. I > guess if we ever want to push ABC onto the standards track there ought > to be an action item to chat with these folks. The crux of the issue is that linux tracks cwnd in packets rather than bytes. The failure mode occurs when you have some very latency-sensitve application does small writes with Nagle disabled (there are a number of these out there, and though I'm not sure exactly what they are, people scream loudly when they break). The initial window allows a few segments, so you send out a few segments. These get delayed-acked, and bytes_acked gets increased. However, cwnd does not increase, because you can't until bytes_acked equals cwnd*mss. So there is a de-amplification effect on the cwnd increase rate of (average segsize)/MSS. The small segments get coalesced into larger segments while cwnd is blocking them, creating a long latency in a latency-sensitive application, defeating the whole purpose of disabling Nagle to begin with. This is not an issue with the ABC spec, as it's defined in terms of cwnd tracking in bytes. It's an unfortunate interaction between the two models. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 21 11:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYEG-0003XC-WE; Tue, 21 Nov 2006 11:12:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYEF-0003X4-PT for tcpm@ietf.org; Tue, 21 Nov 2006 11:12:11 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYED-0004ju-DT for tcpm@ietf.org; Tue, 21 Nov 2006 11:12:11 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) by mailer2.psc.edu (8.13.8/8.13.3) with ESMTP id kALGC6Fu011549; Tue, 21 Nov 2006 11:12:07 -0500 (EST) Message-ID: <45632555.5060401@psc.edu> Date: Tue, 21 Nov 2006 11:12:05 -0500 From: John Heffner User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header References: <20061121114724.019624C29A7@lawyers.icir.org> <397D4657-D64E-4ED1-B7BD-F230340DB0B7@netlab.nec.de> In-Reply-To: <397D4657-D64E-4ED1-B7BD-F230340DB0B7@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Lars Eggert wrote: > On Nov 21, 2006, at 14:37, Pekka Savola wrote: >> Unfortunately, of late I don't think developers have been very >> interested in participating in the IETF, so it's difficult to know for >> sure. > > For Linux kernel developers, which is a community I'm not tuned into, > can you venture a guess as to why this is (lack of travel funds, > disinterest with the IETF, etc.)? > > I agree with Mark that it would be very useful to have stack developers > be involved in the process. We had been thinking of ways in which we can > encourage such participation. I believe lack of funds is a big issue for some. I would also guess that of the small number of "core" developers, most are extremely busy actually working on the kernel, and just can't afford or justify the large amount of time that active IETF participation requires. There are a few of us out there actively working in both areas. ;) -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 21 14:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbPU-0005s9-3e; Tue, 21 Nov 2006 14:36:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbPT-0005s4-IX for tcpm@ietf.org; Tue, 21 Nov 2006 14:35:59 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmbPS-0006wz-7U for tcpm@ietf.org; Tue, 21 Nov 2006 14:35:59 -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 kALJZvvU031716; Tue, 21 Nov 2006 11:35:57 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 91BD54D2954; Tue, 21 Nov 2006 14:36:14 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 269374C30F7; Tue, 21 Nov 2006 14:34:09 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Peaches MIME-Version: 1.0 Date: Tue, 21 Nov 2006 14:34:09 -0500 Message-Id: <20061121193409.269374C30F7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Ted Faber Subject: [tcpm] tcp-auth hum verification 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="===============1195002455==" Errors-To: tcpm-bounces@ietf.org --===============1195002455== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline In the TCPM meeting in San Diego, there was a hum in favor of the working group taking on the general task of developing a new TCP authentication option. This does not include key rollover (but, does include hooks to make that possible). Further, this hum was not to adopt either of the specific proposals that have been written thus far. (The general process we intend to follow--as mentioned in the meeting is to convene a small design team to meld and merge and re-write and whatever the specs on the table to produce a -00 of a WG draft on the subject. After the -00 the WG will take over development.) This message is to verify the hum taken in the room. If you feel that the general area of adding authentication to TCP is *not* a useful task for this WG, please argue this point on the list. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFFY1SwWyrrWs4yIs4RAmJcAJ40CqSrKKi/N/8mqlk5GC4l7csgmACgnnyr oWvFg+pXwSNJqYiz8RFvL+8= =YCzv -----END PGP SIGNATURE----- --=_bOundary-- --===============1195002455== 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 --===============1195002455==-- From tcpm-bounces@ietf.org Wed Nov 22 10:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtZU-00059r-4v; Wed, 22 Nov 2006 09:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmtZS-00059O-FD for tcpm@ietf.org; Wed, 22 Nov 2006 09:59:30 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmtZS-0003CW-0H for tcpm@ietf.org; Wed, 22 Nov 2006 09:59:30 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kAMExJLN024917; Wed, 22 Nov 2006 16:59:20 +0200 Date: Wed, 22 Nov 2006 16:59:19 +0200 (EET) From: Pekka Savola To: Lars Eggert In-Reply-To: <397D4657-D64E-4ED1-B7BD-F230340DB0B7@netlab.nec.de> Message-ID: References: <20061121114724.019624C29A7@lawyers.icir.org> <397D4657-D64E-4ED1-B7BD-F230340DB0B7@netlab.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.6/2214/Tue Nov 21 22:39:05 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Jeffrey Hsu , tcpm@ietf.org, Mark Allman Subject: [tcpm] encouraging wider participation 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 changed the subject line.. On Tue, 21 Nov 2006, Lars Eggert wrote: > On Nov 21, 2006, at 14:37, Pekka Savola wrote: >> Unfortunately, of late I don't think developers have been very >> interested in participating in the IETF, so it's difficult to know for >> sure. > > For Linux kernel developers, which is a community I'm not tuned into, can you > venture a guess as to why this is (lack of travel funds, disinterest with the > IETF, etc.)? The issue is not TCP(m)-specific, but may be magnified as TCP has been around for a long time and is a protocol many hold very strong views about, so any maintenance easily ratholes in a layer higher than L7. ... I suspect bad ROI -- the IETF process takes so long time and eats up so much energy that most rather spend it spend on the implementation work. Further, currently the IETF is mostly useful as a body for new specifications. The IETF hasn't paid much attention to protocol maintenance, so if you look at old protocols such as TCP, UDP or ICMP, the IETF has long since ceased being relevant as a forum for up-to-date behavioural descriptons. If a developer needs to make a modification, they'll just do it -- no need to try to waste time with the IETF. Fixing this would likely require finding ways to encourage low-overhead participation and evaluating how much running code has diverged from the implementations and trying to close that gap. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 22 13:40:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmx0U-0005Oq-Ee; Wed, 22 Nov 2006 13:39:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmx0T-0005Ol-SR for tcpm@ietf.org; Wed, 22 Nov 2006 13:39:37 -0500 Received: from smtp.osdl.org ([65.172.181.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmx0P-0002EX-E0 for tcpm@ietf.org; Wed, 22 Nov 2006 13:39:37 -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 kAMIdNix010806 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Nov 2006 10:39:24 -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 kAMIdMb2011540; Wed, 22 Nov 2006 10:39:22 -0800 Date: Wed, 22 Nov 2006 10:39:22 -0800 From: Stephen Hemminger To: Pekka Savola Subject: Re: [tcpm] encouraging wider participation Message-ID: <20061122103922.6aefdda1@freekitty> In-Reply-To: References: <20061121114724.019624C29A7@lawyers.icir.org> <397D4657-D64E-4ED1-B7BD-F230340DB0B7@netlab.nec.de> 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.681 required=5 tests=AWL, OSDL_HEADER_SUBJECT_BRACKETED, OSDL_NIGERIAN_FUNDS X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.105__ X-MIMEDefang-Filter: osdl$Revision: 1.159 $ X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Lars Eggert , Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Wed, 22 Nov 2006 16:59:19 +0200 (EET) Pekka Savola wrote: > I changed the subject line.. > > On Tue, 21 Nov 2006, Lars Eggert wrote: > > On Nov 21, 2006, at 14:37, Pekka Savola wrote: > >> Unfortunately, of late I don't think developers have been very > >> interested in participating in the IETF, so it's difficult to know for > >> sure. > > > > For Linux kernel developers, which is a community I'm not tuned into, can you > > venture a guess as to why this is (lack of travel funds, disinterest with the > > IETF, etc.)? > > The issue is not TCP(m)-specific, but may be magnified as TCP has been > around for a long time and is a protocol many hold very strong views > about, so any maintenance easily ratholes in a layer higher than L7. To help you understand. Linux development is not centralized, there are many community members. Several of the network developers, watch this list (and the e2e list). Any discussion with direct impact on Linux gets evaluated. The Linux community works mostly through email with occasional face to face meetings. The meetings are informal and dedicated to discussing issues that are not getting enough traction. There has been an annual meeting of the Linux network developers (http://vger.kernel.org/netconf2006.html) as well as discussions at the kernel summit (http://www.usenix.org/events/kernel06/). > I suspect bad ROI -- the IETF process takes so long time and eats up > so much energy that most rather spend it spend on the implementation > work. If you look at who contributes to Linux networking; there are contributions from distributions (Redhat, Novell, Ubuntu), non-profits (OSDL), and research (NCSU, Hamilton, etc). Each contributor has there own needs and spending time on IETF issues is not a priority for most. For many, getting funding and time to go to IETF meetings has been impractical. If there are issues and agenda items that warrant discussion with IETF, I am sure we can get several people to go to one of the meetings. > Further, currently the IETF is mostly useful as a body for new > specifications. The IETF hasn't paid much attention to protocol > maintenance, so if you look at old protocols such as TCP, UDP or ICMP, > the IETF has long since ceased being relevant as a forum for > up-to-date behavioural descriptons. If a developer needs to make a > modification, they'll just do it -- no need to try to waste time with > the IETF. Any practical commercial implementation is a hybrid of specifications from standards organizations, and heuristics based on real world feedback and device quirks. > Fixing this would likely require finding ways to encourage > low-overhead participation and evaluating how much running code has > diverged from the implementations and trying to close that gap. There is also, the possibility of more focused groups (security?), or getting cross vendor participation. Several vendors use Linux in their products and participate on both IETF and Linux lists. -- Stephen Hemminger _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 22 13:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxIJ-0000q7-Qj; Wed, 22 Nov 2006 13:58:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxII-0000q0-2C for tcpm@ietf.org; Wed, 22 Nov 2006 13:58:02 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmxIE-0004WB-51 for tcpm@ietf.org; Wed, 22 Nov 2006 13:58:01 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id kAMIvXJl021583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Nov 2006 10:57:34 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kAMIvXKh014397; Wed, 22 Nov 2006 10:57:33 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kAMIvSIN014120; Wed, 22 Nov 2006 10:57:32 -0800 (PST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 10:57:27 -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: Wed, 22 Nov 2006 10:56:42 -0800 Message-ID: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <20061122103922.6aefdda1@freekitty> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] encouraging wider participation Thread-Index: AccOZbPcMkCicgfBRhm0fRtwaf0ESwAAhkCQ From: "Duke, Martin" To: "Stephen Hemminger" , "Pekka Savola" X-OriginalArrivalTime: 22 Nov 2006 18:57:27.0798 (UTC) FILETIME=[0E058960:01C70E68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Lars Eggert , Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org 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? Martin > -----Original Message----- > From: Stephen Hemminger [mailto:shemminger@osdl.org]=20 > Sent: Wednesday, November 22, 2006 10:39 AM > To: Pekka Savola > Cc: Lars Eggert; Jeffrey Hsu; tcpm@ietf.org; Mark Allman > Subject: Re: [tcpm] encouraging wider participation >=20 > On Wed, 22 Nov 2006 16:59:19 +0200 (EET) Pekka Savola=20 > wrote: >=20 > > I changed the subject line.. > >=20 > > On Tue, 21 Nov 2006, Lars Eggert wrote: > > > On Nov 21, 2006, at 14:37, Pekka Savola wrote: > > >> Unfortunately, of late I don't think developers have been very=20 > > >> interested in participating in the IETF, so it's=20 > difficult to know=20 > > >> for sure. > > > > > > For Linux kernel developers, which is a community I'm not tuned=20 > > > into, can you venture a guess as to why this is (lack of travel=20 > > > funds, disinterest with the IETF, etc.)? > >=20 > > The issue is not TCP(m)-specific, but may be magnified as=20 > TCP has been=20 > > around for a long time and is a protocol many hold very=20 > strong views=20 > > about, so any maintenance easily ratholes in a layer higher than L7. >=20 > To help you understand. Linux development is not centralized,=20 > there are many community members. Several of the network=20 > developers, watch this list (and the e2e list). > Any discussion with direct impact on Linux gets evaluated. >=20 >=20 > The Linux community works mostly through email with=20 > occasional face to face meetings. The meetings are informal=20 > and dedicated to discussing issues that are not getting=20 > enough traction. There has been an annual meeting of the=20 > Linux network developers (http://vger.kernel.org/netconf2006.html) > as well as discussions at the kernel summit=20 > (http://www.usenix.org/events/kernel06/). > =20 > > I suspect bad ROI -- the IETF process takes so long time=20 > and eats up=20 > > so much energy that most rather spend it spend on the=20 > implementation=20 > > work. >=20 > If you look at who contributes to Linux networking; there are=20 > contributions from distributions (Redhat, Novell, Ubuntu),=20 > non-profits (OSDL), and research (NCSU, Hamilton, etc). Each=20 > contributor has there own needs and spending time on IETF=20 > issues is not a priority for most. > For many, getting funding and time to go to IETF meetings has=20 > been impractical. If there are issues and agenda items that=20 > warrant discussion with IETF, I am sure we can get several=20 > people to go to one of the meetings. >=20 > > Further, currently the IETF is mostly useful as a body for new=20 > > specifications. The IETF hasn't paid much attention to protocol=20 > > maintenance, so if you look at old protocols such as TCP,=20 > UDP or ICMP,=20 > > the IETF has long since ceased being relevant as a forum for=20 > > up-to-date behavioural descriptons. If a developer needs to make a=20 > > modification, they'll just do it -- no need to try to waste=20 > time with=20 > > the IETF. >=20 > Any practical commercial implementation is a hybrid of=20 > specifications from standards organizations, and heuristics=20 > based on real world feedback and device quirks. >=20 > =20 > > Fixing this would likely require finding ways to encourage=20 > > low-overhead participation and evaluating how much running code has=20 > > diverged from the implementations and trying to close that gap. >=20 > There is also, the possibility of more focused groups=20 > (security?), or getting cross vendor participation. Several=20 > vendors use Linux in their products and participate on both=20 > IETF and Linux lists. >=20 >=20 > -- > Stephen Hemminger >=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 Wed Nov 22 13:59:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxK1-0001GP-5W; Wed, 22 Nov 2006 13:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmxK0-0001GJ-FP for tcpm@ietf.org; Wed, 22 Nov 2006 13:59:48 -0500 Received: from smtp.osdl.org ([65.172.181.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmxJz-0004eO-2s for tcpm@ietf.org; Wed, 22 Nov 2006 13:59:48 -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 kAMIxiix012168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Nov 2006 10:59:45 -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 kAMIxhCO012124; Wed, 22 Nov 2006 10:59:44 -0800 Date: Wed, 22 Nov 2006 10:59:43 -0800 From: Stephen Hemminger To: Lloyd Wood Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header Message-ID: <20061122105943.36321c03@freekitty> In-Reply-To: <200611211541.PAA21521@cisco.com> References: <200611171813.kAHIDsX5011589@nlpi015.sbcis.sbc.com> <200611211541.PAA21521@cisco.com> 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.73 required=5 tests=AWL, OSDL_HEADER_SUBJECT_BRACKETED X-Spam-Checker-Version: SpamAssassin 2.63-osdl_revision__1.105__ X-MIMEDefang-Filter: osdl$Revision: 1.159 $ X-Scanned-By: MIMEDefang 2.36 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Tue, 21 Nov 2006 15:41:04 +0000 Lloyd Wood wrote: > At Tuesday 21/11/2006 09:49 +0200, you wrote: > >On Fri, 17 Nov 2006, Jeffrey Hsu wrote: > >> For those of you who want to experiment on a production system with ABC, > >> DragonFlyBSD, an advanced production-quality version of FreeBSD, > >> has ABC implemented. > > > >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 > The first report was from users of the debugger in Eclipse, Java was doing several write's before reading the response. With ABC, the debugger crawled (even on local host). Sun did fix the debugger quickly once it was identified. The later reports were from users who had little or no control over the application. Application writers it seems are not network aware and have little understanding of underlying stream properties. That was when by consensus, Linux turned off ABC in 2.6.18; it is still available, just defaults to off. As has already been mentioned, Linux counts packets not bytes, so the interaction maybe related to that. Linux implements RFC2861 so it does not increase the congestion window unless the application is limited by the congestion window. This makes Linux mostly immune to the ack-splitting attacks that motivated ABC in the first place. There have been lots of annoying complexities introduced by the addition of TSO to the mix, but these are resolved in more recent kernels. -- Stephen Hemminger _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 24 17:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnk0L-000774-Au; Fri, 24 Nov 2006 17:58:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnk0J-00072U-7Y for tcpm@ietf.org; Fri, 24 Nov 2006 17:58:43 -0500 Received: from smtpout.mac.com ([17.250.248.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnjyJ-0006Wn-49 for tcpm@ietf.org; Fri, 24 Nov 2006 17:56:52 -0500 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id kAOMufl4001063 for ; Fri, 24 Nov 2006 14:56:45 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-249-89.dsl.snfc21.sbcglobal.net [70.231.249.89]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id kAOMuVZ8018060 for ; Fri, 24 Nov 2006 14:56:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tcpm From: Sally Floyd Date: Fri, 24 Nov 2006 14:56:31 -0800 X-Mailer: Apple Mail (2.624) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [tcpm] acknowlegement congestion control for TCP? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org One of the many things on my todo list is to write an internet-draft specifying an optional mechanism for acknowledgment congestion control, based on the acknowlegment congestion control in CCID 2 ("http://www.ietf.org/rfc/rfc4341.txt"). But, given the size of my todo list and my existing set of nine internet-drafts to handle, I am not likely to complete this on my own any time soon. So this is just an inquiry to see if anyone out there is interested in contributing to some work on the possibility of ack congestion control for TCP. The current very rough draft, just to give an idea: "http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-00a.txt". - Sally http://www.icir.org/floyd/ ------------------------------------------------------------------------ -------------------------------------------------- And the rest of my internet-draft todo list, in case anyone is interested, from "http://www.icir.org/floyd/papers.html": Internet-drafts on the TODO list: - TMRG: Best Current Practice Scenarios for Evaluating Congestion Control Mechanisms. - TMRG: On the Importance of Medium-Sized Flows. - TSVWG: Quick-Start for SCTP. Draft (txt, ps). - TSVWG: Quick-Start for DCCP. - TSVWG: Quick-Start support for IKEv2. - TSVWG: Why RTT-Fairness would be Bad for Congestion Control. Draft (txt, ps). - TSVWG: Why the ECN Nonce (RFC 3540) should go to Proposed Standard. - TCPM: Adding Acknowledgement Congestion Control to TCP. Draft (txt, ps). - TCPM: Increasing the Numdupacks Threshold as a Function of Cwnd. - DCCP: A CCID 2 Variant with Slowly-Responding Congestion Control. Draft (txt, ps). - TSVAREA: Why Rate-based Fairness for Best Effort Traffic is like Democracy. ("It has been said that democracy is the worst form of government except all the others that have been tried." - Sir Winston Churchill.) * If anyone wants to volunteer to take any of these on, just let me know. I no longer work full-time, and I get to things slowly. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZM-0004AR-HB; Mon, 27 Nov 2006 08:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZL-0004AH-G9 for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:47 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZJ-0006Vf-4U for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:47 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AA356F0C494; Mon, 27 Nov 2006 10:30:29 -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 kARDU1u8019617; Mon, 27 Nov 2006 10:30:23 -0300 Message-Id: <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 02:31:52 -0300 To: "Duke, Martin" , "Stephen Hemminger" , "Pekka Savola" From: Fernando Gont Subject: RE: [tcpm] encouraging wider participation In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.b oeing.com> References: <20061122103922.6aefdda1@freekitty> <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.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]); Mon, 27 Nov 2006 10:30:29 -0300 (ART) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Lars Eggert , Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org 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. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZS-0004If-VA; Mon, 27 Nov 2006 08:30:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZQ-0004F5-18 for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:52 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZM-0006ay-Sz for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:52 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4D9DAF0C497 for ; Mon, 27 Nov 2006 10:30:49 -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 kARDU1uC019617 for From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZM-0004AR-HB; Mon, 27 Nov 2006 08:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZL-0004AH-G9 for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:47 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZJ-0006Vf-4U for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:47 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AA356F0C494; Mon, 27 Nov 2006 10:30:29 -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 kARDU1u8019617; Mon, 27 Nov 2006 10:30:23 -0300 Message-Id: <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 02:31:52 -0300 To: "Duke, Martin" , "Stephen Hemminger" , "Pekka Savola" From: Fernando Gont Subject: RE: [tcpm] encouraging wider participation In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.b oeing.com> References: <20061122103922.6aefdda1@freekitty> <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.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]); Mon, 27 Nov 2006 10:30:29 -0300 (ART) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Lars Eggert , Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org 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. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZS-0004If-VA; Mon, 27 Nov 2006 08:30:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZQ-0004F5-18 for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:52 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZM-0006ay-Sz for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:52 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4D9DAF0C497 for ; Mon, 27 Nov 2006 10:30:49 -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 kARDU1uC019617 for ; Mon, 27 Nov 2006 10:30:39 -0300 Message-Id: <7.0.1.0.0.20061127052426.04e59d08@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 09:53:28 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:43 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] tcpsecure & IPR 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 was having a look at the tcpsecure doc, and at some point I recalled the issue of the pending patent, etc. A few questions with respect to this issue: * Is the pending patent on all the mitigations, or just on some of them? If so, which ones? * Do vendors have to do paperwork with Cisco (or whoever) before being able to implement this? No matter what the answer to this one is: Is there any online documentation of this that one could show to vendors willing to implement this (but afraid of the patent thing)? * Any data regarding implementation of these counter-measures by vendors other than Cisco & Juniper? Open source OSes? Thanks! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZU-0004LQ-9L; Mon, 27 Nov 2006 08:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZT-0004J9-8W for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:55 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZQ-0006bn-Sp for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:55 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4C9CFF0C497 for ; Mon, 27 Nov 2006 10:30:53 -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 kARDU1uE019617 for ; Mon, 27 Nov 2006 10:30:44 -0300 Message-Id: <7.0.1.0.0.20061127095337.07bf80e8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 09:59:51 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:52 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [tcpm] tcpsecure: Corner case in the mitigation for the SYN-based reset 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: tcpFrom tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZM-0004AR-HB; Mon, 27 Nov 2006 08:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZL-0004AH-G9 for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:47 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZJ-0006Vf-4U for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:47 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AA356F0C494; Mon, 27 Nov 2006 10:30:29 -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 kARDU1u8019617; Mon, 27 Nov 2006 10:30:23 -0300 Message-Id: <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 02:31:52 -0300 To: "Duke, Martin" , "Stephen Hemminger" , "Pekka Savola" From: Fernando Gont Subject: RE: [tcpm] encouraging wider participation In-Reply-To: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.b oeing.com> References: <20061122103922.6aefdda1@freekitty> <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB38C@XCH-NW-5V2.nw.nos.boeing.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]); Mon, 27 Nov 2006 10:30:29 -0300 (ART) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Lars Eggert , Jeffrey Hsu , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org 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. Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZS-0004If-VA; Mon, 27 Nov 2006 08:30:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZQ-0004F5-18 for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:52 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZM-0006ay-Sz for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:52 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4D9DAF0C497 for ; Mon, 27 Nov 2006 10:30:49 -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 kARDU1uC019617 for m-bounces@ietf.org Folks, Section 4.2 of tcpsecure describes a corner case that is supposedly un-handled. My understanding is that the mitigation does *not* harm any feature of TCP. Can anybody think of a reason for which RFC 793 states that a reset should be sent in response to in-window SYNs, rather than responding with an ACK (as suggested by TCP secure)? (maybe simply the fact that an out-of-window SYN could be an old-duplicate, while an in-window SYN certainly indicates an abnormal behaviour (i.e., error condition)?) 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 ; Mon, 27 Nov 2006 10:30:39 -0300 Message-Id: <7.0.1.0.0.20061127052426.04e59d08@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 09:53:28 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:43 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] tcpsecure & IPR 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 was having a look at the tcpsecure doc, and at some point I recalled the issue of the pending patent, etc. A few questions with respect to this issue: * Is the pending patent on all the mitigations, or just on some of them? If so, which ones? * Do vendors have to do paperwork with Cisco (or whoever) before being able to implement this? No matter what the answer to this one is: Is there any online documentation of this that one could show to vendors willing to implement this (but afraid of the patent thing)? * Any data regarding implementation of these counter-measures by vendors other than Cisco & Juniper? Open source OSes? Thanks! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZU-0004LQ-9L; Mon, 27 Nov 2006 08:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZT-0004J9-8W for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:55 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZQ-0006bn-Sp for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:55 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4C9CFF0C497 for ; Mon, 27 Nov 2006 10:30:53 -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 kARDU1uE019617 for ; Mon, 27 Nov 2006 10:30:44 -0300 Message-Id: <7.0.1.0.0.20061127095337.07bf80e8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 09:59:51 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:52 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [tcpm] tcpsecure: Corner case in the mitigation for the SYN-based reset 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, Section 4.2 of tcpsecure describes a corner case that is supposedly un-handled. My understanding is that the mitigation does *not* harm any feature of TCP. Can anybody think of a reason for which RFC 793 states that a reset should be sent in response to in-window SYNs, rather than responding with an ACK (as suggested by TCP secure)? (maybe simply the fact that an out-of-window SYN could be an old-duplicate, while an in-window SYN certainly indicates an abnormal behaviour (i.e., error condition)?) 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 ; Mon, 27 Nov 2006 10:30:39 -0300 Message-Id: <7.0.1.0.0.20061127052426.04e59d08@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 09:53:28 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:43 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] tcpsecure & IPR 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 was having a look at the tcpsecure doc, and at some point I recalled the issue of the pending patent, etc. A few questions with respect to this issue: * Is the pending patent on all the mitigations, or just on some of them? If so, which ones? * Do vendors have to do paperwork with Cisco (or whoever) before being able to implement this? No matter what the answer to this one is: Is there any online documentation of this that one could show to vendors willing to implement this (but afraid of the patent thing)? * Any data regarding implementation of these counter-measures by vendors other than Cisco & Juniper? Open source OSes? Thanks! Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 08:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZU-0004LQ-9L; Mon, 27 Nov 2006 08:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZT-0004J9-8W for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:55 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZQ-0006bn-Sp for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:55 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4C9CFF0C497 for ; Mon, 27 Nov 2006 10:30:53 -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 kARDU1uE019617 for ; Mon, 27 Nov 2006 10:30:44 -0300 Message-Id: <7.0.1.0.0.20061127095337.07bf80e8@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 09:59:51 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:52 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [tcpm] tcpsecure: Corner case in the mitigation for the SYN-based reset 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, Section 4.2 of tcpsecure describes a corner case that is supposedly un-handled. My understanding is that the mitigation does *not* harm any feature of TCP. Can anybody think of a reason for which RFC 793 states that a reset should be sent in response to in-window SYNs, rather than responding with an ACK (as suggested by TCP secure)? (maybe simply the fact that an out-of-window SYN could be an old-duplicate, while an in-window SYN certainly indicates an abnormal behaviour (i.e., error condition)?) 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 Mon Nov 27 08:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZN-0004Bf-Ne; Mon, 27 Nov 2006 08:30:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogZM-0004AP-FI for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:48 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogZK-0006YV-3W for tcpm@ietf.org; Mon, 27 Nov 2006 08:30:48 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 90AC1F0C498 for ; Mon, 27 Nov 2006 10:30:42 -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 kARDUbv1027832 for ; Mon, 27 Nov 2006 10:30:40 -0300 Message-Id: <7.0.1.0.0.20061127100340.05024738@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Nov 2006 10:30:14 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Mon, 27 Nov 2006 10:30:42 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [tcpm] tcpsecure: Mitigation for the data injection attack 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, Section 5.2 (mitigation for the data-injection attack) of tcpsecure argues that "The ACK value MUST be acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT).", but does not say what to do if the ACK field does not pass this check. I think it should clarify that the corresponding segment should be silently dropped (as opposed to, e.g., dropping the segment and sending an ACK). Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 10:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goip4-0000i6-Ei; Mon, 27 Nov 2006 10:55:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goip1-0000Zp-IO for tcpm@ietf.org; Mon, 27 Nov 2006 10:55:08 -0500 Received: from frantic-dmz.weston.borman.com ([206.196.54.22] helo=frantic.weston.borman.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Goio9-0000Se-DR for tcpm@ietf.org; Mon, 27 Nov 2006 10:54:14 -0500 Received: from [127.0.0.1] (frantic.weston.borman.com [206.196.45.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id kARFs1HU026064; Mon, 27 Nov 2006 09:54:01 -0600 (CST) In-Reply-To: <7.0.1.0.0.20061127095337.07bf80e8@gont.com.ar> References: <7.0.1.0.0.20061127095337.07bf80e8@gont.com.ar> 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] tcpsecure: Corner case in the mitigation for the SYN-based reset Date: Mon, 27 Nov 2006 09:55:02 -0600 To: Fernando Gont X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Nov 27, 2006, at 6:59 AM, Fernando Gont wrote: > Folks, > > Section 4.2 of tcpsecure describes a corner case that is supposedly > un-handled. > > My understanding is that the mitigation does *not* harm any feature > of TCP. Can anybody think of a reason for which RFC 793 states that > a reset should be sent in response to in-window SYNs, rather than > responding with an ACK (as suggested by TCP secure)? A SYN is a request to create a new connection, and the other side should not be sending one within the window of an existing connection. So, if the other side does send a new SYN in the window, it is an indication that the current connection no longer exists on the remote side, hence the current connection is dropped, and an RST is generated to indicate to the other side that we've dropped the connection. If we are legitimately in this situation, and we just send a current ACK instead of a RST, then as long as our current ACK doesn't ack the new SYN, the arrival of our ACK will cause the other side (in SYN- SENT state) to generate an RST which will blow away our side of the old connection. Because we're dealing with an in-window SYN, it is impossible for us to accidentally ACK this SYN, since we only advance the ACK for in-sequence data. > > (maybe simply the fact that an out-of-window SYN could be an old- > duplicate, while an in-window SYN certainly indicates an abnormal > behaviour (i.e., error condition)?) Yes, an in-window SYN raises the bar on how serious a problem this is, where as, as you say, an out-of-window SYN can be just an old duplicate, or a new connection request when lost packets haven't allowed the current connection to fully close (e.g., CLOSING or TIME- WAIT) -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 27 16:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goo20-0008DM-Co; Mon, 27 Nov 2006 16:28:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goo1z-0008DH-Ls for tcpm@ietf.org; Mon, 27 Nov 2006 16:28:51 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goo1x-0000un-AR for tcpm@ietf.org; Mon, 27 Nov 2006 16:28:51 -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 kARLRP4r024551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Nov 2006 13:27:25 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id kARLROhW091206; Mon, 27 Nov 2006 13:27:24 -0800 (PST) (envelope-from faber) Date: Mon, 27 Nov 2006 13:27:24 -0800 From: Ted Faber To: Fernando Gont Subject: Re: [tcpm] encouraging wider participation Message-ID: <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> Mime-Version: 1.0 In-Reply-To: <7.0.1.0.0.20061127022657.0530cdf8@gont.com.ar> 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, Mark Allman , 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: , Content-Type: multipart/mixed; boundary="===============0354915943==" Errors-To: tcpm-bounces@ietf.org --===============0354915943== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fig2xvG2VGoz8o/s" Content-Disposition: inline --Fig2xvG2VGoz8o/s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 27, 2006 at 02:31:52AM -0300, Fernando Gont wrote: > At 20:56 22/11/2006, Duke, Martin wrote: >=20 > >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? >=20 > 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. Make it so. (See the problem?) --=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 --Fig2xvG2VGoz8o/s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFa1g8aUz3f+Zf+XsRAnLVAJ9e4L87EJgPWFOjeaYquk51u6yh7ACgoaCc xEwix6Zjeky3U3FkKwdn3Bk= =HOLL -----END PGP SIGNATURE----- --Fig2xvG2VGoz8o/s-- --===============0354915943== 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 --===============0354915943==-- From tcpm-bounces@ietf.org Tue Nov 28 13:58:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp897-0008Q9-TX; Tue, 28 Nov 2006 13:57:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp896-0008FU-JV for tcpm@ietf.org; Tue, 28 Nov 2006 13:57:32 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp895-0003wl-7z for tcpm@ietf.org; Tue, 28 Nov 2006 13:57:32 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 28 Nov 2006 10:57:30 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kASIvRYb016379; Tue, 28 Nov 2006 10:57:27 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kASIvQis003554; Tue, 28 Nov 2006 10:57:26 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 10:57:23 -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] tcpsecure & IPR Date: Tue, 28 Nov 2006 10:57:22 -0800 Message-ID: <13D1EAB852BE194C94773A947138483D02B67984@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure & IPR Thread-Index: AccSKHPtPD5Rt033S0SbjO2V7zXj1wA9R/IA From: "Mitesh Dalal \(mdalal\)" To: "Fernando Gont" , X-OriginalArrivalTime: 28 Nov 2006 18:57:23.0232 (UTC) FILETIME=[09C75200:01C7131F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1469; t=1164740247; x=1165604247; c=relaxed/simple; s=sjdkim4002; 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]=20tcpsecure=20&=20IPR |Sender:=20; bh=3swVRvMtOx8u72ABxStZJTjLRGqJC17gNa/mOIeeOmk=; b=L5+50VggpSYGwnNsbccQ5P/yhSqlG5U1Oo0YK9aDtuYYKRZE64yDJp/ZNCbBOALmULMKQXYi HOywbWHuARI6V4lOqafwRMiHZkwRhmNXf+3gYztWW9uHnERq51xhcZMF; Authentication-Results: sj-dkim-4; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Scott did a presentation on this topic. The slides are at:=20 http://www3.ietf.org/proceedings/04aug/slides/tcpm-11.pdf Hope this should demystify some of your Qs. Mitesh > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Monday, November 27, 2006 4:53 AM > To: tcpm@ietf.org > Subject: [tcpm] tcpsecure & IPR >=20 > Folks, >=20 > I was having a look at the tcpsecure doc, and at some point I=20 > recalled the issue of the pending patent, etc. >=20 > A few questions with respect to this issue: >=20 > * Is the pending patent on all the mitigations, or just on=20 > some of them? If so, which ones? > * Do vendors have to do paperwork with Cisco (or whoever)=20 > before being able to implement this? No matter what the=20 > answer to this one > is: Is there any online documentation of this that one could=20 > show to vendors willing to implement this (but afraid of the=20 > patent thing)? > * Any data regarding implementation of these counter-measures=20 > by vendors other than Cisco & Juniper? Open source OSes? >=20 > Thanks! >=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 Wed Nov 29 21:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpc2D-0004RP-Ih; Wed, 29 Nov 2006 21:52:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpc2C-0004R7-8n for tcpm@ietf.org; Wed, 29 Nov 2006 21:52:24 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpc2A-0002ff-Ln for tcpm@ietf.org; Wed, 29 Nov 2006 21:52:24 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EBA5FF0C434; Wed, 29 Nov 2006 23:52:14 -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 kAU2pomY022168; Wed, 29 Nov 2006 23:52:06 -0300 Message-Id: <7.0.1.0.0.20061129041057.0542f438@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 29 Nov 2006 04:23:35 -0300 To: "Mitesh Dalal \(mdalal\)" , From: Fernando Gont Subject: RE: [tcpm] tcpsecure & IPR In-Reply-To: <13D1EAB852BE194C94773A947138483D02B67984@xmb-sjc-21c.amer. cisco.com> References: <13D1EAB852BE194C94773A947138483D02B67984@xmb-sjc-21c.amer.cisco.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]); Wed, 29 Nov 2006 23:52:13 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Mitesh, Thanks for your answer. However, I don't think that presentation addresses my concerns. There's one basic concern that I have: Let's say I want to encourage vendors to implement tcpsecure. Vendors will want to be assured that they want have to pay anything, or be sued, or whatever. However, I have not been able to find an "official" statement by Cisco regarding this whole issue. Scott may be extremely accurate and right in what he says. But, as he acknowledges in his presentation, he is not speaking for Cisco. A vendor willing to implement tcpsecure will want to read a statement from Cisco claiming whether vendors implementing tcpsecure will have to pay a royalty, or whatever. In the event that somebody implemented tcpsecure, and then Cisco sued them for that, I don't think vendors will be able to defend themselves by claiming "Scott said that we wouldn't have to pay anything". The presentation does not say whether the pending patent is on all the countermeasures, or only on some of them, either. Kindest regards, Fernando Gont >Scott did a presentation on this topic. The slides are >at: >http://www3.ietf.org/proceedings/04aug/slides/tcpm-11.pdf > >Hope this should demystify some of your Qs. > >Mitesh > > > > -----Original Message----- > > From: Fernando Gont [mailto:fernando@gont.com.ar] > > Sent: Monday, November 27, 2006 4:53 AM > > To: tcpm@ietf.org > > Subject: [tcpm] tcpsecure & IPR > > > > Folks, > > > > I was having a look at the tcpsecure doc, and at some point I > > recalled the issue of the pending patent, etc. > > > > A few questions with respect to this issue: > > > > * Is the pending patent on all the mitigations, or just on > > some of them? If so, which ones? > > * Do vendors have to do paperwork with Cisco (or whoever) > > before being able to implement this? No matter what the > > answer to this one > > is: Is there any online documentation of this that one could > > show to vendors willing to implement this (but afraid of the > > patent thing)? > > * Any data regarding implementation of these counter-measures > > by vendors other than Cisco & Juniper? Open source OSes? > > > > Thanks! > > > > 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 > > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www1.ietf.org/mailman/listinfo/tcpm -- 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 Nov 29 22:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpcMQ-0005vU-I4; Wed, 29 Nov 2006 22:13:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpcMP-0005h6-3U for tcpm@ietf.org; Wed, 29 Nov 2006 22:13:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpcMN-00086v-K0 for tcpm@ietf.org; Wed, 29 Nov 2006 22:13:17 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 29 Nov 2006 19:13:15 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kAU3DENk024478; Wed, 29 Nov 2006 19:13:14 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kAU3DEdG004688; Wed, 29 Nov 2006 19:13:14 -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); Wed, 29 Nov 2006 19:13:14 -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] tcpsecure & IPR Date: Wed, 29 Nov 2006 19:13:09 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580282A047@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] tcpsecure & IPR Thread-Index: AccUKr9icPjTvpOeQ5KgoHvFuynNZwAAKJqw From: "Anantha Ramaiah \(ananth\)" To: "Fernando Gont" , "Mitesh Dalal \(mdalal\)" , X-OriginalArrivalTime: 30 Nov 2006 03:13:14.0391 (UTC) FILETIME=[7943AA70:01C7142D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4599; t=1164856394; x=1165720394; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20 |Subject:=20RE=3A=20[tcpm]=20tcpsecure=20&=20IPR |Sender:=20; bh=yoBDJRJGpRRA4YAGcJvY6uNR0V2pfKP3zqHwsjPXlqQ=; b=V/LuLZW/IoTCQdSq+pJM7QJmMwh+eqwWkdhauCBrUo7rbjneFUBFB/pVsbdwavvOd/94T1/5 6ZkC7Ekb7hJjyIBSkZFIyzccnX5wO5K2S//6hQGLX7CHiROtEe96Ddu7; Authentication-Results: sj-dkim-7; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Fernando,=20 I thought the IPR disclosure from Cisco and also Scott's presentation put together, this IPR issue was beaten to death. Cisco's is a defensive patent and if you read it carefully, it tells : [ among other things ] ...... ...... If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title for an implementation of any IETF standard; Pl read http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt for more details. I think this should answer all your questions below. -Anantha > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar]=20 > Sent: Tuesday, November 28, 2006 11:24 PM > To: Mitesh Dalal (mdalal); tcpm@ietf.org > Subject: RE: [tcpm] tcpsecure & IPR >=20 > Mitesh, >=20 > Thanks for your answer. However, I don't think that=20 > presentation addresses my concerns. >=20 > There's one basic concern that I have: > Let's say I want to encourage vendors to implement tcpsecure.=20 > Vendors will want to be assured that they want have to pay=20 > anything, or be sued, or whatever. However, I have not been=20 > able to find an "official" statement by Cisco regarding this=20 > whole issue. AFAIK, Cisco's patent is very defensive. I cannot recall the exact wordings, but I says >=20 > Scott may be extremely accurate and right in what he says.=20 > But, as he acknowledges in his presentation, he is not=20 > speaking for Cisco. >=20 > A vendor willing to implement tcpsecure will want to read a=20 > statement from Cisco claiming whether vendors implementing=20 > tcpsecure will have to pay a royalty, or whatever. >=20 > In the event that somebody implemented tcpsecure, and then=20 > Cisco sued them for that, I don't think vendors will be able=20 > to defend themselves by claiming "Scott said that we wouldn't=20 > have to pay anything". >=20 > The presentation does not say whether the pending patent is=20 > on all the countermeasures, or only on some of them, either. >=20 > Kindest regards, > Fernando Gont >=20 >=20 >=20 >=20 > >Scott did a presentation on this topic. The slides are > >at: > >http://www3.ietf.org/proceedings/04aug/slides/tcpm-11.pdf > > > >Hope this should demystify some of your Qs. > > > >Mitesh > > > > > > > -----Original Message----- > > > From: Fernando Gont [mailto:fernando@gont.com.ar] > > > Sent: Monday, November 27, 2006 4:53 AM > > > To: tcpm@ietf.org > > > Subject: [tcpm] tcpsecure & IPR > > > > > > Folks, > > > > > > I was having a look at the tcpsecure doc, and at some point I=20 > > > recalled the issue of the pending patent, etc. > > > > > > A few questions with respect to this issue: > > > > > > * Is the pending patent on all the mitigations, or just=20 > on some of=20 > > > them? If so, which ones? > > > * Do vendors have to do paperwork with Cisco (or whoever) before=20 > > > being able to implement this? No matter what the answer=20 > to this one > > > is: Is there any online documentation of this that one=20 > could show to=20 > > > vendors willing to implement this (but afraid of the=20 > patent thing)? > > > * Any data regarding implementation of these counter-measures by=20 > > > vendors other than Cisco & Juniper? Open source OSes? > > > > > > Thanks! > > > > > > 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 > > > > > > >_______________________________________________ > >tcpm mailing list > >tcpm@ietf.org > >https://www1.ietf.org/mailman/listinfo/tcpm >=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 Thu Nov 30 08:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GplYN-0001R5-As; Thu, 30 Nov 2006 08:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GplYL-0001Qy-N1 for tcpm@ietf.org; Thu, 30 Nov 2006 08:02:13 -0500 Received: from smtp1.xmundo.net ([201.216.232.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GplYJ-0001Yx-Aq for tcpm@ietf.org; Thu, 30 Nov 2006 08:02:13 -0500 Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0451CF0C454; Thu, 30 Nov 2006 10:02:10 -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 kAUD0QmN012737; Thu, 30 Nov 2006 10:02:06 -0300 Message-Id: <7.0.1.0.0.20061130090550.07b98768@gont.com.ar> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 30 Nov 2006 09:10:08 -0300 To: David Borman From: Fernando Gont Subject: Re: [tcpm] tcpsecure: Corner case in the mitigation for the SYN-based reset In-Reply-To: References: <7.0.1.0.0.20061127095337.07bf80e8@gont.com.ar> 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]); Thu, 30 Nov 2006 10:02:09 -0300 (ART) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Dave, Thanks so much for your answer. Comments inline.... >>(maybe simply the fact that an out-of-window SYN could be an old- >>duplicate, while an in-window SYN certainly indicates an abnormal >>behaviour (i.e., error condition)?) > >Yes, an in-window SYN raises the bar on how serious a problem this >is, where as, as you say, an out-of-window SYN can be just an old >duplicate, or a new connection request when lost packets haven't >allowed the current connection to fully close (e.g., CLOSING or TIME- WAIT) Related to this: Any idea about the reason for sending an ACK (instead of a RST) when SEG.SEQ is in-window but SEG.ACK > SND.NXT? (just me going through the spec...) 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 Thu Nov 30 11:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpocT-0001RE-Mx; Thu, 30 Nov 2006 11:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpocS-0001R8-4O for tcpm@ietf.org; Thu, 30 Nov 2006 11:18:40 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpocQ-0002Cr-Od for tcpm@ietf.org; Thu, 30 Nov 2006 11:18:40 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 30 Nov 2006 08:18:19 -0800 X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B2FCE2AF; Thu, 30 Nov 2006 08:18: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 8FF102AE; Thu, 30 Nov 2006 08:18: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 ENZ53251; Thu, 30 Nov 2006 08:18:19 -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 E093620501; Thu, 30 Nov 2006 08:18:18 -0800 (PST) Received: from NT-SJCA-0752.brcm.ad.broadcom.com ([10.16.192.222]) by NT-SJCA-0751.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 08:18:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] tcpsecure: Corner case in the mitigation for the SYN-based reset Date: Thu, 30 Nov 2006 08:18:16 -0800 Message-ID: In-Reply-To: <7.0.1.0.0.20061130090550.07b98768@gont.com.ar> Thread-Topic: [tcpm] tcpsecure: Corner case in the mitigation for the SYN-based reset Thread-Index: AccUf/Qcv+DgdCN3REKN7I24o+46egAF87Lw From: "Dov Hirshfeld" To: "Fernando Gont" X-OriginalArrivalTime: 30 Nov 2006 16:18:18.0792 (UTC) FILETIME=[25ACDA80:01C7149B] X-WSS-ID: 6971DBC13ES14217087-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 November 30, 2006 2:10 PM, Fernando Gont wrote: >Any idea about the reason for sending an ACK (instead of a RST) when SEG.SEQ is in-window but SEG.ACK > SND.NXT? I think that the reason is that this ACK might be an ACK for old packet which was delayed in the network. Now, if the transmitter RTO has expired, we have to assume that it moved to slow-start and dragged its SND.NXT back. Therefore, if SND.MAX >=3D SEG.ACK > SND.NXT it is still a legitimate packets which should not cause a reset. -Dov hirshfeld _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm